Subagents made a Claude Code investigation 54% slower and 2.2x pricier, and Anthropic says fold them back
Anthropic advises opening fewer subagents: measured split into 3 parallel agents ran 54% slower and cost twice as much
Investigating the same cross-file code problem in Claude Code, I let the main agent investigate on its own: average 93 seconds and $0.87. Letting it split the work across three parallel subagents and then summarize: average 143 seconds and $1.92. The core conclusions from all four answers were identical.
On October 22, Anthropic's Applied AI team published an article titled 'When to fold subagents into your main agent loop,' and its conclusions point in the same direction: in most scenarios, one main agent plus skills and tools loaded on demand is not worse in quality than a subagent architecture, and cost and latency are often lower. The original post gives a customer case where switching from a multi-agent architecture to a single-agent loop made the run about 2 times faster.
This article first lays out the original post's conclusions and mechanisms, then gives my 4 local controlled experiments and Quickchat's code review test on 20 PRs, then lists the three situations where the original still recommends subagents, and finally lands on concrete usage in Claude Code.
Parallel subagents sound like a speedup, but each additional subagent adds one more system prompt, one more round of code reading, and one more step where results are compressed into a summary and handed back. After receiving the summary, the main agent usually feels the need to verify it again. All of these costs are billed per token, and they often eat up the time saved by parallelism. Whether to split should be decided by whether the context can no longer hold the work, not by whether the task looks 'parallelizable.'
Anthropic's original conclusion: single agent plus skills is often better
The original author is Anthropic's Diane Sarkis, and the article is aimed at teams building agents inside enterprises. The core recommendation is to fold specialized subagents back into the main loop through 'progressively disclosed context via skills' and 'progressively disclosing tools via tool search.'
Three pieces of evidence in the original:
- One customer comparison: on the same set of tasks, a single-agent loop ran about 2 times faster than a multi-agent architecture.
- A comparison across several enterprise deployments: a single agent with skills often beats both 'one big prompt that does everything' and 'subagent architecture' in quality, and cost and per-task latency are also often lower. The original gives no specific numbers here.
- Claude Code's own example: Anthropic trimmed Claude Code's system prompt for stronger models by more than 80%, and part of that came from changing skills and tools to progressive disclosure.
The original also mentions a change in model capability: 'Starting with Opus 4.5, models became capable of managing far more in a single loop than most teams expected.' In the past, the main reason to split out subagents was that one context could not hold all the domain knowledge. With progressive disclosure, the main agent only loads a skill's full content when it needs it, and that reason becomes much weaker.
The cost of subagents is in the handoffs
The original's criticism of multi-agent architectures focuses on handoffs. Teams have to decide what context gets passed between subagents, and details 'often lose details in the back and forth.' In long tasks, keeping the results of each previous step in the main window lets the main agent connect them together, and that works better than a set of summaries handed back by subagents.
Organizational problems are even more common. The original directly calls the phenomenon of architecture turning into an organization chart Conway's Law: every team ships its own subagent, and eventually a company has hundreds of subagents with overlapping functions, no unified standard, and no clear owner. Every team adds a sentence to the system prompt, and the result is a 'Frankenprompt' full of conflicting rules. One company's customer-facing agent had a dozen specialized subagents, making brand voice difficult to unify and increasing latency.
Tool count is another concrete tipping point. The original writes that once tool definitions in the system prompt exceed 30 to 50, the model's tool-selection accuracy drops. It recommends grouping tools by user intent rather than mapping one API to one tool.
Local 4-run comparison: splitting into 3 subagents was 54% slower and 2.2x the cost
To verify this conclusion in a personal-use scenario, I ran a controlled comparison locally with Claude Code 2.1.304 (Opus 5.5, default medium effort). The repository is a copy of the open-source project cc-statistics, with about 95 Python files, plus a macOS App written in Swift and a Web panel.
The task is a typical cross-directory investigation: list all functions in the repository that calculate dollar-denominated fees, explain whether each function calls the unified price table pricing.py or wrote its own pricing logic, whether it counts cache read and cache write, and point out inconsistencies. I manually checked the standard answer beforehand. The two most important spots are: git_integration.py hardcodes Sonnet's unit price and completely ignores cache write; and the Swift App contains a second hand-copied price table.
Each approach ran twice, all with claude -p --output-format json and read-only tools only:
- Single agent: the prompt says not to use the Agent tool, and to investigate by itself with Read, Grep, and Glob.
- 3 subagents: the prompt says to first launch 3 Explore subagents in parallel, divide the work by directory, and summarize after all of them return.
| Single agent | 3 subagents in parallel | |
|---|---|---|
| Wall-clock time | 102 sec / 84 sec | 138 sec / 149 sec |
| Cost | $0.98 / $0.77 | $1.84 / $2.01 |
| Output tokens (incl. subagents) | 7,592 / 7,051 | 24,178 / 28,301 |
| Cache write tokens | 86K / 65K | 197K / 208K |
| Found git_integration hardcoded unit price | 2/2 | 2/2 |
| Found second Swift price table | 2/2 | 2/2 |
On average, the subagent approach was 54% slower and 2.2x the cost of the single agent, and output tokens were 3.6x higher. Answer quality did not pull ahead: all four runs found the two key problems, and the differences were only minor inconsistencies in reporting.
The added cost is visible in the output. In both subagent runs, before summarizing, the main agent wrote things like 'I also spot-checked a few key conclusions' and 'I verified the key spots against the source code again,' meaning that after the subagents already read the code, the main agent re-read the key files to confirm the summaries were reliable. The three subagents each loaded their own system prompt and tool definitions, which shows up as roughly double cache writes.
There is also an easy timing trap: in the JSON output of claude -p, the duration_ms for the subagent approach was only about 30 seconds and did not include the subagents' runtime. To compare the wall-clock time of the two approaches, use a stopwatch.
These experiments have a small sample size, only 2 runs per group, and cover only a read-only investigation task; they cannot be directly generalized to code-writing tasks. What they can show: for an investigation question in a medium-sized repository that fits entirely in the main context, splitting into subagents bought neither speed nor quality.
Quickchat's 20 PRs: code review at max tier cost 188 times more
Another larger data set comes from Quickchat AI's Mateusz Jakubczak (October 21). He used 20 PRs from the Martian Code Review Benchmark (from Sentry, Grafana, Cal.com and others, with 27 severe or critical issues in total) to compare Claude Code's /code-review at high and max tiers. According to his observation, high is one agent going through 8 review angles sequentially, while max is about 10 finder subagents running in parallel plus a verifier and a summary round; the Claude Code official documentation does not say how many agents each tier uses.
| Sonnet 5.5, 20 PRs | high (single agent) | max (multi-agent) |
|---|---|---|
| Severe issues found | 21/27 | 23/27 |
| All issues found | 47/65 | 47/65 |
| Extra reports per PR | 11.9 | 23.9 |
| Time per run | 40 sec | 56 min |
| Cost per run | $0.11 | $20.95 |
| Total cost for 20 PRs | $2.12 | $398.03 |
The multi-agent run found 2 more severe issues, at 188x the cost, more than 80x the time, and double the noise. In one extreme case, a max run using Opus for everything with no budget limit spent $40.64 on a 97-line PR, hit the 30-minute timeout, and produced no output at all.
This data needs caveats. The author's company builds Quickchat Review, a competing product, and the article discloses this; each configuration ran only once; the 20 PRs were selected; and quality was judged by only two LLM judges, who agreed on only 56% of matchups. The author's own recommendation is to use /code-review high for most PRs.
Three situations where subagents still make sense
The original does not reject subagents; it gives three clear conditions for keeping them:
- The single-agent loop shows measurable performance degradation because the context has grown too large.
- Several tasks need to run in parallel, and each task needs a new context window that can be discarded after use.
- The single agent cannot select tools accurately, or the system prompt contains conflicting instructions.
Claude Code itself has an example that fits condition 2. The official documentation says the local /code-review runs as a background subagent with its own context window, 'so it doesn't fill your conversation.' The large amount of code read during review does not stay in your main conversation, and that is exactly where subagents belong.
For teams migrating back from multi-agent architectures, the original gives this order: first build an end-to-end eval; 10 standard examples are enough to start. Prioritize merging subagents that call each other, share data, or are often invoked together. During the transition, the main agent can call a subagent as a tool. Then fold them one by one: turn a subagent's prompt into a skill, turn the APIs it calls into MCP tools, and compare the eval after each fold.
The original also records a failure: after merging one subagent in an example customer-service agent, latency dropped, but a previously passing flow broke. The main agent had a tool to look up orders and answered on its own, so it never asked the delivery specialist for the delivery date. That is why the eval should cover every agent chain that runs together in production and every rule that cannot be violated, and each task should be run more than once.
How to use subagents in Claude Code
| Scenario | Approach | Basis |
|---|---|---|
| Investigation or change in one repository, context fits | Let the main agent do it; do not prompt it to 'start a few agents in parallel' | Local measurement: parallel was 54% slower, 2.2x the cost, same quality |
| Need to scan many files, but only the conclusion is needed | Use a subagent; let it read and return only the conclusion | Original condition 2; large file contents do not fill the main context |
| Several unrelated tasks need to run at the same time | Use subagents in parallel | Original condition 2 |
| A class of work has fixed steps and judgment rules | Write it as a skill, not as a dedicated subagent | Original: skills encode 'how a team does work' |
| More tools or MCP servers are being added | Merge tools by intent and keep the count under 30 to 50 | Original: tool-selection accuracy drops beyond that |
| Code review | Start with /code-review high; consider higher tiers for important PRs | Quickchat: max cost 188x more, found 2 more severe issues |
The only decision criterion is whether the main agent's context really cannot hold the work, or whether the work really needs a disposable independent context. When neither is true, a subagent split just re-reads code, rewrites summaries, and makes the main agent verify everything a second time. Time and money are spent twice.