Running many agents at once: the tax is linear, the rebate is quadratic

Ask what it costs to run several agents at once and you get a number back immediately: N times one agent. It is the intuition everyone starts from, it is what the tooling’s warnings imply, and it is wrong often enough to be worth taking apart.

The reason it is wrong is not that agents are secretly cheap. Every extra agent really does pay a startup cost, and we can price it to the cent. The reason is that the N-times rule silently assumes each agent does a whole job’s worth of work — and the most common thing people actually do with parallel agents is the opposite: they cut one job into slices. Those two transactions have opposite economics, because the dominant cost in a long agent session does not grow linearly with work. It grows with the square of the turn count.

This piece prices both. Every mechanic is checked against Anthropic’s documentation; every dollar figure is computed from our own pricing snapshot with the same engine that drives the site’s calculators. The model and its assumptions are stated so you can substitute your own.

Three numbers, three different questions

Start by separating the multipliers already in circulation, because they get quoted interchangeably and they measure different things.

About 4x, and about 15x. In how we built our multi-agent research system, Anthropic writes: “In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” Both are measured against a chat, not against each other. Divide them and a multi-agent system costs roughly 3.75 times a single agent — for the research workload they were measuring, where agents fan out across sources.

About 7x. Anthropic’s Claude Code cost documentation says agent teams “use approximately 7x more tokens than standard sessions when teammates run in plan mode, because each teammate maintains its own context window and runs as a separate Claude instance.” Different baseline, different workload, different mode.

90.2%. From the same research post: “a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” That is a quality number, and it arrives attached to a caveat from the same page — that of the factors explaining performance variance, “token usage by itself explains 80% of the variance.”

None of these is a price for your workload. They are observations about specific workloads, and the honest way to use them is as evidence that the effect is large, not as a coefficient. What follows is the mechanism underneath them, which does transfer.

The tax: every agent starts cold

A subagent is not a continuation of your session. Anthropic’s documentation is specific about what it starts with: its own system prompt plus environment details — not the full Claude Code system prompt — the delegation prompt, CLAUDE.md at every level of the hierarchy, a git status snapshot taken at the parent session’s start, the full content of any preloaded skills, and a roster of sibling agents. It does not see your conversation history, the files Claude already read, the skills you already invoked, or your output style.

A teammate in an agent team starts even heavier. It is a full, independent Claude Code session: “a teammate loads the same project context as a regular session: CLAUDE.md, MCP servers, and skills,” plus the spawn prompt. The lead’s conversation history does not carry over.

Neither can read the parent’s cache, because the prefixes differ. So each one opens with a cold write of everything it loads. Call that block the prefix, and note one thing that works in your favour: subagents, teammates and workflow agents all fall outside the main conversation’s TTL bucket, so their writes are billed at the five-minute rate of 1.25x base input rather than the one-hour rate of 2x that a subscription’s main conversation uses.

Twelve to twenty-five cents per agent, before it reads a single file. Spawn five and you have spent about sixty cents on nothing but startup; spawn fifty and it is over six dollars.

The stagger: Claude Code buys the prefix back with latency

Which is why Claude Code does something clever, and undocumented anywhere outside one paragraph of the workflows page.

In a dynamic workflow, agents that match on model, effort level, agent type, tools, output schema and working directory build an identical tools-and-system-prompt prefix. So when a fan-out starts several matching agents at once, Claude Code “holds all but the first until the first agent’s response begins, then releases the held agents together so their first requests read the shared prefix instead of each processing it uncached.” The hold is capped by CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS, 5000 milliseconds by default, and setting it to 0 turns the behaviour off.

That converts N cold writes into one write and N-1 reads. A cached read is 8% of a five-minute write, so the saving is close to the whole thing:

20k prefix on Opus 5. 16 is a workflow’s concurrent-agent cap; the large size guideline aims under 50.

Read that as a price on time: Claude Code spends up to five seconds of wall clock to save roughly eleven cents per held agent. It is the best trade in the whole system, and it is on by default. The thing to avoid is quietly breaking the conditions for it — a fan-out where agents differ in model or effort or tool set does not share a prefix, and pays the naive column instead.

The rebate: why history is the quadratic term

Now the part that inverts the intuition.

A single agent re-sends its entire conversation on every turn. That is what prompt caching discounts and does not eliminate — we worked through the mechanics in the 20x in Claude Code caching. The consequence for parallelism is this: on turn t, the agent re-reads roughly P + (t-1)d tokens, where P is the prefix and d is what each turn appends. Sum that over n turns and the history term contains d · n(n-1)/2. It is quadratic in turns.

Split the same n turns across k agents, each running n/k turns, and that term becomes k · d · (n/k)(n/k - 1)/2, which is the original divided by roughly k. Meanwhile the prefix write, paid once per agent, is multiplied by k.

So a split trades a linear penalty for a quadratic saving. Here is the same job — 30 turns, 20k prefix, 6k appended per turn, 1,500 output tokens per turn, all on Opus 5 — cut different ways:

The history column falls by a factor of eight from one agent to fifteen. The write column rises by a factor of 2.4. Between them sits a minimum, and on this job it is at three agents, 17% below a single session.

Anthropic’s guidance, arrived at from experience rather than from cache arithmetic, is: “Start with 3-5 teammates for most workflows” and “If you have 15 independent tasks, 3 teammates is a good starting point.” Two independent routes to the same number is the strongest evidence in this article that the model is describing something real.

The optimum is not a constant

It moves, and predictably. Longer jobs push it up, because the quadratic term grows; fatter prefixes push it down, because the linear penalty grows; more tokens appended per turn push it up sharply, because that is the coefficient on the quadratic.

The rule that falls out is short enough to keep: split long, context-heavy work; keep short work or work with a heavy per-agent startup in one session. On a twelve-turn job with a 40k prefix, every split loses money.

Partition is not redundancy

Everything above describes cutting one job into slices. The other thing people do with parallel agents is run the same job several times from different angles — five hypotheses, three reviewers, four candidate designs. Anthropic’s own examples lean this way: spawn three teammates to review a PR for security, performance and test coverage; spawn five to argue competing theories about a bug.

That is not a split. Each agent does a full job’s worth of work, so there is no quadratic term to divide:

Exactly N times, to the cent. This is where the folk rule is right, and it is where Anthropic’s 15x lives — a research fan-out is redundancy by design, because the whole point is that several agents look at the same question from different sides.

When delegation pays: a break-even in remaining turns

The most common single use of a subagent is not parallelism at all. It is containment: run the tests, read the logs, crawl the docs, and return a summary — so the volume never enters the main conversation. Anthropic’s docs put it plainly: “the verbose output stays in the subagent’s context while only the relevant summary returns to your main conversation.”

That has a clean break-even, and it is measured in parent turns remaining, not in tokens.

Delegating costs you the worker’s own prefix write plus its output. It saves the parent from carrying V verbose tokens on every turn it has left, minus the S tokens of summary that come back. So:

T* = (P_worker × W_worker + O_worker × Out_worker) / ((V − S) × R_parent)

With a 12k worker prefix, 2,000 tokens of worker output, a 500-token summary, and an Opus 5 parent:

Two things drop out of that table.

The worker’s model is the whole lever. The parent’s saving is fixed by the parent’s cached-read rate, so it does not move when you change the worker. The numerator scales straight down with the worker’s price. A 50k log dump handed to another Opus 5 needs five more parent turns to pay off; handed to Haiku 4.5 it pays off after one. Set it per subagent with the model field in its definition, or for a whole session with CLAUDE_CODE_SUBAGENT_MODEL.

Delegate volume, not difficulty. The denominator is the volume you avoid carrying. Delegating a small, hard question to a subagent is usually a loss — you pay a full prefix to save almost nothing. Delegating a large, dumb one is nearly always a win.

Where the split stops paying

Three limits, and they are not symmetric with the case for splitting.

Shared context defeats it. The quadratic saving exists only because each agent carries a fraction of the history. If every agent needs the whole picture, you have not partitioned anything — you have run redundancy with extra steps, and you pay k times for the privilege. Anthropic says this about their own system: “some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.”

Coordination is not free, and it is not in our model. The lead spends turns assigning work and synthesising results; teammates message each other; a task list gets read and updated. Our 30-turn split above prices the work, not the talking. Add a lead session of eight coordination turns to the three-teammate case and the 17% saving compresses to about 14% — still positive, but the direction of the error is worth knowing. Anthropic’s own framing is that “agent teams add coordination overhead” and that “beyond a certain point, additional teammates don’t speed up work proportionally.”

At equal budgets, more agents is not more intelligence. This is the finding that keeps the whole topic honest, and it does not come from a vendor. In Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets (arXiv 2604.02460, Dat Tran and Douwe Kiela, submitted April 2026), the authors hold reasoning tokens constant across architectures and report: “SAS consistently match or outperform MAS on multi-hop reasoning tasks when reasoning tokens are held constant.” Their conclusion is blunter still — that many reported multi-agent advantages are “better explained by unaccounted computation and context effects rather than inherent architectural benefits.”

Set that beside Anthropic’s 90.2%, which came with roughly 15x the tokens, and the two stop disagreeing. Parallelism buys throughput and context headroom. It does not buy reasoning quality per token. If your bottleneck is that a problem is hard rather than that it is big, more agents is the wrong instrument.

The settings that actually move the number

Most of what governs a fan-out’s cost is configuration you never see. These are the ones with measurable effects.

subagentPromptCacheTtl — the one most people are missing. Claude Code sorts every request into two TTL buckets: the main conversation, and everything else. That second bucket — subagents, workflows, in-process teammates, forks, compaction, session titles — gets five minutes by default, including on a Claude subscription. You can move it to 1h with this setting or the CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL environment variable; the docs put the requirement at Claude Code v2.1.242 or later, and the changelog lists both settings as landing in v2.1.243. One-hour writes cost 2x base input against 1.25x, so it pays when your agents idle between turns and costs you 60% extra on writes when they do not.

experimental.cacheTtl — the same dial, one level finer. Anthropic’s changelog for v2.1.248 adds a per-agent cacheTtl of 5m or 1h to a subagent definition’s frontmatter, “used when no subagent TTL setting is configured.” That is the right place for it when one long-running worker idles between turns and the rest of your fan-out does not — a session-wide 1h would pay the doubled write rate for every short-lived agent to help the one slow one.

CLAUDE_CODE_SUBAGENT_MODEL — sets the worker model for every subagent and teammate whose model is not named explicitly, and it overrides the per-definition model field. Per the break-even table, this is the highest-leverage single setting in a delegation-heavy workflow.

CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS — 5000 by default. Leave it alone unless you are debugging; setting it to 0 disables the shared-prefix hold and moves your fan-out from the staggered column to the naive one.

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS — 20 by default, above which spawning fails with Concurrent subagent limit reached. Nesting is capped separately at 3 levels by CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Agent teams cannot nest at all: only the lead spawns teammates.

workflowSizeGuideline — advice Claude receives when writing a workflow, not a cap: small aims under 5 agents, medium under 15 (the default), large under 50. A workflow runs at most 16 agents concurrently and 1,000 in total per run, and Claude Code shows a Large workflow warning past 25 agents or a projected 1.5 million tokens. The warning is advisory and does not pause anything.

Two operational details worth money

A fan-out survives interruption better than one long agent. Workflow resume replays in the order agents started, and “cached results stop at the first agent that didn’t finish, and every agent that started after that one runs again, even if it completed.” Stop a run mid-flight and you lose the unfinished agent plus everything launched after it. Anthropic draws the conclusion themselves: “A workflow that fans work out across many small agents therefore preserves more progress than one long agent.” Granularity is insurance.

Idle teammates do not report their findings. In an agent team, the idle notification tells the lead a teammate stopped — it “doesn’t carry the teammate’s output; a teammate shares results by messaging the lead or updating the shared task list.” A team whose members finish without reporting has spent every token and delivered nothing to the lead’s context. That is not a cost mechanism so much as a way to waste one.

The decision procedure

1. Name the transaction first. Are you slicing one job or multiplying it? If you cannot say, you cannot predict the cost.
2. For a partition, size it by job length and prefix weight. Long and context-heavy: split to 5 or more. Ordinary 30-turn work: 3. Short, or a heavy per-agent startup: keep it in one session.
3. For redundancy, budget N times and ask what the Nth look is worth. It is not overhead; it is what you are buying. Three good angles beat five scattered ones, which is also Anthropic’s advice.
4. Delegate volume, not difficulty, and check the break-even in remaining parent turns before spawning.
5. Put workers on the cheapest model that can do the job. It divides the delegation break-even directly.
6. Keep fan-out agents identical — same model, effort, tools, schema, working directory — so the prefix stagger can do its work.
7. Set subagentPromptCacheTtl to 1h if your workers idle between turns and you are paying per token.
8. Prefer a fork over a subagent when the side task needs what the parent already knows, and a subagent over a fork when it needs volume the parent should never carry.
9. Watch cache_read_input_tokens against cache_creation_input_tokens. In a healthy fan-out, creation is concentrated in the first agent.
10. Don’t reach for agents to make a hard problem easier. At equal budgets that is the one thing the evidence says they do not do.

If you want to run these numbers against your own workload, the LLM API calculator models cache hit rates on the same verified snapshot, the 20x in Claude Code caching covers the per-turn mechanics this piece builds on, and the MCP context tax covers the other half of the prefix — the tool definitions every one of those agents loads. For the tool itself, see our Claude Code pricing breakdown.

Model and assumptions: Opus 5 rates from our snapshot; 20k prefix; 6k tokens appended per turn; 1,500 output tokens per turn; subagent and teammate writes billed at the five-minute rate, main-conversation writes at the one-hour rate. Coordination turns are excluded except where stated. Sources: Anthropic’s agent teams, subagents, workflows, prompt caching and cost documentation; how we built our multi-agent research system; Tran and Kiela, arXiv 2604.02460. See methodology. Checked 27 August 2026.