Single Agents Beat Multi-Agent Swarms at Equal Cost

Teams reach for multi-agent orchestration because parallelism feels like the obvious way to scale an agent, and because a swarm reads well in an architecture diagram. It is rarely the cheapest way to get the accuracy you actually need. A multi-agent system (MAS) is an architecture where several LLM instances, each with its own context and role, collaborate on a task instead of one model handling it end to end.

The intuition is seductive. Split the problem, give each piece to a specialist, run them in parallel, and combine the results. More agents, more coverage, better answer. In practice that intuition skips over a cost that only shows up on the bill and a coordination problem that only shows up in the failure logs. Every agent you add has to be prompted, has to burn tokens, and has to hand its output to something that stitches the pieces back together without contradictions.

Not everyone buys the default. Cognition, the team behind Devin, argued in "Don't Build Multi-Agents" (June 2025) for a single-threaded approach: share full context and full agent traces rather than compressed messages, and avoid splitting decision-making in ways that can conflict, because "actions carry implicit decisions, and conflicting decisions carry bad results." That principle turns out to preview exactly why the equal-budget data came out the way it did. Before you commit to either camp, our breakdown of multi-agent vs single-agent systems covers the conceptual tradeoffs, and the broader AI agents pillar guide maps where swarms sit in the wider landscape.

Stanford's design was simple and, in hindsight, obvious: give the single agent and every multi-agent architecture the same number of reasoning tokens, then compare accuracy. Reasoning tokens (also called the thinking-token budget) are the internal chain-of-thought tokens a model spends working through a problem before it answers. Prior comparisons let the swarm spend as many tokens as it wanted across all its agents, which quietly compares a big compute budget to a small one.

The study spanned three model families, five multi-agent architectures, and two multi-hop benchmarks. Multi-hop reasoning is a task that requires chaining several retrieval-and-inference steps to reach an answer, like resolving one fact in order to look up the next. Here is the full test surface:

One methodological honesty point from the paper is worth flagging: controlling a token budget through an API (as with Gemini 2.5) is harder than controlling it on open weights, and the authors note that loose budget control can inflate apparent multi-agent gains. In other words, some of the swarm advantages reported elsewhere are measurement artifacts, not reasoning wins. That caveat is the whole reason the equal-budget framing matters.

The headline result is blunt: at equal budgets, single-agent systems matched or outperformed multi-agent systems in nearly every condition. According to Stanford's Tran and Kiela (arXiv 2604.02460, April 2026), single-agent systems consistently match or outperform multi-agent systems on multi-hop reasoning when reasoning tokens are held constant. That held across model families, across all five team architectures, and across both benchmarks.

This is where a widely repeated claim needs correcting. The swarm did not lose at every level under every condition, and the paper never says multi-agent "never outperformed." The error analysis found that teams occasionally beat the solo agent, and the Debate architecture was the strongest team setup. According to The Decoder's coverage (Maximilian Schreiner, April 2026), teams cast a wider net in high-corruption or degraded-context scenarios, where a single agent starts to choke on the input. The accurate framing is that at matched compute, one agent wins or ties almost everywhere, and the swarm only edges ahead when it is given more tokens or when the solo agent's context is compromised.

That distinction changes how you read every multi-agent benchmark you see. If a swarm beats a single agent but nobody equalized the token budget, you have not learned that teamwork helped. You have learned that spending more compute helped, which you already knew. The interesting question is always: at the same budget, who wins? For the coordination mechanics that decide whether a swarm even holds together at equal compute, our field notes on multi-agent orchestration that actually works cover the patterns that survive production.

The single-agent edge is not an accident of prompt tuning. Stanford grounds it in the Data Processing Inequality. The Data Processing Inequality (DPI) is an information-theoretic rule stating that post-processing cannot create information: no function applied to data can increase the information it already contains about a target. Once you frame a multi-agent pipeline as a chain of processing steps, the DPI has a sharp consequence.

When you split a task across agents that communicate through compressed messages instead of shared full context, every hand-off is a processing step that can preserve information or lose it, but never add it. The subagent that reads a document and passes a three-sentence summary to the orchestrator has thrown away everything not in those three sentences. A single agent holding the entire context has, in principle, a higher information ceiling than any pipeline that keeps compressing and forwarding. This is the formal version of Cognition's practical advice to share full traces, not just messages: every compression is a chance to drop the one detail the answer depended on.

The DPI also predicts the exception cleanly, which is what makes it a good model rather than a slogan. Multi-agent becomes competitive when a single agent's effective context utilization is degraded, or when more compute is expended. If the input is so large or so noisy that one agent cannot actually use all of it, splitting the work so each agent gets a clean, digestible slice can recover information the overloaded solo agent was losing anyway. That is the same regime where degraded-context scenarios favored the Debate architecture in Stanford's own error analysis. The information you lose to compression across agents can be worth it only when you were already losing more information to overload in a single window. How you design those hand-offs decides how much you lose, which is the entire subject of AI agent communication patterns for multi-agent systems.

Multi-agent systems run about 15x the tokens of a chat interaction, versus about 4x for a single tool-using agent (Anthropic, 2025). That is the real overhead, and it is worth stating up front because the most-cited "production numbers" for the swarm tax are fabricated. Figures like a precise 4.3x to 4.6x token overhead, a 47-deployment survey finding 68% of systems overbuilt, or a customer-service case running $47K a month against a single-agent $22.7K do not appear in any primary source. They surface only on SEO content farms and should not anchor a budgeting decision. Use the measured figures instead.

According to Anthropic (2025), agents typically use about 4x more tokens than chat interactions, and multi-agent systems about 15x more. That is the real, citable overhead. A single tool-using agent already costs roughly four times a plain chat because it reasons across multiple tool calls; a swarm costs roughly fifteen times a chat because it does that reasoning in several parallel agents at once. The second, independent data point comes from the illusion paper: according to "The Illusion of Multi-Agent Advantage" (arXiv 2606.13003, June 2026), automatically generated multi-agent systems consistently underperformed a Chain-of-Thought self-consistency baseline despite being up to 10x more expensive, with the authors concluding that automated design paradigms produce "architectural bloat."

Two studies, two methods, one direction. Held at equal budget, the swarm does not reason better; run at its natural budget, it costs multiples more. Across the production agent systems we audit at Particula Tech, the token line item for a poorly justified swarm is almost always the largest and the least examined, precisely because it is invisible on a dashboard that tracks only completion tokens. If your agent bill is climbing as you add agents, the discipline in our guide to reducing LLM token costs through optimization applies before you scale the swarm, not after.

Multi-agent systems still earn their keep on high-value tasks with heavy parallelization, information that exceeds a single context window, and many complex tools. This is the boundary condition, and it is where the swarm tax buys something real. According to Anthropic (2025), a multi-agent system with a Claude Opus 4 lead and Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on its internal research eval, which is a large lift, not a rounding error.

Notice what that win case has in common with Stanford's DPI exception. Open-ended research pulls in more source material than one context window can hold, so a single agent is already in the degraded regime the DPI warns about. Splitting the reads across subagents, each with a clean context, recovers information the solo agent would have lost to overload. The gain is real, but it comes from the task structure, not from teamwork as a general principle. The moment the sub-tasks stop being separable, or the information fits one window, the advantage collapses back into pure token overhead.

The mechanics of getting parallel exploration to actually pay off (fan-out, fan-in, and the latency math of running agents concurrently) are their own engineering problem, which we cover in DAG agent orchestration and fan-out/fan-in latency. If you are going to pay the swarm tax, the least you can do is spend it on genuinely parallel reads rather than a sequential chain wearing a multi-agent costume.

The recommendation is direct: default to a single well-instructed agent, give it the full context and the right tools, and only escalate to a multi-agent swarm when the task provably exceeds what one loop can hold. Reach for the swarm to solve a measured problem (context overflow, genuinely parallel reads, a valuable task where budget is not the constraint), never as the default architecture. Use this table as the gate.

If most rows point left, you are looking at a single-agent problem, and adding orchestration will cost you roughly 15x the tokens to buy accuracy you could have gotten from better tools or a longer loop. Skip the swarm. Fix the single agent first: sharpen the prompt, widen the context you actually pass, and instrument the tool calls. Most of the swarms we are asked to review turn out to be a single agent's job that was split before anyone checked whether splitting helped, and the equal-budget data is now the citation that makes that argument for you.

This is exactly the judgment we pressure-test in Particula Tech's agent architecture audits: not "can we build a swarm" but "does this task earn one," before you commit to the token bill and the coordination complexity. Match the budget, apply the DPI test, and let the task structure, not the architecture diagram, decide how many agents you run.