The Swarm's Bill Arrives at the Deadline

On 6 October I wrote that token cost is not something the topology decides for you. It is a dial you set. I still believe it, and the papers from the last two weeks have made it look like a smaller part of the problem than I thought.

That argument was about how much you spend. The measurements that landed between 15 and 29 October are about something else. Given the same quantity of work, the arrangement of the agents decided whether the task finished inside its deadline. Those are different variables, and the distance between them is wider than I expected.

The benchmark that holds the work still

MAServeBench was submitted on 29 October by seven authors at Peking University and Georgia Tech [1][2]. Its premise is that a multi-agent request is not a request. It turns one user request into “interdependent model and tool operations”, and unlike independent requests, “these operations become ready at different times and consume evolving context as agents coordinate and exchange results” [1].

Ordinary serving benchmarks miss that. A load generator sprays independent requests at a model and measures latency, which assumes the requests have nothing to do with each other and that the router can treat each one as a fresh unit of work. A swarm instead produces a dependency graph. A planner call gates four research calls, which gate a synthesis call, which gates a reviewer that may send the whole thing back. Two swarms can emit identical token counts per call and present completely different arrival patterns to the server.

The paper separates two things that usually get run together. Work generation is which calls happen and how large they are. Work exposure is when a call that already exists becomes eligible to run. Hold the first fixed and vary only the second, and you have a controlled experiment on the collaboration rules with the model’s output held identical. The mechanism is a recorded trace of every operation with its resolved inputs, output contract and typed dependencies, which can be replayed with different release constraints [2].

I discount most benchmark papers that report on their own benchmark. What raises this one is the validation section: seven paired comparisons against six real frameworks, reimplemented in the benchmark’s abstractions and run on the same tasks [2]. On SWE-bench Verified, the original Agyn workflow resolves 60.4% of 500 instances and the MAServeBench realization resolves 62.4%. Magentic-One scores 62.4% on GAIA against a realization’s 61.2%, and 44.7% on WebArena against 40.9%. Those are small deltas in both directions, which is what you want from a reimplementation and rarely get.

Four percent

The main experiment is a 2x2: two release rules crossed with two KV-cache budgets of 16 and 40 GiB, on Qwen3-8B over 910C hardware. One rule releases each operation as soon as its dependencies are satisfied, and the paper calls that DAG. The other adds a barrier between analyses that do not depend on each other. The workflow has four independent analyses, and the barrier adds three ordering edges among them. Scheduled width drops from 24 to 12 and mean root latency rises by 26% [2].

The barrier does not change a single required dependency. It does not add a token. It is legal ordering, and it preserves every artifact precondition the workflow already had. It only decides that work which could have run at the same time does not.

Across four Poisson arrival rates and three paired blocks, with recorded work, required dependencies and arrivals all held fixed, the shared deadline is 361.7 seconds. That is 1.5 times the P95 of a separate low-load reference run, so it is not a number pulled to make a point [2].

At the second of the four rates, the DAG arm’s median deadline attainment is 100% and the barrier arm’s is 4%, under either cache budget. The block ranges are 91.7 to 100% and 0 to 5.9% [2]. The first three rates incur no KV preemption in either arm, so nothing was being evicted when the barrier arm missed almost every deadline.

The 4% is one arrival rate in one benchmark on one model, reported by the group that built the benchmark. The appendix carries a deadline sweep where the barrier arm climbs to 88% at a deadline set to twice the reference P95, so the 4% is a property of that deadline rather than of barriers in general [2]. What holds across every version of the sweep is the direction: over 96 paired block contrasts, the more parallel arm is never worse.

I find the direction easier to believe than the magnitude. The magnitude is still the most useful number I have seen on this beat, because a deadline is the unit an operator is judged on.

Turn-taking is a barrier

The reason to care about the barrier arm is that it is what most multi-agent code already looks like. Chat-completion interfaces invite turn-taking. A supervisor writes a message, a worker replies, the supervisor writes again. Every one of those exchanges is a synchronization point, because the next message cannot be composed until the previous one lands. A team that builds this workflow as a supervisor waiting to collect all reports before dispatching the synthesizer has recreated the barrier arm’s ordering.

The resemblance stops at the ordering. The 4% belongs to one model, one workload and a 361.7-second deadline, and I would not expect a supervisor built on a hosted API to land anywhere near it. What transfers is the reason to measure: if the ordering in your own system is a barrier, deadline attainment is the number to collect, and a throughput chart will not tell you which of the two configurations you built.

The paper does not suggest removing ordering the artifacts require, since that would break the workflow. It suggests noticing which ordering a dependency requires and which is only a copy of a conversation.

The throughput inversion

There is a second result in the same paper, about throughput, and I think it matters more for anyone running their own hardware. At the highest tested ordinary-serving load, raising the request limit from 64 to 128 raises output TPS by 14.6% and lowers the deadline-compliant task rate by 22.5%. The paper’s phrase is that this reverses the preferred configuration [2]. Rank the two settings by throughput and 128 wins. Rank them by whether the work finished on time and 64 wins.

There is a version of the same inversion under memory pressure. At the highest arrival rate, going from 16 to 40 GiB of KV cache eliminates preemption, cuts the DAG arm’s root P95 by 15.5% and raises output TPS by 7.7%, and deadline goodput stays near zero anyway. The execution got materially faster and the tasks still did not complete in time. The paper’s own summary is blunt: “Improved hardware efficiency does not guarantee better task SLOs” [2].

Anyone sizing a GPU pool for an agent product should read that sentence twice. Throughput and task completion track each other right up until they do not, and the region where they diverge is the region where your queue looks full.

For anyone running vLLM or AIBrix on hardware they own, which is the layer I looked at two weeks ago, these are configuration values rather than vendor decisions. The 64-to-128 change is the one people reach for when the queue looks long, because it is the knob labeled more. On this workload it buys 14.6% more output tokens per second and gives back 22.5% of the completions that arrived on time.

The AIBrix release was the serving layer learning that an agent is a session. This is the next step along the same line: the serving layer also has to learn that a session has a deadline, and that a batch full of work from one slow dependency chain can hit its throughput target while the request behind it expires.

The 15x is a default

None of this settles the question the October post left open, which is whether multi-agent is worth its token premium. It does change what the premium looks like.

Anthropic’s figures are still the best public estimate of the tax: about 4x the tokens of a chat interaction for a single agent and about 15x for a multi-agent system [3]. Its guidance next to them is that multi-agent pays off for heavy parallelization, information that exceeds one context window, and interfacing with many complex tools.

EvoRouter, submitted on 26 October, argues that the tax is mostly untuned. Models, collaboration modes, agent counts, interaction rounds and skills all interact, so the configuration space grows combinatorially and almost nobody searches it [4]. Their learned router reports 68.69% average in-domain accuracy across 19 datasets in five domains, 7.23 percentage points over the strongest routing baseline, at 50.95% less inference compute [4].

I would not read that as swarms getting cheap. The baseline is its own, the savings are self-reported, and routing well is not orchestrating well. What it shows is that the 15x is what you get when the arrangement is left at whatever the framework’s example did.

Twenty negotiations in one context

The coordination papers were chasing a different failure, and the best of them starts by questioning which resource is actually scarce. The inbox paper, submitted 26 October, argues that the scarce resource in agent coordination is not delivery but reading, because “every message costs tokens, and the context is finite” [5].

Current infrastructure works by push. The sender decides what enters the recipient’s context, the recipient reads in arrival order, and once the context is full the oldest messages are dropped. In simulated societies of up to 16,000 agents, where every decision is an LLM judgment, an agent leading 20 concurrent negotiations “proposes options already rejected 97% of the time”, because the replies that ruled those options out fell off the front of its context [5].

The alternative is a pull inbox outside the context, where the recipient’s own rules decide what it reads. An inbox that first reads messages carrying a refundable deposit finds about 60% of the agents a request needs, at every size from 1,000 to 16,000, where first-come-first-read misses every request [5].

The figure I keep returning to is the partial-deployment one. On a real email network, when half the agents adopt such an inbox, forwarded search recovers 5% of what full adoption gets, against 42% for a single-hop search [5]. Half a coordination primitive is not half the benefit. It is close to none, and it loses to a simpler mechanism that everyone is on.

Those numbers come from simulation with one real-network check, so read them as a demonstration that the failure mode exists rather than as a measurement of how often it happens.

The sender is still the party in doubt

PCM, submitted 29 October, is the security half of this and it belongs to yesterday’s post more than to this one. Its finding is that the agent protocols authenticate the channel and leave the sender in doubt. On a pre-specified set of 926 messages from real runs containing 712 fabrications in 16 classes, plain A2A accepts all 712, models of six deployed protocols accept between 504 and 712, and the proposed protocol accepts 10 [6].

The caveats are heavy enough that I would not quote the 1.4% as a property of A2A. It is a single-author paper from a company proposing its own protocol, and the six comparison protocols were modeled rather than run. What I take from it is the same thing I took from the TRACE post: a receipt proves who sent a message and not whether it is true. The quantified version of that sentence now exists, and it is worth reading.

What I would actually do

The honest default has not moved. One agent with good tools is still the right starting point, and most workloads never clear the bar for a second one.

Past that bar, the October papers say the variable that decides success is not the cleverness of the routing prompt. EvoRouter’s gains come from choosing configurations better, not from assembling more agents, and nothing in this cluster shows a swarm beating a single agent on accuracy. The variable that produced the 96-point gap in MAServeBench was where a synchronization point sat in a dependency graph.

MAS-Loop, submitted 28 October, adds a smaller point that fits. The orchestration policies people train are still mostly one-shot, in that an orchestrator “generates a system but only observes and learns from its terminal outcome”, throwing away the trajectory that shows which step failed [7]. That is the same blind spot one layer up, and MAS-Loop is an attempt to close it.

The dial metaphor survives, and it was describing the smaller dial. Tokens are a setting, and both arms of the MAServeBench experiment spent the same amount of them. Where the synchronization points go is a design decision, and the paper puts a number on what that decision costs.

Sources

1. MAServeBench: Benchmarking Multi-Agent LLM Serving Systems with Hierarchical Collaboration Workloads — arXiv 2610.40293, submitted 2026-10-29, Peking University and Georgia Institute of Technology; abstract only, for the interdependent-operations and timely-completion sentences
2. MAServeBench full text — §4.2 trace and replay contracts, Appendix A.2 the seven paired functional comparisons, §6.2 the barrier and the 24-to-12 width, §6.6 the 2x2 experiment and deadline results, Appendix C.2 the deadline sweep and the 96 block contrasts, Appendix C.3 the request-limit inversion, §6.4 and Figure 9 the KV evidence
3. How we built our multi-agent research system — Anthropic Engineering; the 4x and 15x figures, and the guidance on when multi-agent pays
4. EvoRouter: Cost-Efficient Multi-Agent Routing via Insight-Guided On-Policy Distillation — arXiv 2610.35690, submitted 2026-10-26; abstract only
5. The Inbox as a Coordination Primitive for LLM Agent Societies — arXiv 2610.36264, submitted 2026-10-26; abstract only
6. PCM: A Proof-Carrying Message Protocol for Verifiable Multi-Agent Communication — arXiv 2610.39109, submitted 2026-10-29; abstract only
7. MAS-Loop: Beyond One-Shot Orchestration towards Self-Evolving Multi-Agent Systems — arXiv 2610.38946, submitted 2026-10-28; abstract only