Spawning a subagent in Claude Code feels free. It isn't. We measured it across a real review pipeline, and the number that matters is one almost nobody talks about: each subagent costs roughly 436,000 tokens in fixed overhead before it does any useful work.
This post explains where that number comes from, how to reproduce the measurement on your own setup, and what it changes about how you should split work between agents.
The experiment
We run a weekly review pipeline over a catalog of digital products (Markdown-heavy repos: rules files, skills, templates). The pipeline embeds each product's full content into a reviewer prompt and asks for structured findings.
We ran the same product, same full content, two ways:
- Arm A: three subagents, one per review perspective (buyer value, niche accuracy, compliance). Total prompt size: ~314k characters.
- Arm B: one subagent covering all three perspectives in sequence. Total prompt size: ~105k characters.
Billed token totals, from the session transcript:
| Arm A (3 agents) | Arm B (1 agent) | |
|---|---|---|
| Total tokens | 2,150,310 | 809,070 |
| Distinct defect classes found | 20 | 11 |
| Primary-source fetches performed | 0 | 2 |
Arm B cost 37.6% of Arm A. The naive expectation — "three agents read the same content, so about 3x" — roughly holds, but the reason is not the content.
Where the tokens actually go
Breaking the transcript down per turn, each agent carried about 436k tokens of overhead that had nothing to do with the review itself: the initial context load at spin-up plus the cache write on its final turn. The embedded product content — the thing we assumed dominated cost — was only about 46k tokens per agent.
That's a 9.5:1 ratio of fixed cost to payload.
Two consequences fall out immediately:
- Embedding full content is cheap. We had been truncating embedded files to save tokens, which quietly excluded the files that carried the product's actual value from review. Full-content embedding turned out to cost almost nothing relative to what we were already paying per agent.
- Headcount is expensive. The cost lever is the number of agents, not the size of what you hand them. Three agents reading 46k each cost far more than one agent reading 138k.
How to measure this yourself
You don't need any special tooling. Claude Code writes full transcripts as JSONL under ~/.claude/projects/<project-dir>/, and each assistant message records its token usage.
- Run your multi-agent task once.
- Find the transcript files for the session (one per agent for spawned agents).
- Sum
usagefields per agent: input tokens, output tokens, cache creation, cache reads. - Separate the first turn (spin-up) and last turn (final cache write) from the middle turns. The first and last are your fixed overhead; the middle is your actual work.
The exact overhead number will vary with your system prompt, MCP servers, and loaded skills — every always-on tool schema is part of the spin-up payload. Ours landed at ~436k. Yours may be smaller or much larger; the point is that it is per agent and independent of the task.
What this changes in practice
Merge reviewers whose perspectives overlap. In Arm A, two of our three perspectives (buyer value and compliance) produced overlapping findings — 4 of 7 findings duplicated across them. We were paying the fixed cost twice to hear the same defect twice. We now run those as one agent with explicit perspective switching, and keep only genuinely orthogonal perspectives (spec verification against primary sources) separate.
Spawn for independence, not for tidiness. A subagent is worth its 436k when you need something a single context can't give you: an opinion formed without seeing your reasoning, a parallel read of material you don't want polluting your main context, or true wall-clock parallelism. "This feels like a separate concern" is not, by itself, worth 436k tokens.
Don't starve the agents you do spawn. Since payload is the cheap part, hand each agent everything it needs — full files, full context, explicit instructions to fetch primary sources. The quality difference in our experiment came from exactly that: the one agent that fetched two official docs pages found the most serious defect (a fabricated quote presented as official documentation) that all three narrow agents missed.
One honest caveat: this is n=1, one pipeline, one week, measured on our workload. The 436k figure is ours, not a constant of the platform. But the structure of the result — fixed cost per agent dwarfing content cost — held on every agent we inspected, and it inverted how we design review fleets.
We publish AI-coding field notes like this daily, and maintain Rulestack — rules files, skills, and templates for Claude Code, Cursor, and Codex that hold up in real projects.
Follow us on Bluesky for the daily short-form version: @ai-shop.bsky.social
Correction (2026-08-17)
A reader pointed out something this post gets wrong by omission, and they are right.
The ~436K figure sums the token fields from the transcript at face value. Those fields do not all bill at the same rate. Cache reads bill at 0.10x base input, and 5-minute cache writes at 1.25x — and spin-up overhead is overwhelmingly cached system prompt and tool schemas, which is exactly the part that gets read from cache. So the 9.5:1 fixed-to-payload ratio is a ratio of tokens, and the corresponding ratio in dollars is considerably smaller.
I should have said that in the post. "Costs 436K tokens" reads as a cost claim, and I did not separate token accounting from dollar accounting anywhere.
What the correction does not change: the fixed part still barely moves with how much work you hand the child, so headcount — not payload size — is the lever. Two reviewers whose findings overlap still pay the fixed cost twice to find the same defect twice. Spawn for independence, not for tidiness.
The measurement I still owe you is the cache-read versus cache-creation split from the same transcript fields, which would turn the dollar ratio from an argument into a number. I have not run it yet.
Primary sources for this correction:
Correction (2026-08-24)
The measurement I owed in the last correction is now run, and it retires the headline number. A do-nothing probe subagent in the same repository shows cache_creation_input_tokens: 54,154 on its first request — that is the real cold-start fixed cost here. The ~436k in this article came from summing face-value token counts across every request of a multi-request run, which counts the same cached prefix once per request. Face-value sums measure re-delivery volume, not what a spawn costs you.
With the corrected fixed cost, the delegate-vs-inline break-even drops from "only huge reads" to roughly 30–50k tokens of reading for a same-model subagent, and roughly 10k when the subagent runs on a cheaper model. The method that survives: read the first request's cache_creation_input_tokens from the probe's transcript, and weight cache reads at ~0.1×.
Primary sources for this correction:
Top comments (2)
Worth separating the two numbers in that 9.5:1, because you name the variables behind the fixed cost, system prompt, MCP servers and loaded skills, and then hold them constant across both arms. One more belongs on that list: CLAUDE.md is documented to load into every custom subagent, with the built in Explore and Plan agents as the stated exceptions, so a large CLAUDE.md gets multiplied by headcount and compounds the exact effect you measured. The ablation that would settle it is rerunning Arm A with the servers that pipeline never calls disconnected, then again with a trimmed CLAUDE.md, one variable at a time. If the fixed number drops while the 46k payload holds, headcount and tool surface are two independent levers, and the second one costs you nothing in review quality. Right now Arm B buys its 37.6% by giving up three parallel perspectives, which is a real trade. Were both arms run against the same set of connected servers?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.