Every benchmark where the swarm beats the lone agent shares one rigged variable: nobody held the budget constant. The orchestra got five model instances, recursive sub-agents, and a token allowance fat enough to choke a context window — then "won" against one agent running on a fraction of the compute. That's not a result. That's a heavyweight fighting a flyweight and issuing a press release. The entire case for orchestration evaporates the moment both sides spend the same.
Someone finally ran the fair fight. The result should make you delete half your roadmap.
The fair fight nobody wanted to run
Tran & Kiela at Stanford (arXiv:2604.02460, April 2026) did the obvious thing everyone skipped: hold the thinking-token budget equal across single agents and multi-agent systems, then measure multi-hop reasoning on Qwen3, DeepSeek-R1, and Gemini 2.5. Under equal compute, the soloist matched or beat the swarm. At a 1,000-token budget the single agent scored 0.418 against the multi-agent system's 0.379. The orchestra wasn't smarter. It was richer.
Anthropic's own engineering numbers corner the same conclusion from the opposite side. On their BrowseComp evaluation, token spend alone explained 80% of the performance variance. Eighty percent. The architecture you spent three weeks wiring — the routers, the planners, the critic agents — fights over the remaining twenty, and most of that is model choice and tool calls, not orchestration. You didn't build intelligence. You built a costlier checkout counter for the same tokens.
So when a paper reports "our multi-agent system outperformed the baseline," translate: our system that spent 15x the tokens beat the one that didn't. Naturally.
The tax, itemized
Call it what it is — a tax. Here's the bill.
Tokens: 4x to 15x. Anthropic measured it. A plain agent burns roughly 4x the tokens of a chat turn. A multi-agent system burns ~15x. That multiplier isn't a worst case you can engineer away; it's the cost of admission for seating an orchestra instead of a soloist.
Latency: stacked and invisible. Each agent handoff costs ~100–500ms of pure coordination. A four-agent pipeline piles up ~950ms of orchestration against maybe 500ms of actual work — more than half your wall-clock is the orchestra tuning up before anyone plays a note. Your user watches a spinner while three agents negotiate who owns the task.
Tail risk: unbounded. The 15x is the floor, not the ceiling. A sub-agent that recursively spawns sub-agents, or a tool that dumps an oversized payload into three parallel contexts at once, can multiply one query's cost by another order of magnitude. A single-agent design has no such blast radius — there's no recursive spawn to run away from you at 2 a.m.
Error compounding is the line item nobody prices
Reliability multiplies, and multiplication is merciless. A 20-step pipeline where each step is 95% reliable succeeds end-to-end just 36% of the time — 0.95^20 ≈ 0.358. That's only sequential decay. Multi-agent stacks a second failure surface on top: coordination. Production multi-agent systems fail at rates between 41% and 86.7%, and the failures aren't dumb models flubbing facts — they're role misinterpretation, duplicated work, and skipped verification steps. New failure modes, not louder versions of the old ones.
Cognition named the exact mechanism in "Don't Build Multi-Agents" (June 2025). Their Flappy Bird example is the whole argument in one image: spin up two parallel sub-agents to build a game, and one returns a Super Mario-style background while the other returns a bird sprite in a clashing art style. Neither agent was wrong. Each acted on unstated, conflicting assumptions — and the orchestrator inherits "the undesirable task of combining" two miscommunications into one artifact. Their two rules belong above your desk:
- Share full agent traces, not just the final messages.
- Every action carries an implicit decision; conflicting decisions compound.
A single agent cannot disagree with itself about the art style. The entire bug class ceases to exist.
The swarm-builders won't use it for your job
Here's the part that should end the argument for anyone shipping code. The people building agentic coding tools — the ones who would love to sell you a swarm — explicitly tell you not to use one for coding.
Anthropic, in the very post the swarm crowd cites for its 90.2% headline, says plainly that most coding tasks "involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating in real time." Claude Code is single-threaded by design. Its sub-agents exist only to answer discrete, bounded questions — what does this function return, where is this symbol used — and are explicitly barred from making architectural decisions. The most-used agentic coding tool on the market refuses to be a swarm.
Sit with that the next time someone pitches a five-agent "engineering team": planner, coder, reviewer, tester, orchestrator. The vendor with more agentic-coding telemetry than anyone alive looked at that exact org chart and shipped one agent with a tight scope instead.
Before you reach for orchestration, write the prompt
The honest reframe: most of what people solve with a second agent, a better-scoped first agent already handles. The "researcher → writer" handoff is usually one agent whose context just needed assembling properly. The "critic agent" is usually a verification step that belonged in the system prompt. You're paying a coordination tax to dodge the harder, cheaper work — writing one good prompt with the right tools bolted on.
The default that survives the evidence is single-threaded. Reach for a sub-agent the way Claude Code does: to answer a bounded question and hand back a fact, never to delegate judgment.
# The decision rule
parallelize ONLY when:
subtasks are TRULY independent # no shared context to reconcile
AND task_value > token_cost # the 15x is absorbed by the payoff
else:
one well-scoped agent
Where the tax actually pays
This isn't anti-multi-agent for clicks. A real envelope exists where the 15x earns out — and it's narrow, drawn by independence and value, not by sophistication.
- High-value, embarrassingly parallel research. When threads are genuinely independent — legal due diligence, competitive intelligence, biomedical literature review — Anthropic's multi-agent setup beat single-agent Opus 4 by 90.2%. The value absorbs the token bill, and the subtasks never have to reconcile a shared art style.
- Breadth that overflows one context window. Real volume with low interdependency: fan it out because it physically won't fit, not because parallel sounds impressive.
- Many complex, independent tool surfaces one agent can't juggle coherently.
- An already-degraded single-agent context. Stanford found the crossover where multi-agent wins only under heavy corruption — around 70% masking or substitution noise. Read that carefully: the swarm pulls ahead precisely when the single agent's context is already broken. That indicts your context pipeline; it doesn't endorse the swarm.
Notice what unites the list: truly independent subtasks and value that dwarfs token cost. Coordination-heavy, shared-context work — which is most dev work — fails both tests at once.
The two posts everyone frames as enemies agree
Here's the tell. Cognition's "Don't Build Multi-Agents" and Anthropic's "How we built our multi-agent research system" get cited as opposite poles of the debate. They aren't poles. They converge on one rule: single-threaded by default; multi-agent only for high-value, low-dependency, parallelizable work. Simon Willison, reading the Anthropic system as a sympathetic skeptic, lands in the same spot.
There is no real disagreement among the people who actually build these systems. The "agent swarm" trend is the entire gap between that narrow, boring rule and how broadly orchestration gets sold to you. The hype lives in the delta.
So before you stand up an orchestrator, a message bus, and five role-played agents to ship a feature, try the thing the evidence keeps pointing at: one agent, scoped well, with the right tools and a verification step in the prompt. It's cheaper, it's faster, it can't miscommunicate with itself — and on most real dev tasks, it wins the fair fight. Make the swarm earn its 15x. It usually can't.