DEV Community: Redreamality

Self-hosted open source worth a weekend: 8 notes on Automatisch, Monica, PeerServer, telegram-files, WsgiDAV and more

Redreamality — Mon, 02 Nov 2026 02:04:18 +0000

Most "self-host this" lists are a wall of logos. I wanted something more useful for myself: a short set of open-source projects I'd actually consider running on a small box, with the one or two details that decide whether they're worth the trouble. The eight below range from a Zapier-style automation engine to a comment widget that lives on GitHub Issues. Each links to a longer reading note I keep in my digital garden.

Automating work and keeping track of people

Automatisch. If you like Zapier's model of triggers and actions but would rather keep the data on your own server, Automatisch is the obvious place to look. It connects services such as Slack and Twitter without code, and getting it running is a git clone followed by docker compose up. Two things are worth knowing before you commit: it's mostly JavaScript with around 14k stars and steady releases, and it uses a dual licence. The community edition is AGPL-3.0, while files with .ee. in the name fall under a commercial enterprise licence. My note has the details on Automatisch's licensing split and setup.

Monica. Monica calls itself a personal relationship manager: a CRM, but for friends and family. You log how you met someone, birthdays, past conversations, addresses, tasks and reminders, and it can hold journals, photos and documents too. What I like is how clearly it says what it isn't. There's no social network and no built-in AI assistant, no ads and no tracking, and it's licensed under AGPL. Users who struggle to remember personal details, including people on the autism spectrum, have reported it helps. Here's my write-up of Monica as a private CRM for your own life.

Moving files and connections around

PeerServer (peerjs-server). PeerJS lets browsers talk to each other over WebRTC, and PeerServer is the small signalling server that introduces them. Your media and data never pass through it. You can install the peer package globally from npm and run peerjs, use the peerjs/peerjs-server Docker image, or Kubernetes, or mount it inside an existing Express app with ExpressPeerServer. If you put it behind a reverse proxy, remember to set proxied: true; there are also options for SSL, CORS, connection limits and custom client IDs. The PeerServer configuration notes cover those options and a Google App Engine deployment that needs the flex environment for WebSockets.

telegram-files. This one solves a narrow but common problem: pulling files out of Telegram channels, groups and shared links reliably and without babysitting. It handles multiple accounts, pause and resume, automatic transfer to another destination, and inline previews of images and video in a PWA. Setup needs your own Telegram API ID and hash. The security defaults are sensible: admin sessions guard the API, previews and WebSocket, and on first start it prints a one-time bootstrap code valid for 15 minutes so nobody else can claim the admin account. It's MIT-licensed. More in my notes on running telegram-files as an unattended downloader.

WsgiDAV. When you need a WebDAV share and you're already in Python, WsgiDAV is a WSGI-based server you can run from the command line or embed as a library. What makes it interesting is the provider model. Besides the plain filesystem, the docs list providers for Mercurial, MongoDB, MySQL and virtual resources, and you can write your own by subclassing DAVProvider, DAVCollection and DAVNonCollection. I kept a map of the WsgiDAV docs and its provider API so I can find the right page quickly.

Small services for reading, linking and commenting

wewe-rss on Hugging Face. wewe-rss turns WeChat official accounts into RSS feeds, which is about the only sane way to read them in a normal feed reader. The guide I saved runs it on a free Hugging Face Space: a MySQL instance on Railway's free tier, a rewritten Dockerfile with app_port: 4000, and three secrets (DATABASE_URL, AUTH_CODE, SERVER_ORIGIN_URL). Keep the Space public at first so the origin URL resolves, use Factory rebuild to update, and back up the database before the free credit runs out. The steps are in my wewe-rss Hugging Face deployment note.

EasyNav. Every company ends up with a wiki page full of internal links that nobody maintains. EasyNav is a cleaner version of that: a navigation portal with groups, sub-categories, ordering, search and login, built on React 18 with an Express backend on SQLite or MySQL. It ships Docker Compose and Kubernetes manifests, hashes passwords with bcrypt, uses JWT and parameterised queries, and is released under the Mulan permissive licence. See what EasyNav includes for an internal links portal.

CWGI comments. The author of this blog comment system had tried Disqus, Gitalk, Utterances and Cusdis and wasn't happy with any of them, so they built their own. Comments are stored as GitHub Issues, logins go through a GitHub App to keep bots out, and the client is Solid.js plus Tailwind at roughly 23 kB gzipped with no iframe. The server side runs on Cloudflare Workers. The catch is that a GitHub App needs a callback URL, so in practice you run your own backend, and anonymous reads are limited to GitHub's 60 requests per hour. I summarised why CWGI stores comments in GitHub Issues and what that means in practice.

How I'd pick

Almost all of these are a Docker command away, so trying them costs little. Where they differ is licensing and exposure. Automatisch and Monica are AGPL, and Automatisch adds enterprise-only files, which matters if you modify and serve them. Anything that holds credentials, such as telegram-files' Telegram session or wewe-rss's database URL, deserves HTTPS and a proper first-admin setup before you open it to the internet.

These are my own reading notes; each project belongs to its respective authors.

Trusting what agents do: 7 notes on workflow memory, step-level rewards, proof-checked code and the ironies of automation

Redreamality — Sat, 31 Oct 2026 02:09:36 +0000

Every week brings a new agent that can browse, code or plan. The question I keep coming back to is less glamorous: how do you know the thing did the right work, and what happens to the humans who are supposed to catch it when it didn't? Over the past month I saved seven notes that circle that question from different directions: memory that learns reusable routines, rewards that grade each reasoning step, a language that refuses code that breaks stated rules, a 40-year-old paper on automation, and a scheduling method that treats estimates as evidence. They aren't a unified theory, but read together they make a decent checklist.

Agents that learn routines and get graded step by step

Agent Workflow Memory (AWM). The idea behind AWM is that a web agent shouldn't solve every task from scratch. It induces "workflows", common sub-routines with the example-specific details stripped out, stores them in memory, and reuses them on later tasks. It runs offline, where it learns from annotated examples, or online, where it builds workflows from its own past attempts with no extra data. The authors report a 35.6% success rate on WebArena and the top text-only score on Mind2Web. I wrote up how AWM's offline and online modes differ, along with the pipeline commands for each benchmark.

TRL's PRM Trainer. Outcome-only rewards tell a model whether the final answer was right; a process reward model (PRM) scores each intermediate step. The original paper behind it found outcome supervision gets you a similar final-answer error rate with fewer labels, but if you care whether the reasoning itself is correct, you need step-level feedback: reasoning errors among correct answers dropped from 14.0% to 3.4%. Hugging Face's TRL ships an experimental PRMTrainer that expects a dataset with prompt, a list of completion steps and a per-step label. My walkthrough of training a step-level reward model with TRL covers the Qwen2-0.5B + Math Shepherd example and the config knobs worth knowing.

Making "don't break this" checkable

Bend. Bend pitches itself as C-like speed, CUDA-like parallelism and Lean-style proofs behind Python-flavoured syntax. The part that matters for agents is LAWS.bend: you declare rules that must hold, and the type checker, which is really a proof checker, rejects any change that breaks them, so an AI edit that introduces a bug gets bounced until the law is proven again. The project describes it as an AGENTS.md backed by proofs, and claims checks fast enough (around a second on a mid-sized codebase) to run after every edit. It's still evolving and only recommended for backends, but Bend's proof-checked approach to AI coding is the most concrete answer I've seen to "how do I stop the agent from regressing this".

The human side of automation

Ironies of Automation. Lisanne Bainbridge's paper, cited more than 1,800 times, is the one I'd hand anyone building agents for operators. Its core irony: automation still needs someone to watch it and someone to take over fast when it fails, yet the more you automate, the less practice that person gets. More alarms can make an emergency more confusing, and people are asked to spot machine errors they can't judge in real time. Her suggestions are refreshingly practical: stop, observe, understand, correct, restart; pace automation to what humans can follow; keep operators trained with manual runs or simulators. Here's my summary of the Ironies of Automation paper, based on a thread that walks through it and Bainbridge's later revision.

Evidence Based Scheduling. Joel Spolsky's method isn't about AI at all, but it's the best antidote I know to single-number promises. Break work into tasks of 16 hours or less, log estimated versus actual time, turn that into a per-person velocity, then run a Monte Carlo simulation to get a probability curve for the ship date instead of one date. Interruptions get absorbed by the historical data rather than estimated separately, and you can watch the curve move as you cut low-priority features. If you're forecasting work that agents and people share, EBS and its Monte Carlo ship-date curve is worth a fresh look.

Finding the evidence and the context

alphaXiv. When I need to check whether a claim about agents holds up, I start from the papers. alphaXiv connects papers, researchers and institutions and is built around answering questions grounded in the underlying research, with an MCP server and a browser extension on top. The snapshot I saved listed work from late September and early October 2026 on context-editing language models, agents recovering from their own critical mistakes, and benchmarks for whether agents can design libraries for other agents. My note on using alphaXiv to keep up with agent research lists the sections that were most useful.

Conare. Plenty of agent failures aren't reasoning failures, they're missing-context failures. Conare sells context infrastructure for AI companies: one API that pulls product data, user history and past decisions from places like Gmail, Slack, Notion and Linear, so a model's answer cites where it came from. It's a young product and my note is mostly about its positioning, but Conare's single context API is a useful reference point if you're designing your own retrieval layer.

What I take from it

Verification shows up at every layer: memory that keeps proven routines, rewards that check steps rather than endings, compilers that check promises, schedules that check estimates against history. Bainbridge's warning sits over all of it. The better the checks get, the more deliberately you have to keep the human in practice.

These are my own reading notes; the projects named above belong to their respective authors.

Code meets markets: 8 notes on Freqtrade, OpenBB, flash loans, Solana and a four-quadrant portfolio

Redreamality — Thu, 29 Oct 2026 02:05:15 +0000

Developers drift into finance the same way they drift into anything else: someone mentions a trading bot, a market dashboard or a DeFi trick, and an evening disappears into docs. Over the past month I saved notes on eight resources that kept coming up in that drift, from open-source trading and data tools to Solana and Ethereum primers. Rereading them side by side, my takeaway is that the code is rarely the hard part. The hard part is knowing what risk you're actually taking, and the better projects below say so loudly. None of this is investment advice; treat it as a reading list for builders.

Tools for trading and market data

Freqtrade. This is the open-source crypto trading bot most people start with, and for good reason. It's written in Python, keeps state in SQLite, and gives you backtesting, plotting and hyperparameter search (hyperopt) before a single real order goes out, with FreqAI for adaptive ML-based strategies on top. You can drive it from Telegram or a built-in web UI, and it talks to most large exchanges for spot and futures. What I like most is the honesty of its docs: run in dry-run mode first, read the source, and assume you're responsible for every loss. My notes on Freqtrade's backtest-first workflow cover the CLI commands and the modest hardware it needs.

OpenBB. OpenBB has shifted from "open-source terminal" to something more like a data plumbing layer. Its Open Data Platform lets you wire proprietary, licensed and public data sources in once, then consume them from Python (pip install openbb), a local FastAPI server, Excel, an analyst-facing Workspace UI, or an MCP server for AI agents. That last surface is the interesting one: the same normalized price history a quant pulls in a notebook can be handed to an agent without a second integration. Here's how OpenBB's Open Data Platform is structured, including its Apache-2.0 license and its warning that the data isn't guaranteed to be accurate.

A market heatmap for China A-shares. Sometimes you don't want a bot, you want a picture. 大盘云图 is a free web heatmap that lays out every Shanghai and Shenzhen listed stock by industry sector, colours each tile by its daily move, and lets you zoom from sector to single ticker, with Hong Kong indices on top. It refreshes roughly every eight seconds during trading hours from mainstream delayed feeds (not Level-2), needs no login, and supports full-screen monitoring and replaying past sessions. If you've used Finviz-style maps for US stocks, this A-share heatmap tool is the equivalent view of the Chinese market.

A four-quadrant allocation framework. This one is a personal system rather than software: a self-described engineer splits money along two axes, volatility and time horizon, and gives each quadrant its own tactics. The bulk sits in low-volatility, short-term positions such as stablecoin yield, with smaller slices for long-term index-fund dollar-cost averaging, trend-following quant strategies on assets like BTC and big-tech stocks, and a deliberately tiny high-risk bucket the author openly says has a low win rate. The page reports strong backtest numbers for an ETF rotation strategy, which deserve the usual scepticism about backtests. The framing is still worth borrowing, and the note sums up the volatility-by-horizon investment quadrants.

Learning the on-chain side

Flash loans, explained. Flash loans are the DeFi feature that sounds impossible until you understand transaction atomicity. You borrow with no collateral, use the funds, and repay inside the same Ethereum transaction; if repayment fails, the whole transaction reverts as if the loan never happened. That makes them useful for arbitrage and, unfortunately, for amplifying protocol exploits. The note also flags the less dramatic costs: you usually have to write and deploy your own Solidity contract, and you pay gas even when the trade fails. A clear primer: what flash loans are and why they're tied to so many DeFi hacks.

A Python programmer's route into blockchain. If Solidity feels like a leap, this guide starts where Python developers already are. It walks from distributed ledgers and proof-of-work versus proof-of-stake, to building a toy blockchain with hashing and chain validation, adding transactions, mining and a Flask API, and finally talking to Ethereum through Web3.py and Remix. It ends with a reading list and a candid section on energy use, governance and regulation. Good for a weekend: a blockchain learning path for Python developers.

pxsol: learning Solana from the ground up. pxsol's Chinese-language book is one of the more thorough Solana walkthroughs I've come across. It goes from keys, Base58 addresses and vanity-address scams, through hand-built transactions, the account model, program-derived addresses and rent exemption, to writing and upgrading Rust programs, issuing SPL tokens and designing airdrops, and closes with Solana's economics and tooling (Anchor, Pinocchio, web3.js, solana-py). The note maps the chapters of the pxsol Solana guide so you can jump to the part you need.

From token to trading pool. One chapter of that series deserves its own entry because it's where theory meets a live market. It shows how the example token goes from mainnet issuance to a Raydium pool paired with SOL: choosing the fee tier and initial price, receiving LP tokens that represent your share of the pool, and then watching what happens when that pool is small. The lesson about slippage in thin liquidity is one every token launcher should learn on paper first. See the Solana DEX listing walkthrough.

Put together, these eight form a rough curriculum: understand the mechanics (flash loans, Python-built chains, Solana from first principles), get decent data (OpenBB, a heatmap for a quick read), test ideas without real money (Freqtrade's dry runs), and decide how much risk you're willing to hold before you write a line of strategy code. The tools have never been easier to run. Knowing when not to run them is still on you. If you've taken any of these from experiment to real capital, I'd like to hear what surprised you.

Open-source LLM apps, from fine-tuning to group chat: 8 notes on Oumi, F5-TTS, VideoLingo, LangBot and more

Redreamality — Tue, 27 Oct 2026 02:11:21 +0000

Most of the interesting open-source LLM work right now isn't a new model. It's the plumbing around models: the pipelines that fine-tune them, the bots that put them in a group chat, the tools that turn a video into subtitles in another language. I went back through my bookmarked notes on that layer and pulled out eight projects that, between them, cover most of the path from training a model to putting it in front of people. My view after rereading them: the hard part has moved from "can a model do this" to "who owns the glue," and the projects below are where that glue is being written in the open.

Training and evaluating

Oumi. If you want one toolchain for data prep, fine-tuning, evaluation and serving, Oumi is the most complete open option I've saved. It handles SFT, LoRA/QLoRA, DPO and GRPO across text and vision models (Qwen, Gemma, Llama, DeepSeek, GLM and more), runs from a laptop up to cloud clusters via oumi launch, and hands inference to vLLM or SGLang. The recent releases lean hard into agents, with tool-calling SFT/DPO, executable tool environments and rubric-based judges. My notes cover Oumi's end-to-end training and deployment workflow in more detail.

How small can an agent framework be? A tutorial built on PocketFlow argues that every LLM agent reduces to a graph: a decision node, some action nodes, an end node, and a loop back to the decision. PocketFlow does it in roughly 100 lines, with each node split into prep, exec and post steps over a shared store. The worked example is a research assistant that decides whether to search or answer, and the same shape turns out to be hiding inside LangGraph, the OpenAI Agents SDK and Pydantic's agents. It's a useful antidote to framework fatigue: why agents are just graphs with loops.

Voice and video

F5-TTS. Flow matching has become a serious alternative to autoregressive speech synthesis, and F5-TTS is the reference implementation people keep pointing to. It pairs a Diffusion Transformer with ConvNeXt V2, adds a "Sway Sampling" trick at inference time, installs with a single pip install f5-tts, and ships a Gradio app for multi-speaker generation and voice chat. One thing to check before shipping anything: the code is MIT, but the pretrained weights are CC-BY-NC because of their training data. Details are in my write-up on F5-TTS and its licensing split.

VideoLingo. This is the project that made me realise how much of "AI dubbing" is pipeline engineering. VideoLingo chains download, word-level ASR and alignment, subtitle segmentation, terminology-aware translation with an optional reflection pass, and dubbing through a choice of TTS backends (F5-TTS among them), all behind a Streamlit UI or a local HTTP API. The note is candid about where it breaks: background noise, mixed-language speech and strict JSON output from the LLM. See how VideoLingo turns a video into translated, dubbed subtitles.

Putting models where people already talk

LangBot. Instead of building a chat UI, LangBot connects models to the chat apps people already use: Discord, Telegram, Slack, LINE, QQ, WeChat, Feishu, DingTalk and more, plus a Matrix bridge for the long tail. It brings the boring-but-necessary production pieces (access control, rate limits, content filtering, monitoring), a plugin system with MCP support, and hooks into Dify, Coze and n8n. You can try it with uvx langbot and a browser. I summarised LangBot's platform coverage and plugin model.

HuixiangDou. Group chats are a hostile place for a bot: most messages aren't questions, and answering everything is spam. HuixiangDou handles this with a three-stage pipeline (preprocess, reject, respond) so it stays quiet unless it has something grounded to say. It needs no training, runs in CPU-only, 2 GB and 10 GB GPU configurations, and tunes its scope through lists of good and bad example questions. The successor, HuixiangDou2, moves to GraphRAG. Here's what HuixiangDou does differently in group chats.

Chatwoot. When the conversation is with customers rather than colleagues, you need an inbox, not a bot. Chatwoot is an MIT-licensed, self-hostable alternative to Intercom and Zendesk that pulls live chat, email, WhatsApp, Telegram, Instagram and SMS into one place, and adds an AI agent called Captain to deflect routine questions. It also covers help-center articles, CSAT reports and Shopify order lookup. My notes on running Chatwoot as an open-source support desk list the deployment options.

A small personal use case

LLM-summarised bookmarks. Not every LLM application needs a platform. One blogger wired a bookmark extension, GitHub Actions, the Wayback Machine, Jina Reader and a cheap DeepSeek model into a pipeline that saves each bookmarked page's full text and writes a list summary plus a one-line gist, for under one yuan a month. It fixes two real problems at once: dead links and forgetting what a long article said. Read the bookmark summary and full-text index setup.

Taken together, these eight sketch a stack you can assemble without a single proprietary service: train or adapt a model with Oumi, keep the agent logic as a plain graph, give it a voice with F5-TTS, localise video with VideoLingo, and meet users in chat through LangBot, HuixiangDou or Chatwoot. Licences are the thing to watch, more than capability. If you've put one of these into production, I'd like to hear which piece needed the most glue.

A self-hosted publishing and reading stack: 8 notes on Pelican, RSS, Glance, SearXNG and Cloudflare Tunnel

Redreamality — Sat, 24 Oct 2026 02:06:06 +0000

I keep a small garden of notes on tools I've bookmarked, and a cluster of them kept circling one question: how much of a personal publishing and reading setup can you run yourself, cheaply, without handing it to a platform? Here are eight notes from that pile, grouped by the job each tool does. Every link goes to the full note on my site.

Publishing

Pelican. A Python static site generator that still earns its place in 2026. You write Markdown or reStructuredText, it renders Jinja2 themes, emits Atom/RSS on its own, and can import from WordPress or an existing feed. No database and no server-side code, so any static host works. My note covers what Pelican does and where the project stands now, including the recent jump to requiring Python 3.11.

RSS.Beauty. Raw XML feeds look broken to anyone who clicks them. This project uses XSLT to turn RSS 2.0 and Atom 1.0 into a readable, mobile-friendly page with one-click subscribe buttons, and it deploys to Cloudflare Pages, Vercel, Netlify or a Docker container. See my notes on making a feed presentable with RSS.Beauty.

listmonk. Some readers will never install a feed reader, so email is the fallback. The weekly digest I saved walks through standing up listmonk as a self-hosted newsletter and converting between RSS and email in both directions. Here's the listmonk and RSS-to-email write-up.

Reading and finding things

ALL-about-RSS. Less a tool than a map: specs from RSS 0.90 to JSON Feed, hosted and self-hosted readers, feed generators for sites that dropped RSS, and bridges out to Kindle, Telegram, Discord or Mastodon. It also keeps a list of services that quietly removed their feeds. My summary is a guided tour of the ALL-about-RSS list.

Glance. Once you follow enough feeds you want one page for them. Glance is a self-hosted dashboard configured in YAML, with widgets for RSS, Hacker News, subreddits, weather, markets and Docker container status, and it ships as a single binary under 20 MB. The note also explains a common gotcha: widget timeouts are often caused by Pi-hole or AdGuard Home rate-limiting DNS. Read the Glance dashboard note.

SearXNG. A metasearch engine that aggregates results from many search services without tracking or profiling you. It's one of the most active self-hosted projects around, with around 37.9k stars and steady commits. I wrote up how the SearXNG repository is organised.

Exposing it, and the longer view

Cloudflare Tunnel. Running services at home is easy; reaching them from outside without opening ports is the hard part. A Tunnel runs cloudflared on your local box, gives each service a subdomain with automatic HTTPS, and can put an email or IP allowlist in front of it. The guide I saved is honest about the caveats too, such as speed and dropped connections in some regions. Here's the free Cloudflare Tunnel walkthrough.

Local-first software. The idea underneath all of this: your data should live on your device first and sync second. The local-first community page collects talks like Martin Kleppmann's "CRDTs: the hard parts" and Peter van Hardenberg's original talk, plus meetup recordings. See the local-first software reading list.

Put together, the list is a full loop: write with Pelican, make the feed readable with RSS.Beauty, mail it with listmonk, read others through Glance, search with SearXNG, and reach all of it through a Tunnel. None of it needs a paid plan, though Cloudflare does ask for a payment method on file before enabling Zero Trust. If you run a similar stack, I'd like to hear what you swapped in.

Who pulls the brake? 5 reads on governing agents: budgets, identity, stop authority and harness design

Redreamality — Wed, 21 Oct 2026 02:03:31 +0000

Once an agent can run for hours, deploy things and spend money, the interesting question stops being "is the model smart enough?" and becomes "who is allowed to stop it, and how?" I've been collecting posts from the Redreamality blog that treat that as an engineering problem rather than a vibe. Here are five that each attack a different piece of it.

1. Soft budgets send email, hard budgets send errors

The scenario is painfully familiar: an agent ships a small demo overnight, it wires up paid APIs and auto-scaling compute, and by morning there's a "you're near your budget" email sitting next to a much bigger bill. The post builds on Simon Willison's argument that usage-billed services should ship with hard caps on by default, so that the next billable request simply fails once the line is crossed. What I liked is the framing as a third cost ledger: not the agent's own tokens, and not wasteful loops inside a trajectory, but the downstream services an agent leaves running after the session ends. It also gives a useful test for any vendor console: don't ask whether there's a "Budget" page, ask what happens after the trigger. Worth reading in full: why services agents deploy need a kill switch, not a warning.

2. When the agent gets its own work email

Google's Gemini Enterprise announcement gave agents coworker status: a dedicated mailbox, calendar, Drive, a directory entry, and the ability to be @-mentioned in Chat or tagged in a Doc comment. Rather than retelling the keynote, this write-up pulls out three things a company has to settle before rolling that out: whose identity the agent acts under, whether you can trace who actually asked it to do something, and who can cap its spending. The author's point is that putting all three on an announcement page is not the same as specifying them, and the gaps show up later. There's a practical checklist at the end. See the identity, audit and spend-cap questions behind coworker agents.

3. Agents that finish the job and keep going anyway

This one covers a preprint that names a failure mode I recognized immediately: the hard goal is already met, but the loop keeps adding abstractions, extra checks and fixes for complexity it invented itself. The authors call it "LLM Parkinsonism", with a careful note that it's a description of trajectory shape, not a clinical claim, and propose Global Executive Control, which separates generating actions from deciding whether the project should continue. On their benchmark with a 40k-token ceiling, success stayed around 96.5% while mean token use dropped by about 36% compared with local control. The takeaway is structural: stop authority belongs outside the self-conditioned loop, not in a model that's merely better at saying "done". Read the breakdown of project-level stop authority for agents.

4. A harness you can install instead of hand-rolling

Most teams still treat the agent loop's control code as private glue: when to compress context, when a tool must wait for a human, how a session resumes. This post looks at Strands Harness, which ships that layer as an installable package with overridable defaults and an SDK underneath for lifecycle hooks, guardrails, sessions and evals. The author is appropriately skeptical about the vendor's roughly 28% token-cost claim and separates sourced numbers from marketing. The four questions it uses to judge any harness (context economics, structural versus prompt-based control, where audit evidence lives, and whether the prototype is the same object you deploy) are reusable well beyond this one product. Here's the analysis of Strands as a productized agent harness.

5. Don't collapse the harness objective into one number

The last piece covers an Adobe Research paper arguing that a harness is a design surface with several objectives at once: a version that is accurate but never refuses an unsafe request, or that burns ten times the tokens, still fails in production. Their method lets a coding agent rewrite full Python harnesses while seeing accuracy, behavioral safety and token cost together in a single search phase, and it beats an "accuracy first, then trim tokens" approach on both safety and cost. If you tune prompts or agent scaffolding against a single score, this is a good corrective. Details are in this summary of multi-objective harness search.

The common thread

All five land in the same place: the controls that matter, such as budgets, identity, stopping and safety, should live in structure the agent can't talk its way around, not in a polite instruction. If you only read one, pick whichever matches the last time something ran longer or cost more than you expected.

Living with Claude Code: 8 reads on quotas, harnesses, MCP sprawl and cost

Redreamality — Tue, 20 Oct 2026 02:08:50 +0000

Most of what I've learned about coding agents this year didn't come from launch posts. It came from the boring questions: why my weekly quota ran dry on a Wednesday, why the agent grabbed the wrong Slack tool, whether a green test run means anything at all. These eight posts from the Redreamality blog each take one of those questions and work it through properly, so I keep them together.

1. Where each Claude Code extension actually plugs in

The extension list has grown long: CLAUDE.md, rules, Skills, MCP, subagents, Hooks, Plugins, and, since October 1, Mods. What makes this piece useful is that it maps each one to the stage of the agent loop it touches instead of just listing features. The distinction I took away is between asking and enforcing. Writing "don't edit .env" in CLAUDE.md is a polite request, while a PreToolUse hook that blocks the edit holds even in bypassPermissions mode. The suggested rollout order is refreshingly conservative: run the defaults first, keep CLAUDE.md under 200 lines, and add Mods last. Read the layer-by-layer map of the Claude Code extension stack before you install your next plugin.

2. Two clocks, one quota

If you've ever wondered where your usage went, this breakdown of how Claude Code quotas are actually metered is the one to bookmark. Two clocks run at the same time. The rolling 5-hour window sets your pace, but the weekly limit is the real budget, and a single big parallel fan-out can drain the weekly allowance before the session window even resets. There's also a sneaky default in there: the built-in Explore subagent runs on the opus alias, so plain codebase digging bills at the priciest everyday model. Pointing subagents at Haiku helps, though the post notes that Haiku 5.5 prompts over 100K tokens cost 5x per token.

3. Local VM, cloud sandbox, or a computer of its own

Starting October 6, new Claude Cowork tasks on Pro and Max run in a per-session cloud sandbox instead of a local VM, and the desktop app hands over copies of local files when a task needs them. The post uses that change to ask a bigger question about where an agent's hands should run: a local VM, a throwaway cloud sandbox, or an always-on agent with its own cloud machine. I liked that it names a new failure mode, the "half-connected" session that keeps working after the desktop app closes but can no longer reach your files. Its most quotable point comes from Anthropic itself: isolation limits where code runs, not what the agent reads or does.

4. Picking the mid-tier engine for daily work

Plenty of teams pinned their agents to Opus because they feared a mid-tier model would fall apart on multi-file edits. This piece makes a practical case for making Sonnet 5.5 the daily default and escalating to Opus only when a task needs open-ended judgment. Input and output cost half of what Opus 5.5 charges, and Anthropic reports 70.6% on Terminal-Bench 4.0, up from 10.3% for Sonnet 5. The more practical warning is that more effort isn't always better. On FrontierCode, Sonnet 5.5 scored lower at Max than at Xhigh. The post closes with a one-week bake-off script that I'd genuinely run before changing a team default.

5. A harness layer you can audit

ECC, short for Everything Claude Code, doesn't replace the agent loop. It wraps one with skills, hooks, rules, a Markdown memory vault, and a config scanner called AgentShield. This teardown of the ECC harness project is careful to separate what the docs actually ship from what the README slogans suggest. The token defaults are worth borrowing even if you never install it: Sonnet as the main model, MAX_THINKING_TOKENS cut from 31,999 to 10,000, Haiku for subagents, and fewer than 10 MCP servers. The bigger lesson is that a catalog of 292 skills becomes a liability once you install all of it. Start from a minimal profile and turn hooks on deliberately.

6. Green tests aren't ownership

This one answers the "coding is solved" crowd, using Alex Ewerlöf's essay and its roughly 473-point Hacker News thread as the spine. The argument I keep coming back to is about ownership, which rests on knowledge, mandate, and accountability. Lose any one and nobody really owns the code, and a passing UAT run only proves the acceptance script passed. My favorite detail is Ewerlöf's story of an agent taking 12 minutes and 72 steps to bump five npm patch dependencies, a job he finishes by hand in under a minute. Read it for why cheap generation hasn't made verification cheap, then go check who actually reviews your agent PRs.

7. Every MCP server has a running cost

Adding an MCP server takes a minute, and that's exactly the trap. This survey of the hidden bill for piling on MCP servers opens with Anthropic's tally: five common servers expose 58 tools and burn about 55K tokens before you type a word. Selection quality drops as well, since Claude's tool picking degrades past 30 to 50 tools and similar names get mixed up. The post compares tool search, Code Mode, gateways, and a trained approach called ToolSearcher. Its most transferable advice is to measure "found the tool" and "picked the tool" separately, because an untrained 7B model surfaced 72.4% of target tools yet scored an F1 of only 0.098.

8. When a cheap model is actually cheap

DeepSeek V4.1 Flash keeps getting called absurdly cheap, and this post works out when that holds. The secret is one line of the price sheet: a cache hit costs $0.003 per million tokens off-peak, about 2% of a miss, with no long-context surcharge up to 1M tokens. That makes long, cache-heavy sessions very cheap, and a modeled all-day session comes to $0.53 at peak against $2.58 on Haiku 5.5. Short tasks are a different story, and peak hours fall right on the Beijing working day. If you're deciding what to route to it, this agent cost model for DeepSeek Flash is more honest than any headline rate.

Wrapping up

None of these posts argue that agents are bad or that one vendor wins. They treat a coding agent as a system with meters, boundaries, and failure modes, which is exactly how it feels after a few months of daily use. Start with whichever problem bit you most recently.