Why Claude Code subagents multiply your cost so fast

Subagents cost more than you expect because each one is a separate conversation, not a branch of yours. It gets its own context window, its own copy of the system prompt and tool definitions, and a cache that starts cold. It then re-reads the files it needs for itself, because it cannot see what the parent already read. Fan out to six of them and you have not split one job six ways, you have started six jobs that each pay full setup cost and each rediscover most of the same repository.

The second half of the bill lands back in the parent. Every subagent returns a summary, and that summary joins the parent transcript permanently. From then on it is resent with every parent turn until the session ends. So a wide fan-out charges you once inside each child and then repeatedly in the parent, for the rest of the run.

Where the tokens actually go

If you have only ever looked at the output length, the numbers will not make sense. Model output is a rounding error in an agent run. Input is the bill. A single Claude Code turn resends the entire conversation so far, including every file you have read, every grep result, every diff, every tool error. That is why an agent session gets more expensive per turn the longer it runs, even when your prompts get shorter.

Within one agent, that growth is roughly quadratic in the number of turns. Turn one sends the prefix, turn twenty sends the prefix plus nineteen turns of accumulated tool output. Now run N agents concurrently and you get N of those curves, in parallel, with no shared history between them. The wall clock stays flat because they run at the same time. The token count does not.

• Per-subagent fixed overhead: system prompt, tool schemas, project instructions, and whatever brief you handed it. Paid once per subagent, not once per run.
• Cold cache: prompt caching rewards reusing an identical prefix. A brand new subagent has no matching prefix to reuse, so its first calls are billed as ordinary input, and short-lived subagents can finish before caching ever pays off.
• Redundant discovery: three subagents auditing three modules will each read the shared types file, the config, and the same half of the router. Same bytes, tokenized three times.
• Return-trip inflation: every result summary lands in the parent context and is resent on every later parent turn.
• Retries and course corrections: a subagent that misreads its brief burns a full exploration pass before you find out, and you usually pay for a second pass to fix it.
• Failed tool calls: a grep that returns nothing still costs the round trip, and agents that are unsure tend to grep more.

The caching part is the one that surprises people

Anthropic prompt caching works on exact prefix matches. Once a cached prefix exists, reading it back is much cheaper than sending those tokens fresh, which is why a long single-threaded session is not as ruinous as the raw token counts suggest. Writing to the cache costs a premium over normal input, and cache entries expire after a short idle window unless refreshed.

Fan-out interacts badly with all three of those properties. Each subagent has a different prefix, so each one pays its own cache write premium. Many subagents are short enough that they never reach the point where reads recoup the write. And while the children are running, the parent may sit idle long enough for its own cached prefix to lapse, so the parent pays to write it again when it resumes. You can hit a case where a run with six subagents pays six cache-write premiums plus one parent rewrite, and collects almost none of the read discount.

Parallelism buys you latency. It does not buy you tokens. Those are separate budgets and only one of them shows up on the invoice.

How to keep fan-out under control

None of this means subagents are a bad idea. They are the right tool when a task is genuinely independent and would otherwise pollute the main context with junk you never want to see again. Searching a large codebase for every call site, then returning eleven lines, is a good trade: the parent pays for eleven lines instead of forty file reads. The failure mode is fan-out as a reflex.

• Fan out for context isolation, not for speed. If the parent would benefit from seeing the intermediate work, do it inline.
• Give each subagent a narrow brief with the file paths already resolved. The expensive part of a subagent is not the thinking, it is the search it does before thinking.
• Cap concurrency. Three well-scoped subagents usually beat eight overlapping ones on both cost and quality.
• Ask for a bounded return format. An open-ended report of findings comes back long and then sits in the parent context forever.
• Do the shared reading once in the parent and paste the relevant excerpt into each brief, rather than letting five children each read the same file.
• Use a smaller model for mechanical subagent work such as inventory, listing, and grep-and-summarize. Save the expensive model for the synthesis step.
• Watch for the same subagent being spawned twice with near-identical inputs. It happens more than you would think, especially after a retry.

Seeing it per process, which is the part that is normally invisible

The reason this is hard to reason about is that nothing in the default setup attributes cost to a specific subagent. You get a session total, well after the fact. I built Probe0 partly because I got tired of guessing which fan-out was responsible for a bad afternoon.

Probe0 is a local proxy for coding agents on macOS. Every agent CLI on the machine routes through it after one setup step, a local proxy plus a certificate installed once, and there is no Probe0 server anywhere in the path. The Recording module keeps a full request ledger: model, token counts, real cost, latency, and which process made each call. That last field is what makes subagent cost legible, because you can finally see that the audit fan-out cost four times what the implementation did.

A few of the other modules aim directly at the failure modes above, and each one is individually switchable and reports what it saved. Request Coalescing collapses simultaneous identical calls into one upstream request, which is exactly the shape of parallel subagents grepping the same thing at the same moment. Exact Cache stores repeat calls on local disk and never touches the network. Semantic Cache uses a local vector index with a strict similarity floor, and it refuses to match anything carrying tool calls, because a near-miss on a tool-bearing turn corrupts a run in ways that are worse than the money you saved. Model Tiering tries a cheap model first for the mechanical work. Spend Guard sets a hard cap per run or per day, warns, then pauses, which is the only real defence against a fan-out that goes wrong while you are away from the keyboard.

The honest limits: macOS only, private beta, sign-in via Google or GitHub, and the account system is new. It is not a team gateway and does not try to be a hundred-provider catalog. It covers what coding agents actually call. If you need multi-user deployment, audit trails across a team, or Linux and Windows support, a hosted gateway is the right answer and I would not argue otherwise.

Either way, the mental model matters more than the tool. A subagent is a whole new conversation with a cold cache and no memory of what you already know. Price it that way before you spawn six.