Multi-agent research systems burn ~15x the tokens of a chat — when does that pay?

## Where the numbers come from Anthropic published figures for their multi-agent research system that are now the standard reference point in interviews: ordinary agents consume roughly 4x the tokens of a chat interaction, and multi-agent systems roughly 15x. In the same work, a multi-agent configuration — a stronger orchestrator delegating to several workers — outperformed a single-agent baseline by about 90% on their internal research evaluation. Take both halves seriously. Quoting the 15x as a reason never to build multi-agent is as shallow as quoting the 90% as a reason always to. The premium is structural, not an implementation defect. Every worker re-pays for its own system prompt, its tool definitions and its task brief. The orchestrator pays to write those briefs and again to read the summaries back. Coordination turns — deciding what to spawn, deciding whether the results suffice, deciding to spawn more — are pure overhead that a single agent never incurs. ## The three-part breakeven test **Read-heavy.** The subtask must consume far more than it reports. A worker that reads sixty documents to produce a paragraph is compressing roughly 50:1, and that compression is exactly the product you bought. A worker that fetches one record and passes it along compresses nothing; you have paid for a full extra loop to achieve a function call. **Parallelizable.** The subtasks must be genuinely independent. When they are, you spend more tokens but less wall-clock time — five workers running concurrently finish in roughly the time of the slowest, and users experience the system as faster despite the higher bill. When the subtasks are sequential, you pay the premium *and* the latency, which is the worst of both. **Independently verifiable.** You must be able to tell whether a worker's finding is correct without redoing its work — a citation you can check, a test that passes, a number you can recompute. This is not a nicety. Multi-agent systems fail in compounding ways: a worker's confident but wrong summary is indistinguishable from a right one at the orchestrator, and it then contaminates the synthesis. Without a verification signal you cannot evaluate the system, cannot debug a bad run, and cannot safely let it run unattended. All three must hold. Two out of three is usually a signal to build a workflow — fixed code fanning work out to model calls — rather than a delegating orchestrator. ## The workloads that pass, and the ones that do not **Passes**: literature and prior-art review across disjoint source sets; broad market or competitor scans; large-codebase comprehension where several areas can be read in parallel; any breadth-first search where you do not know in advance which branch holds the answer. These share a signature: high fan-out, cheap-to-check outputs, no single ordering. **Fails**: high-volume per-request work where unit economics decide viability — a classification or routing endpoint served millions of times cannot absorb a 15x multiplier, and rarely needs one. Latency-critical interactive completion, where an extra orchestration hop is felt directly. Tightly coupled sequential work, where each step needs the previous step's full context and splitting it merely starves every worker. ## Economics beyond the raw multiplier The headline multiplier is not the whole cost picture, and a principal-level answer says so. *Mixed model tiers.* A strong orchestrator over cheaper workers changes the blended rate substantially, since most tokens are burned by workers doing bulk reading. *Prompt caching.* Workers that share a stable system prompt and tool block can hit cache on the invariant prefix, and cached input is materially cheaper than fresh input. This is a real lever on the fixed per-worker overhead. *Value per query.* A 15x multiplier on a query worth cents is fatal; on an analyst-hours-replacing research task it is trivial. Always convert the multiplier into currency against the value of the answer before arguing about it. *Failure cost.* Multi-agent runs fail later and more expensively than single calls — you find out after five workers have finished. Budget for the retries, and cap total spend per task rather than trusting the design to be well-behaved. ## How to decide in practice Do not begin with the multi-agent architecture. Start with the simplest thing that could work — a single call, then a fixed workflow, then a single agent with good context hygiene (compaction, offloading tool output by reference). Escalate only when you have measured a specific failure that isolation addresses. Then run the multi-agent version against the single-agent baseline on your own task distribution, measure quality, cost and latency together, and keep the split only where the quality delta justifies the bill on *your* workload. Published multipliers describe someone else's system; the decision has to be made on your numbers.