Why Claude Subagents Cost 4x More Tokens (And When They're Worth It)

The first time I split a big refactor into a fan-out of parallel agents, I expected the bill to go up a little for the convenience. It went up a lot. When I actually read the metering afterward, the reason was obvious in hindsight and almost never mentioned in the “spawn 10 agents!” tutorials.

A subagent does not inherit the parent session's cached context. It spins up a fresh window, reads the files it needs, runs its own tool calls, and pays the full uncached rate for all of it. Your main session had that repo context cached and was paying the discounted cache-read price on every turn. The subagent doesn't get that discount. It starts from zero.

This is why the multiplier is so steep. In a widely repeated metered example, a task that ran on about 121,000 input tokens as a single agent reached roughly 513,000 with just two subagents — about a 4.2x jump. The broad rule of thumb people report lines up with that: subagent-heavy workflows add somewhere between 200% and 500% overheadcompared to the same job as one agent. The work didn't get harder. You just paid for the setup several times.

It helps to name the buckets. When you fan out, the extra spend comes from four places, and only one of them is doing real work:

• Cold context re-loads — each agent reads the files, docs, and instructions it needs at the uncached rate, and overlapping files get bought once per agent.
• System-prompt and tool-schema overhead — every agent carries its own system prompt and tool definitions. Bloated MCP servers make this brutal, loading thousands of tokens per turn, per agent.
• Coordination — the parent has to brief each worker and then read and merge their outputs, which is its own round of tokens.
• The actual task — usually the smallest slice of the total, which is the whole frustration.

That second bucket is the one people forget. If you're running fat MCP servers, every agent pays the MCP tax on every turn — I dug into that specific line item in what MCP servers really cost in tokens. Multiply that per-turn tax across a fan-out and it stops being a rounding error.

None of this means fan-out is bad. It means fan-out is a tool with a real price, and the price is only justified in specific situations. The deciding question I ask every time: does each agent need a different slice of context?

• Genuinely parallel + independent: reviewing ten unrelated files, running five research threads that don't touch each other, auditing separate modules. The isolation and the wall-clock speedup are worth the token premium.
• Context that won't fit in one window: when the combined material would blow past a single session, splitting it is the only way through — and each agent legitimately needs only its own slice.
• Adversarial or diverse perspectives: spawning several verifiers to independently check a claim, where you want the redundancy on purpose.

And when it's not worth it: sequential work where step two needs step one's result, or anything where every agent would load the same shared context. There, fan-out just means paying to re-read the same files N times. A single session keeps that context cached and reuses it — which is the whole point of prompt caching, and exactly the discount a cold subagent throws away.

There's a subtlety worth knowing once your workloads get big. A naive subagent orchestrator — one parent handing full context to each worker — is the expensive pattern I've been describing. An agent team, where workers share a task list and each loads only its own task plus the relevant prior outputs, scales better.

The counter-intuitive part: for a large parallel workload, a team can land three to five times cheaper than a subagent orchestrator, precisely because no single agent ever accumulates the full context. Each teammate carries only what its task needs. For a small job the coordination overhead isn't worth it and a single session wins outright. I broke down the orchestration side of this in my notes on multi-agent orchestration.

When I do fan out, these four keep the multiplier in check:

• Route workers to a cheaper model. Defaulting every worker to Opus is where the money goes; sending workers to Haiku tends to cut the subagent line item by around 30% with no real quality loss on mechanical work.
• Hand each agent the minimum context. Don't ship the whole repo to a worker that touches one file. Less cold context means less re-buying.
• Default to a single session and earn the fan-out. Start sequential; only split when a step is genuinely independent and the parallelism actually buys you something.
• Cap the whole run with a hard token budget. A fan-out that spawns more agents than you expected should hit a ceiling and abort, not quietly 10x the invoice.

That last one is non-negotiable for anything unattended — it's the same seatbelt I put on every autonomous loop in running AI agents on autopilot without torching your budget. And if you want the full model-side playbook — routing thresholds, caching, prompt compression — it's in how I cut my Claude API bill by 73%. Anthropic's own pricing docs spell out the cache-read discount you're forfeiting every time an agent starts cold.

• Subagents start cold — they don't inherit the parent's cached prefix, so they re-buy context at the uncached rate.
• Expect 3–5x the tokens of a single session; one metered example jumped from ~121K to ~513K with two subagents.
• Fan out only when each agent needs a different slice of context. Shared-context work belongs in one session.
• For big parallel jobs, an agent team beats a naive subagent orchestrator because no agent holds the full context.
• Control it: route workers to a cheaper model, hand each the minimum context, and cap the run with a hard budget.