DEV Community

Redreamality
Redreamality

Posted on

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

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.

Top comments (1)

Collapse
 
reidmarlow profile image
Reid Marlow •

The token overhead from MCP server sprawl in point seven is exactly what happens when teams treat tool integration as an infrastructure decision rather than a context budget. Shipping 50 tool schemas into every prompt eats 50K tokens before the user types a character, but the worse failure mode is prompt dilution. When an agent has 60 tools in context, the model spends half its attention budget disambiguating near-synonym function names like fetch_ticket, get_issue, and read_task. That search noise directly degrades downstream tool parameter synthesis.

The second trap with heavy harnesses is subagent quota leakage. If an orchestrator spins up four worker subagents and each child process inherits the full parent configuration including all MCP servers and thinking quotas, a single file-search task burns 200K tokens across the fleet. Scoping child agents down to minimal tool manifests with thinking tokens clamped to zero for routine inspection tasks stops parallel workflows from exhausting weekly quotas before lunch.