Single Agent vs Multi-Agent: When to Split a Task, With a Decision Checklist and Cost Math

Single agent vs multi-agent comes down to one question. Can the work be cut into pieces that do not need each other's results? If yes, and the task is worth several times the tokens, split it. If the pieces share decisions, such as one plot, one codebase or one brand voice, keep one agent and give it better tools.

The evidence supports both camps. Anthropic reported in June 2025 that a lead Opus 4 with Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on its internal research eval. In the same post it said multi-agent runs use about 15 times the tokens of a chat. A Google and MIT study found +80.8% on a decomposable finance task and as much as -70.0% on sequential planning.

Disclosure: Oakgen is our product. This is an infrastructure topic and I ran no benchmarks of my own. Every number below carries its publisher and date, and I say whose measurement it is.

The short version

Who this is for

You are building or buying an agent workflow and someone proposes "a team of agents". Or your usage meter moves faster than your work does. You want a rule you can apply before spending the tokens.

If you want the mechanics of each pattern first, read agent orchestration patterns explained. For budget caps and effort settings, see agent orchestration cost control. This post is about the earlier question of whether to split at all.

How I checked this

As of November 12, 2026, I opened Anthropic's multi-agent research post, its Building effective agents post, the Fable 5.2 launch page, the help article on Fable launch offers, the Claude Code cost docs and the pricing page. I also read both Cognition posts, the Google and MIT paper (arXiv v3) with its Google and MIT summaries, and the MAST failure study.

Limits matter here. Anthropic's 90.2% figure is a vendor-run internal eval from June 2025 on Claude 4 era models, not an experiment you can rerun. The MAST study used older models and open-source frameworks. I ran no agents.

What Anthropic measured, and what it did not

Anthropic's post describes an orchestrator-worker design. A lead agent plans, spawns subagents that search in parallel, and passes everything to a citation step. The numbers I would keep are these.

• 90.2%. A lead Claude Opus 4 with Claude Sonnet 4 subagents beat single-agent Claude Opus 4 on Anthropic's internal research eval. Anthropic says the gain is largest for breadth-first queries with several independent directions.
• 80% of variance. On BrowseComp, three factors explained 95% of performance variance, and token usage alone explained 80%. Anthropic's reading is that multi-agent systems work mainly because they spend enough tokens to solve the problem.
• 4 times and 15 times. Agents typically use about 4 times more tokens than chat, and multi-agent systems about 15 times more, in Anthropic's data.
• Up to 90% less time. Running 3 to 5 subagents in parallel and giving each 3 or more parallel tool calls cut research time by up to 90% on complex queries.

Then the caveats Anthropic wrote itself. The task must be valuable enough to pay for the extra tokens. Domains where agents share one context or have many dependencies are a poor fit today, and most coding has fewer parallelizable pieces than research. Early versions spawned 50 subagents for simple queries, and vague instructions led two subagents to duplicate the same search.

Notice what the 90.2% does not say. The post does not say the single agent got the same token budget, and Anthropic itself says multi-agent systems work mainly because they spend enough tokens. If the lesson is "spend more tokens on hard problems", splitting is one way to spend them, not the only way.

What independent and rival evidence says

Cognition published its counter-argument on June 12, 2025, a day before Anthropic's post.

The Google and MIT paper adds three findings worth keeping. Above roughly 45% single-agent success on those benchmarks, adding agents predicted zero or negative gains, and the authors call that an empirical rule, not a universal cutoff. Independent systems amplified trace-level errors 17.2 times against 4.4 times for centralized ones, and the MIT summary warns that these do not mean answers were 17.2 or 4.4 times more likely to be wrong. SWE-bench Verified showed small declines for every multi-agent variant, from -2% to -15%.

Two cautions. The Google and MIT study matched total token budgets across single and multi-agent systems, while Anthropic's multi-agent system simply spends more tokens, so the two answer different questions. And the Google Research blog from January 2026 describes 180 configurations where the later arXiv version says 260. I cite the paper.

One more disagreement. Anthropic says multi-agent systems excel at interfacing with numerous complex tools. The Google and MIT paper found that tool-heavy tasks carry coordination overhead, though the MIT summary says that interaction lost statistical significance after accounting for benchmark clustering. Treat tool count as a warning to test, not as a reason to split.

Where splitting pays

Four situations show up repeatedly in the sources.

Breadth-first reading. Many independent searches, each of which can fail or be redundant without corrupting the others. Anthropic's example was finding the board members of every company in the S&P 500 IT sector, which a single agent failed with slow sequential searches.

Context that will not fit. A subagent has its own window and returns only condensed findings. Anthropic calls search compression, and Claude Code's docs suggest delegating test runs, documentation fetches and log processing so the verbose output stays out of the main conversation.

A fresh pair of eyes. Cognition found its review agent works best when it shares no context with the coding agent, because a clean context lets it reason backward from the diff. The writer stays single-threaded.

Cheaper workers. Anthropic's launch post says Fable 5.2 can act as an Orchestrator that delegates simpler tasks to smaller models, and Claude Code's docs say you can set a subagent to a smaller model such as Haiku. Here splitting can lower cost per task, because the expensive model reads summaries instead of raw pages.

At the far end, Anthropic reports that 1,000 Fable 5.2 agents formalized the proof of Fermat's Last Theorem in 30 hours, while Opus 5.5 in the same setup completed 26% in 18 hours. That is Anthropic's own run, one run per model, on a task with a machine-checkable finish line. Cognition notes that the famous swarm demos share a simple, verifiable success criterion most real work lacks.

Where splitting fails

Shared decisions. Cognition's two principles are to share full context and to remember that actions carry implicit decisions. Two subagents asked to build a game background and a bird will choose different art styles. The same happens with two agents writing two halves of a script.

Sequential work. Google and MIT's PlanCraft traces show a centralized system splitting a three-step crafting task into research, inventory and execution agents, where the single agent just looked up the recipe and crafted. The messages consumed the budget.

Vague delegation. Anthropic found short instructions like "research the semiconductor shortage" produced duplicated searches. Each subagent needs an objective, an output format, tool guidance and clear boundaries.

Missing verification. The MAST study groups failures into system design, inter-agent misalignment and task verification. Its authors say explicit verifiers help but are not a silver bullet.

Lossy handoffs. Anthropic's appendix suggests subagents write outputs to files and pass back references, to avoid a game of telephone through the lead.

The Fable 5.2 sub-agent usage burn, and what is verified

Our community reactions post sorted the launch-week complaints, and this theme held up best. I do not go beyond what it verified.

• Anthropic's help article says "Fable models use your usage limits faster than other Claude models." I re-read it on November 12, 2026.
• SemiAnalysis reported from its run logs that Fable 5.2 writes hundreds or even thousands of test cases where Opus 5.5 and Fable 5.1 stopped at about 20, and is more eager to launch subagents for independent re-derivation and auditing.
• A Hacker News user said it will spin up Fable subagents and burn through usage quickly unless you tell it how to use them. That is one account.
• Nobody I found measured plan-limit percentage in a controlled way. The reports are self-measured.

Claude Code's docs add the general mechanics. Every subagent sends its own requests on top of the main conversation's, and a subagent's requests still draw on your usage. The /usage command shows the subagent share of your recent usage. The docs also say agent teams use approximately 7 times more tokens than standard sessions when teammates run in plan mode.

So the honest chain is this. Fable models use limits faster per Anthropic, each subagent adds requests, and a model that delegates eagerly multiplies both effects. The size of the effect for your workload is unknown until you read your own /usage breakdown. One dated detail. The help article says Pro plans and standard Team seats get Fable included at up to 50% of weekly limits through November 16, 2026, 11:59 pm Pacific, so the economics may change after that.

The split-or-not checklist

This is the original asset. It combines two gates, five fit questions and five stop signs, built from the sources above. It is my synthesis, not a published standard, and the thresholds are judgment calls.

Gates. Both must be yes, or stay with one agent.

1. A single agent with good tools and a clear prompt has been tried on about 20 real tasks and fell short on quality, context or time. Anthropic says small samples are enough early on.
2. The task is worth several times the tokens. Anthropic says economic viability needs a task value high enough to pay for the extra performance.

Fit questions. Count the yes answers.

3. Can the work be cut into pieces where no piece needs another's result?
4. Is it mostly reading (search, review, summarizing), with one agent writing the final output?
5. Would the combined material overflow one context window?
6. Would a cheaper model handle the pieces well enough?
7. Do you need a reviewer that has not seen the author's reasoning?

Stop signs. Any yes means stay single, or split reads only.

8. Do the pieces share decisions about style, schema, naming, plot or brand voice?
9. Is it a short chain where each step needs the last step's output?
10. Does a single agent already succeed more than roughly 45% of the time on this kind of task? Google and MIT found gains vanish above that level on their benchmarks, so it is a prompt to test, not a law.
11. Are you on a plan with a usage limit you cannot see in tokens?
12. Can you not trace what each subagent did?

Scoring. Pass both gates, hit no stop sign, and answer yes to at least three fit questions, and a lead with parallel read-only subagents is justified. Hit stop sign 8 or 9 and the answer is one agent. Hit 11 or 12 and fix the visibility first.

A worked cost illustration, with hypothetical inputs

Everything in the token columns below is invented to show the arithmetic. The prices are real. They are Anthropic's list prices per million tokens, read on November 12, 2026, with no caching or batch discount.

The hypothetical task. Summarize how 12 competing brands position their short-form video ads, then propose three angles.

• Single agent. 300,000 input tokens summed across all its turns, because history and tool results are resent, and 40,000 output tokens.
• Split version. Six subagents each read two brands, at 150,000 input and 20,000 output tokens each. The lead uses 120,000 input and 25,000 output tokens.

All three split setups use 3.4 times the tokens of the single agent. That ratio is close to the 3.75 you get by dividing Anthropic's 15 times by its 4 times, which is arithmetic on two averages and not a measurement of any task. What changes the bill is which model the subagents run on. Setup D is the expensive shape, and setup E shows why a smaller worker model is the main lever.

Now the question that matters, cost per success. Divide cost by the share of runs that succeed. These success rates are also hypothetical.

The rule is simple. Splitting pays only when the success rate multiplies by more than the cost ratio, here 1.99. That is a high bar on tasks one agent already handles, and an easy one on tasks it cannot finish at all. Plan limits are not published as token counts, so I cannot turn this into a percentage of any plan.

How a creative team would apply this

A campaign has a read-heavy front and a write-heavy back. Researching competitor ads, pulling reference footage notes and auditing last quarter's winners are independent reads, so they are candidates for parallel subagents. The script, the brand voice and the shot list are one connected artifact with shared decisions, so one writer should own them.

That is the split Cognition describes for code, applied to creative work. It also fits the checkpoints in our guide on what a creative AI agent should automate, where approval sits between the plan and the spend. For how the steps chain, see agentic creative pipelines. I make no claim about how Oakgen Agent Chat is built internally, and I did not test a multi-agent version of this workflow.

If your agents reach tools over MCP, see code execution with MCP for context bloat, and MCP vs A2A for which protocol links agents to tools and to each other.

If you do split, set these guardrails

• Cap the count. Anthropic's early agents spawned 50 subagents for simple queries. Its scaling rules were 1 agent for simple fact-finding, 2 to 4 for direct comparisons and more than 10 only for complex research.
• Pick the worker model on purpose. Subagents can inherit your session model, and Claude Code's docs note that switching to Opus also applies to subagents that inherit it. Set a smaller model for simple work.
• Write the brief for each subagent. Objective, output format, tools, boundaries.
• Keep one writer. Let subagents read, search and review.
• Return references, not transcripts. Have subagents write findings to files and hand back a pointer.
• Set effort levels. Our pricing and cost per task guide shows how far cost per task moves with effort.
• Trace everything. Anthropic said production tracing is what let it diagnose why agents failed.

Decision framework

Climb this ladder one rung at a time and stop when the task passes.

1. One model call with retrieval and examples. Anthropic says this is usually enough for many applications.
2. One agent with tools and a stopping condition.
3. One agent plus a read-only subagent for noisy work such as tests, logs or documentation.
4. A clean-context reviewer on the finished output.
5. A lead with parallel read-only subagents for breadth-first research.
6. Parallel writers or agent teams, only with a measured gain and a task like the Fermat proof, where finished work can be checked by machine.

If you pick Fable 5.2 for the lead, our comparison with Opus 5.5 and GPT-6 Astra covers which jobs justify it. Anthropic itself recommends starting most coding and knowledge work on Opus 5.5.

What I would do. I would start every new workflow on rung 2 and write down the success rate on 20 tasks. I would add rung 3 the first time a tool dumps more than a few thousand tokens into the context. I would add rung 5 only for research that is clearly independent and clearly valuable, with worker subagents on a cheaper model and a hard cap on the count. I would not run parallel writers on anything with a shared voice. Finally, I would read the /usage breakdown after the first real session.

Common mistakes

1. Splitting before testing one agent. Anthropic's own advice is to find the simplest solution and add complexity only when it demonstrably helps.
2. Reading the 90.2% as a general result. It is a vendor eval on research tasks with Claude 4 era models.
3. Giving subagents one-line tasks. That is how Anthropic's early agents duplicated each other.
4. Splitting a writing job. Two writers make two sets of implicit choices.
5. Letting subagents inherit the most expensive model. The cost table shows a 2 to 3.5 times difference from that choice alone.
6. Comparing at different token budgets. If the split version simply spends more tokens, you may be measuring budget, not architecture.
7. Treating the 45% figure as a rule. It came from specific benchmarks, and the SWE-bench Verified and Terminal-Bench runs used 20 task instances per configuration.

Frequently asked questions

When should I use multiple agents instead of one?

Use several agents when the work splits into pieces that do not need each other's results, when it is mostly reading rather than writing, when the material would overflow one context window, and when the task is worth several times the tokens. Anthropic's June 2025 engineering post says multi-agent systems excel at valuable tasks with heavy parallelization, information that exceeds a single context window, and many complex tools. Keep one agent when the pieces share decisions or each step depends on the last.

How many more tokens do multi-agent systems use?

Anthropic reported in June 2025 that agents typically use about 4 times more tokens than chat interactions and multi-agent systems about 15 times more, from its own data. Anthropic's Claude Code docs, read on November 12, 2026, say agent teams use approximately 7 times more tokens than standard sessions when teammates run in plan mode. The two figures use different baselines, so do not chain them. Measure your own task.

Do multi-agent systems actually perform better?

It depends on the task. Anthropic reported a 90.2% gain over single-agent Opus 4 on its internal research eval. A Google and MIT study across 260 configurations found a relative change from +80.8% on a decomposable finance task to -70.0% on sequential planning, with a mean across all six benchmarks of -0.3% and a very wide interval. Both can be true, because the tasks and budgets differ.

Why do sub-agents burn through Claude Fable 5.2 usage limits?

Anthropic's help article says Fable models use usage limits faster than other Claude models, and Claude Code's docs say every subagent sends its own requests on top of the main conversation's. SemiAnalysis reported from its run logs that Fable 5.2 launches subagents for independent re-derivation and auditing more eagerly than earlier models. That is a plausible mechanism, not a measured one. I found no controlled measurement of plan-limit share. Check the subagent share in /usage.

Is a sub-agent the same as a multi-agent system?

Not quite. Anthropic defines a multi-agent system as multiple agents, meaning LLMs autonomously using tools in a loop, working together. A subagent that only searches code or runs tests and returns a summary behaves more like a tool call. Cognition's April 2026 post says most multi-agent setups in the world are limited to read-only subagents of that kind. They cost tokens, but they carry far less coordination risk than agents that write in parallel.

Should coding tasks use multiple agents?

Mostly one writer. Anthropic said most coding tasks involve fewer truly parallelizable pieces than research. Cognition's 2025 post argued against parallel writers, and in April 2026 it said the patterns that work keep writes single-threaded, for example a clean-context review agent that checks the coder's diff. Use extra agents to review, search or run tests, not to write overlapping code.

What is the cheapest way to test whether splitting helps?

Run about 20 representative tasks on one agent first, as Anthropic suggests for early evaluation. Then add the smallest split, such as one read-only subagent for noisy work, and compare success rate, tokens and wall-clock time on the same 20 tasks. Split only if the success rate rises by more than the cost ratio. The worked example in this post shows that arithmetic with hypothetical inputs.

Sources

1. Anthropic Engineering, How we built our multi-agent research system, Jun 13 2025 (read 2026-11-12)
2. Anthropic Engineering, Building effective agents, Dec 19 2024 (read 2026-11-12)
3. Anthropic, Introducing Claude Fable 5.2 and Claude Mythos 5.2, Nov 9 2026 (read 2026-11-12)
4. Claude Help Center, Claude Fable 5.2 launch offers (read 2026-11-12)
5. Claude Code Docs, Manage costs effectively (read 2026-11-12)
6. Claude Platform Docs, Pricing (read 2026-11-12)
7. Cognition, Don't Build Multi-Agents, Walden Yan, Jun 12 2025 (read 2026-11-12)
8. Cognition, Multi-Agents: What's Actually Working, Walden Yan, Apr 22 2026 (read 2026-11-12)
9. Kim et al., Towards a Science of Scaling Agent Systems, arXiv 2512.08296 v3, revised Apr 8 2026 (read 2026-11-12)
10. Google Research, Towards a science of scaling agent systems, Jan 28 2026 (read 2026-11-12)
11. MIT Media Lab, When do AI agents benefit from collaboration, project overview (read 2026-11-12)
12. Cemri et al., Why Do Multi-Agent LLM Systems Fail, arXiv 2503.13657, NeurIPS 2025 Datasets and Benchmarks (read 2026-11-12)