DEV Community: Redreamality

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.