A planner hands a coding task to a coder, the coder hands its draft to a reviewer, and each handoff travels over an agent interoperability protocol. The protocol's share of each handoff takes 7.2 milliseconds. The whole pipeline costs 3.22 times as much as asking one strong model once, takes 3.24 times as long, and solves no more tasks [1].
Those two numbers come from the same preprint, and they point in opposite directions. The part of a multi-agent system that teams argue about, the protocol, is close to free. The part they rarely question, splitting one job into several roles, is where the money goes.
Three costs hiding in one number
Most comparisons of "multi-agent versus one call" report a single figure. Andreas Zettl and Diego Gosmar argue that this figure mixes three separate mechanisms [1]:
- Decomposition. Splitting one generation into several, with context re-supplied at every stage.
- The protocol. Building, sending and parsing envelopes at every handoff.
- Model choice per role. Giving mechanical roles a cheaper model. This is the only one of the three that can save money, and only a decomposed pipeline can use it.
To pull them apart, they ran 135 coding tasks (50 from HumanEval, 85 from ClassEval) three times each under six designs, 2,430 runs in total, with Claude Opus 5.5 as the strong model and Claude Haiku 5.5 as the cheap one. The run took place on 15 and 16 October 2026 and cost $67.16 [1].
| Design | What it is |
|---|---|
| A | One call to the strong model |
| A' | One call to the cheap model |
| R | The cheap model reads the task and picks which model answers it |
| B | Planner, coder, reviewer, all strong, chained by plain API calls |
| C | The same three roles over the Open Floor Protocol (OFP), all strong |
| D | Like C, but the planner and reviewer run on the cheap model |
Each comparison isolates one mechanism. B against A measures decomposition. C against B measures the protocol. D against C measures model choice.
The protocol is a rounding error
Across 2,430 handoffs, the protocol took a median of 7.2 ms each, with a 95th percentile of 12.5 ms. A three-handoff pipeline spent 20.5 ms on it, 0.11% of its median wall time [1]. The pipeline over OFP cost 1.01 times as much as the identical pipeline over plain calls, with a confidence interval of 0.99 to 1.02 [1]. The protocol did not measurably change the bill.
The authors are clear that this is a best case. Every agent ran on one machine over loopback HTTP, with no TLS and no authentication, so a deployment across networks or organisations will pay more [1]. Even so, they point out that a hundred times the measured figure would add about two seconds to a pipeline that already takes about twenty [1].
So the protocol is not the bill. The question is what is.
The planner and the reviewer are the bill
The all-strong pipeline over OFP cost 3.22 times as much as the single call and took 3.24 times as long, with a pass@1 change of -1.5 points that is not statistically significant [1]. On the harder ClassEval tier, the pipeline solved 87.8% of runs against 90.2% for the single call [1].
The mechanism is volume. At a fixed model, decomposition inflated output tokens by a factor of 2.95 and input tokens by 4.89 [1]. Every stage after the first has to be told what the first stage already knew, so input volume grows with pipeline depth even when output volume does not.
The authors' reading is blunt: for a model as capable as Opus 5.5 on self-contained tasks, a separate planner and reviewer "add tokens without adding information" the single call lacked [1]. It echoes what we found when four papers on agent debate measured agreement instead of accuracy: more agents in the loop is not the same as more checking.
The cheap planner made it worse
The obvious fix is design D. Keep the strong model where the code is written and move the planner and reviewer to a model that costs 2.5% as much. That cut cost to 0.39 times the all-strong pipeline, but pass@1 fell by 6.7 points, and D still cost 1.27 times the single strong call while running 2.6 times as long [1].
The surprise is why. The authors' own formula forecast D at 1.02 times the single call; the real figure was 1.27, a miss of 19% [1]. The price part of the forecast was right. The volume part was not: the cheap model reasoned more than the strong one in the same roles. Reasoning made up 37.6% of D's output tokens against 21.9% in the all-strong pipeline, and the coder stage, the only strong-model step left, still accounted for 92.9% of D's cost [1].
On paper, D cleared the break-even line: 74% of its output tokens went to the cheap model, above the 68% the formula required [1]. In practice, it did not. A cheap model that writes longer changes the very number the forecast depends on.
The break-even check you can run before adding a role
The paper's most reusable contribution is a short formula [1]. Call the extra token volume a decomposition creates α (2.0 means the pipeline writes twice what one call writes), the cheap-to-strong price ratio r, and the share of tokens you can push to the cheap model f. The pipeline is cheaper than one strong call only when:
f > (α − 1) / (α × (1 − r))
and it can never be cheaper, whatever you route, once α reaches 1/r.
| Token inflation α | Cheap model at half price (r = 0.5) | At one fifth (r = 0.2) |
|---|---|---|
| 1.5 | 67% of tokens must go cheap | 42% |
| 2.0 | 100%, and then it only breaks even | 63% |
| 3.0 | Impossible | 83% |
Those thresholds are the paper's own table [1]. The lesson from D adds one rule to it: measure α with the cheap model actually in the role, not with the strong model you started from. The volume a role produces belongs to the model filling it.
Route the task, not the role
Where did the savings hide? Not inside the pipeline. On the easy tier the cheap model alone solved 98.7% of runs; on the hard tier it solved 52.5% [1]. The tasks divide into ones the cheap model handles and ones it does not, and splitting every task into roles charges strong-model prices on all of them.
An oracle that knew in advance which single call to use for each task solved 94.3% of runs at $0.0098 per solved task, half the strong call's $0.0198, at the same accuracy [1]. The paper's own router could not get there: asking the cheap model to judge difficulty up front sent 86.7% of hard-tier runs to itself, 28.8% of everything it routed to itself failed, and it finished at 71.4% [1].
That leaves a practical question the paper does not answer. If guessing difficulty in advance fails, what signal could tell you, after the fact, that the cheap answer was not good enough?
We reran the numbers from their log
The authors released the harness, the task suite and the raw run log, one row per run with tokens, cost, time and test results [2]. We downloaded results_final.csv and recomputed the paper's figures. They reproduce: 2,430 runs, $67.16, a median of 7.21 ms per handoff, the strong call at $0.0198 per solved task, and the oracle at 94.3% for $0.0098.
Then we tested a design the paper did not run: try the cheap model first, and call the strong model only when the tests fail. No extra runs were needed. For each task and repetition, we took the cheap call's logged result; where it failed, we added the cost and time of the strong call from the same repetition.
| Policy, all 135 tasks | pass@1 | Cost per solved task | Time vs one strong call |
|---|---|---|---|
| One strong call (A) | 93.8% | $0.0198 | 1.00x |
| Paper's router (R) | 71.4% | $0.0046 | 1.00x [1] |
| Oracle (needs foreknowledge) | 94.3% | $0.0098 | not reported |
| Cheap first, strong on test failure | 94.3% | $0.0101 | 1.24x |
The cascade matched the oracle's accuracy at almost the oracle's cost, without knowing anything in advance. On the hard tier alone, it solved 91.0% of runs at $0.0164 per solved task, against 90.2% at $0.0287 for the strong model, 43% less per solved task. It escalated 121 of 255 hard-tier runs and 2 of 150 easy-tier runs.
Two costs come with it. Escalated runs pay for both calls in time, so the hard tier took 1.35 times as long as the single strong call, while the easy tier, where the cheap model rarely failed, took 0.67 times as long. And this is a best case: the escalation signal here is the benchmark's own grading tests. Your tests are rarely that complete, and a cheap answer that passes weak tests ships wrong without ever escalating.
Still, the pattern is the one the paper points toward. The cheap-versus-strong decision works per task, and a test suite is the most reliable judge of difficulty most teams already own.
What this study cannot tell you
The best objection is about scope, and the authors raise it themselves. These are self-contained coding tasks with clear specifications, run with models from one vendor, on public benchmarks the models have probably seen in training [1]. A reviewer has little to add when the task is a well-specified function. Long, under-specified work is where separate roles might earn their tokens, and the paper names it as the open question [1]. A separate October study of coding agents spawning sub-agents across 354 tasks of varying length catalogued 13 failure modes specific to concurrency alongside the conditions where it helps [3], which is a reminder that the long-horizon answer will not be a single number either.
Two more points belong on the record. Both authors take part in the Open Voice Interoperability Initiative, which develops the protocol they tested, and they disclose it [1]. The protocol's own result favours their project; the decomposition result cuts against the usual case for multi-agent designs, which makes the paper harder to read as advocacy. And the paper says its hypotheses were fixed in commit 85a3748, 25 minutes before the first run [1]. The public repository's history begins with an "initial commit" on 16 October, after the run had finished [2], so that timing cannot be checked from outside. The hypotheses are implemented in the released analysis script, and the numbers they produce reproduce.
This is also a v1 preprint without peer review. Treat the exact ratios as one careful measurement, not a law.
What to do before your next role
- Measure the single call first. Cost per solved task and pass@1 for one strong call and one cheap call. In this study, no pipeline beat the strong call on accuracy or the cheap call on cost per solved task [1].
- Price the protocol last. At 7 ms a handoff on one host, it will not decide your design. Decomposition will.
- Measure α with the real models in the roles. A cheaper model that reasons longer can erase the discount it was hired for.
- Try a test-gated cascade before a pipeline. Cheap model first, strong model when the tests fail. Its quality is only as good as your tests.
- Save multi-agent designs for work that splits. Fan-out over independent subtasks and long-horizon work are the cases the authors leave open; a single coding task is not one of them. Less scaffolding has helped agents before.
- For voice agents, budget time, not money. The protocol added about 20 ms per three-handoff pipeline. The three-role pipelines took 2.6 to 3.2 times as long as the single call, and a listener hears that [1].
The argument about which protocol connects your agents is worth having. It is just not where your bill comes from: on these tasks, the bill came from deciding that one job needed three agents.
References
[1] Andreas Zettl and Diego Gosmar: The Coordination Tax and the Heterogeneity Dividend: Break-Even Conditions for Multi-Agent LLM Pipelines (2026-10-25). Paper
[2] Andreas Zettl: coordination-tax-harness: harness, task suite, run log and analysis script (2026-10-16). Documentation
[3] Han Li, HanHaoNing Li, Ziqian Jiang and Yiling Lou: When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks (2026-10-07). Paper