Key facts.
- Multi-agent is a token amplifier by design: Anthropic's orchestrator-worker research system used about 15 times the tokens of a chat and roughly 4 times a single agent (Anthropic,How we built our multi-agent research system, 2025).
- The spend buys real capability on the right task: that system beat a single Claude Opus 4 by 90.2% on breadth-first research, and token usage alone explained about 80% of the performance variance (Anthropic, 2025).
- More agents aren't free coordination: each sub-agent re-processes its own full context and tool loop, and the orchestrator pays again to brief and synthesize them, which is where the multiplication comes from (Anthropic, 2025).
Why does multi-agent cost so much more?
Because every sub-agent is a full agent, not a cheap helper. When an orchestrator spins up workers, each one loads its own context window, runs its own tool-use loop, and generates its own reasoning trace. The per-token work is replicated across all of them in parallel. On top of that, the orchestrator pays to brief each worker, and pays again to gather and synthesize their results. The bill isn't the single-agent cost plus a little overhead. it's roughly single-agent cost times the number of workers, plus coordination. Anthropic measured this: their research system ran at about 15 times the tokens of a normal chat and around 4 times a single agent. The multiplication is structural, not a tuning problem.
What do you get for the 15x?
On the right task, a large capability jump. The same Anthropic system beat a single Claude Opus 4 by 90.2% on breadth-first research, the kind of task where you need to explore several independent directions at once and a lone agent is the bottleneck. Token usage alone explained about 80% of the performance variance, meaning most of the gain came from spending more tokens across parallel exploration. that's the honest trade: multi-agent converts a large token budget into breadth and depth a single agent can't reach in one pass. When the task is genuinely broad and high-value, the spend is justified.
when's multi-agent not worth it?
When the task isn't broad, which is most of the time. Cognition's analysis argues that for the majority of agent tasks, splitting work across agents fragments context and creates more coordination failures than it solves, and that a single-threaded agent is the more reliable default. The economics agree: if a task doesn't need parallel breadth, the extra agents mostly re-do work and inflate the bill without buying capability. Multi-agent earns its 15x on open-ended research and broad exploration. For a linear task or a routine workflow, the multiplier is pure cost.
How do you keep the bill sane?
| Lever | What it does |
|---|---|
| Default to one agent | Use multi-agent only for genuinely broad, high-value tasks |
| Cheaper models for workers | Run sub-agents on a smaller model; reserve the big model for the orchestrator |
| Bound the fan-out | Cap how many workers spawn; more agents is not more answer |
| Compress handoffs | Pass summaries, not full transcripts, between orchestrator and workers |
| Cache shared context | Cache the common prefix so workers do not each re-pay for it |
| Measure value vs cost | Track tokens per task against the task's worth, and kill the pattern where it loses |
Default to one agent and reserve multi-agent for genuinely broad, high-value tasks. Run sub-agents on a cheaper model and keep the big model for the orchestrator. Cap how many workers spawn; more agents isn't more answer. Pass summaries between orchestrator and workers rather than full transcripts. Cache the shared prefix so workers don't each re-pay for it. Track tokens per task against the task's worth. VibeModel builds the layer that tracks which tasks deserve the multiplier and which are paying it for nothing, which is the Pattern Intelligence Layer.
Frequently asked questions
Isn't multi-agent just better?
Only on the right task. It beat a single agent by 90.2% on breadth-first research, but that's the case it's built for. On linear or routine tasks it mostly re-does work and inflates cost, and a single-threaded agent is more reliable.
Why does it cost 15x and not 2x?
Because each sub-agent re-processes a full context and tool loop in parallel, and the orchestrator pays to brief and synthesize on top. The cost scales with the number of workers plus coordination, not with the size of the task.
When should I actually use multi-agent?
When the task is broad enough to need several independent lines of exploration at once, and valuable enough to justify the token spend. For anything one agent can do in sequence, stay single-agent.