Why Multi-Agent AI Systems Cost Three Times More and Solve No More Tasks

Sam Altman wants a new name for multi-agent AI systems. On John Collison's Cheeky Pint interview on October 29, he said he hates the word "agent swarms" and would rather call them "agent teams," because now you can point many models at one problem at once.^[1]

He is describing a direction, and a fair one, but the pitch carries no price. The same week, two researchers published a study that measured it on Anthropic's current models, and for a single coding task the answer was blunt: the team cost three times as much as one call and solved no more.

Are agent teams the next way to scale AI?

For work that splits into many independent pieces, they can be. For a single task one strong model can finish, the evidence this week says no: a team adds handoffs, and every handoff is paid for in tokens and time before it adds any capability.

The vivid version comes from YC Labs. It put 50 AI agents in a survival Minecraft world for three hours with one goal, "Build a thriving civilization." They sent about 5,900 messages and built a ration ledger, written rules and a permit system.^[2]

At one point four agents spent 11 minutes appointing a "sole fertilizer operator" for a single piece of bone meal.

YC Labs' own verdict: "The colony never really thrived." It is a game, and it was not a controlled test of team size, so it proves nothing about cost. It does show where the effort goes once agents have to agree with each other.

What does a multi-agent pipeline actually cost?

On these coding tasks, about three single calls. A planner, coder and reviewer team on Anthropic's strong model, Opus 5.5, cost 3.22 times as much as one Opus call, took 3.24 times as long, and solved no more tasks. The comparison covered 2,430 runs on 135 public coding problems.

The study is "The Coordination Tax and the Heterogeneity Dividend," by Andreas Zettl and Diego Gosmar of VoiceInteroperability.ai and Linux Foundation AI & Data, posted to arXiv on October 25.^[3]

They ran each of six setups three times on two public benchmarks, 50 small function tasks and 85 larger tasks that ask for a whole class with several methods. The six setups:

• One call to the strong model, Opus 5.5.
• One call to the cheap model, Haiku 5.5.
• A router that asks the cheap model which of the two should take the task.
• A planner, coder and reviewer team as plain calls, all on the strong model.
• The same team passing work over an open agent messaging standard, the Open Floor Protocol.
• That team again with the cheap model as planner and reviewer, and the strong model coding.

The whole experiment, all 2,430 runs, cost $67.16.

On the small tasks every setup solved nearly everything, so the team only added cost. On the larger tasks, where splitting the work had the most to offer, one strong call solved 90.2% and the all-strong team solved 87.8%.

What that looks like in dollars

The paper reports cost per solved task for each setup. On the larger class-level tasks, one strong call cost $0.0287 per solved task, the all-strong team $0.0898 and the mixed team $0.0429.

Those are fractions of a cent until you run them at volume. At 10,000 solved tasks a month, the single call comes to about $290, the all-strong team about $900, and the mixed team about $430, with the mixed team also solving fewer of the tasks it was given.

The limits matter, so here they are once. Two public coding benchmarks the models have likely seen in training, one vendor's models, and one message protocol. The numbers say nothing about research, support or sales work. They say a lot about the default assumption that more agents means better results.

Is the coordination protocol the expensive part?

No. The messaging layer that passes work between agents added 7.2 milliseconds per handoff, about a tenth of one percent of a pipeline's running time. The cost lives in the decomposition itself: each role reads the context, reasons about it and writes output, and the next role does it all again.

When a multi-agent system runs slow or expensive, the protocol is an easy suspect. On this evidence the plumbing is nearly free. The bill comes from asking three models to think about one problem in sequence, which is the same pattern behind the token bill now landing on teams that run agents all day.

Why don't cheaper models fix the bill?

Because a cheaper model can think longer. Moving the planner and reviewer to Haiku cut the team's cost to 0.39 times the all-strong team, but it lost 6.7 points of accuracy and still cost 1.27 times one strong call. The authors' own forecast missed by 19%.

The forecast was built from list prices, and Haiku costs a fortieth of Opus per token. It missed because Haiku reasoned at length in the same roles. Reasoning made up 37.6% of the mixed team's output tokens, against 21.9% for the all-strong team.

Price per token is not cost per task. We made the same point about single models in why the cheapest model per token can cost more per finished task; this study shows the effect compounds inside a team, where every role's extra thinking gets billed.

Where is the real saving?

In choosing one model per task, not in adding roles. A perfect choice between the single strong call and the single cheap call solved 94.3% of runs at about half the strong call's cost per solved task. No team setup came close to that trade.

That 94.3% is a ceiling. It assumes you already know which tasks the cheap model can handle. The authors' simple router, a cheap model asked to pick without any training, captured the cost saving but not the accuracy: of the runs it sent to the cheap model, 28.8% failed.

The router leaned hard on the cheap model, sending 86.7% of the larger tasks its way, and that is where its misses came from. As the authors put it, routing whole tasks needs no inter-agent protocol at all.

Knowing which tasks a cheap model can handle is worth more than any number of extra agents.

When should you use multi agent systems?

When the work really splits: many independent searches, many files, many candidates to try, or roles that need different permissions. The measured wins for multi-agent AI come from parallel search with an independent judge, not from passing one task down a line of specialists.

We covered the strongest of those wins in why agent swarms fail tasks that single agents ace, where 45 coordinated agents found far more security flaws than the same model working alone. That task had the right shape. A single coding task, done in sequence by planner, coder and reviewer, does not.

How do you evaluate a multi-agent system before you adopt it?

Run three setups on a sample of your own tasks and compare one number: cost per solved task. One strong call, a routed choice between a strong and a cheap model, and the team. Adopt the team only if it wins on that number.

Start with a few dozen real tasks. Keep three things in view while you run it:

• Count solved tasks, not finished runs. A run that returns broken code costs money and solves nothing.
• Log tokens per role, including reasoning, since that is where the mixed team's forecast broke.
• Rerun when a model or its price changes, because the ratios move with both.

If the team wins, keep it and build the checks that make an orchestration trustworthy. If it loses, you have saved yourself a bill that grows with every task you run.

A team of agents is an architecture choice with a bill attached, and the bill is the first thing to read.