Multi-Agent AI Costs 15x More Than a Single Agent. Here's When That's Worth Paying.

The pitch skips the bill

"Multi-agent" has become the word vendors reach for when they want a pitch to sound more sophisticated than "chatbot." The idea is intuitive: instead of one AI model doing everything, you split the work across several agents that each handle a piece, then combine the results. More agents, more capability — the logic seems to write itself.

Anthropic's own engineering team published real numbers on this, from building the multi-agent system behind Claude's Research feature, and the numbers are worth sitting with before you buy the pitch. A lead agent (Opus 4) coordinating multiple subagents (Sonnet 4) beat a single Opus 4 agent working alone by 90.2% on their internal research evaluation. That's a real, substantial jump.

It also cost roughly 15x the tokens of a single chat interaction. A single agent working alone runs about 4x the tokens of a plain chat. Multi-agent orchestration isn't a free upgrade — it's a nearly 4x cost multiplier on top of an already more expensive approach, in exchange for better results on a specific kind of task.

That ratio is the actual decision businesses need to make, and it's the part most "multi-agent" pitches leave out.

Where the gain actually comes from

It's tempting to assume multiple agents are smarter because they "collaborate" or "specialize." Anthropic's analysis of their BrowseComp evaluation found something less exciting and more useful to know: token usage alone explained about 80% of the performance variance, with the number of tool calls and model choice accounting for most of the rest.

In other words, the gain is mostly brute force spread across parallel workers, not emergent coordination intelligence. Three agents reading twenty sources each will usually beat one agent reading twenty sources total, because more of the problem gets covered, not because the agents are reasoning together in some qualitatively different way. That's a real advantage for the right kind of task. It's also exactly why the advantage doesn't transfer to every task.

Where it pays off

The pattern Anthropic describes is breadth-first work: research sweeps, competitive scans, due diligence across many independent documents, anything that decomposes cleanly into subtasks that don't depend on each other. Give five agents five different companies to research in parallel and merging their output is trivial — you're just concatenating independent findings.

This is also where errors are cheap. If one subagent botches its slice, you lose a fifth of the coverage, not the whole run, and it's usually obvious which slice is weak. If the task is genuinely high-value — the kind of research a person would otherwise spend hours on — paying 15x the token cost of a single chat to get it done in minutes is an easy trade.

Where it falls apart

The failure mode shows up the moment subtasks stop being independent. Cognition, the company behind the coding agent Devin, published an essay arguing against building multi-agent systems for exactly this reason: when you split coding work across parallel agents, each one makes its own implicit decisions about style, interfaces, and edge cases. Those decisions don't automatically agree with each other, and reconciling them after the fact is often harder than just writing the code with one agent that held the full context the whole time.

Anthropic's own write-up says the same thing from the other direction: domains that need all agents to share context, or that have heavy dependencies between subtasks, are a poor fit for multi-agent systems today. Coding is the clearest example — a function written by one subagent has to compose correctly with a function written by another, and "correctly" depends on shared assumptions that parallel agents don't automatically have.

There's a second cost that doesn't show up in the token bill: debugging. A single agent that gets something wrong has one place to look. A multi-agent pipeline that gets something wrong might have failed at the task split, in any one of N subagents, or at the merge step, and figuring out which one takes real engineering time — time a vendor's demo never shows you.

What this means if you're the one buying

If a vendor's pitch leads with "multi-agent system" as the selling point, the useful question isn't "how many agents." It's three narrower ones:

• Does this task actually decompose into independent subtasks, or are the pieces dependent on each other?
• What's the token/API cost multiplier for this architecture, and does the task's value clear that bar?
• What happens when one subagent gets it wrong — is the failure contained, or does it propagate?

A task that's breadth-first and high-value (market research, document review across a large independent set, parallel data enrichment) can justify the 15x spend. A task that's inherently sequential or interdependent (most coding, most workflows with a single correct output) usually gets worse, not better, from being split across agents — and you pay more for the privilege.

Our default at Devectra is to start with one well-scoped agent with good tools and good context, and only move to multi-agent orchestration when we can point to the specific bottleneck it fixes and the cost math still works. "We added more agents" is not, on its own, a result. It's a line item.

Takeaway: before paying for a multi-agent architecture, ask whether your task is actually parallelizable and whether its value clears a roughly 4x cost premium over a single agent, which itself already runs ~4x a plain chat. If the task is sequential or interdependent, a single agent with better context will usually beat several agents arguing past each other — for less money.