Every writeup of the paper quoted one line: task completion drops from 29.5 minutes to 12.4. The same table has a token column, and it tells you the architecture is buying predictability, not speed.
On November 1 the DeepSeek Harness team published a 14,000-word design doc for what they call a Super-agent: an agent that stays online, takes events from group chats and code review instead of typed prompts, and runs many tasks at once without you babysitting sessions. The post has 2.7M views. The summary threads have hundreds of thousands more.
Almost all of that traffic repeats the same headline number — 29.5 minutes down to 12.4 — and almost none of it mentions what the same experiment says about cost. That column is the one worth reading, because it tells you where the real trade sits and which of the five modules you can safely skip.
Section 7.1 is an ablation, not a benchmark. Four designs, five runs each, about 300 messages per run of which roughly 20 were actual work requests; the rest were chatter, follow-ups, cancellations and CI noise. “Coding work was simulated by a tool that simply consumes time” — so the numbers measure scheduling and coordination, never the quality of the code produced. The authors say so themselves and call the results indicative.
Four designs: the full Super-agent (long-lived Router + isolated Workers + event pass-through), the same system with pass-through removed, and a single session with a subagent tool under two different prompts.
| design | p50 / p95 (min) | cache-read tokens per run |
|---|---|---|
| Super-agent | 12.4 / 15.7 | 23.2M |
| Super-agent, no pass-through | 12.6 / 15.5 | 31.8M |
| Single session, neutral prompt | 20.4 / 29.5 | 6.1M |
| Single session, delegation prompt | 13.8 / 29.0 | 10.8M |
Read the right column next to the left one. Going from a single session to the two-level architecture takes cache-read tokens from 6.1M to 23.2M per run — 3.8× — to save 8 minutes at the median and 13.8 at p95.
That is not a rounding detail. Cache reads are the cheap part of inference, which is exactly why the number is big and why nobody publishes it: a fact like this only shows up when the authors hand you their own ablation table and let you see the losing column.
The architecture is not a faster agent. It is an agent whose worst case behaves like its best case. You are paying 3.8× tokens for a shorter tail, and if your workload is one urgent task at a time, you are buying nothing.
Look at the last row. Give a single session one prompt — “every message of the chat reaches you, prefer handing each piece of work to a subagent” — and its median drops from 20.4 to 13.8 minutes, statistically level with the full system at 12.4.
Its p95 does not move. 29.5 → 29.0.
That single row is the strongest argument in the paper, and it is not the argument people are making. It says: prompting closes the median gap and cannot touch the tail, because the tail is not caused by the model choosing badly most of the time — it is caused by the architecture letting one long task and one new message compete for the same loop. The authors are blunt about the mechanism: with the neutral prompt the model did not call a subagent in any of the five runs; with the delegation prompt it delegated in four of five, and in the fifth it decided the work was “small” and did it itself, producing the long purple tail in their chart.
So the honest framing of “12.4 vs 20.4” is: a prompt gets you the average, a system gets you the tail. Those cost very different amounts of engineering, and they are not interchangeable.
Removing the subscription mechanism — the part where follow-up events in a thread go straight to the worker that owns them instead of back through the Router — changes completion time by 0.2 minutes. Nothing.
What it changes: the Router makes about 30% more decisions per run, and total cache-read tokens go 31.8M → 23.2M, 37% less when pass-through is on. A feature that reads like plumbing for correctness turns out to be a 27% bill reduction with no latency effect.
Section 7.2 stress-tests the Router alone, pushing trigger arrival from about 1 to about 40 per minute.
The mechanism is prefill: triggers that queue up during one inference turn get merged and computed in the same pass, so the 40th event costs a fraction of the 1st. This inverts the intuition every on-call engineer has — a backlog here is a discount, up to the context limit and the model's tolerance for many events in one turn.
It also explains why they resist sharding the Router. Splitting it buys throughput and spends the thing they actually want: one global place where every decision and every piece of cross-task memory sits.
Section 8.2 is the interesting one for anyone building a product on this. Once sessions stop being the user's unit of work, the whole interface has to be redesigned, and they say plainly that the chat window became the centre of interaction “partly through path dependence”. Their own agent mostly works inside GitHub issues and pull requests. If you are shipping an agent product this quarter, that is the paragraph that should worry you, not the latency.
Section 8.4 is worse: the cloud loop keeps taking untrusted events while endpoints hold credentials, so “if a server-side intrusion or a prompt injection compromises the Agent Loop, every endpoint device connected to it could be taken over”. A 100-word cap on chat replies is their verified norm. Nobody has a verified norm for that one.
One absence is worth naming, because every writeup inherits it: there is no quality column. The ablation measures completion time and token spend, and the authors are explicit that coding work was simulated by a tool that consumes time — so nothing in the paper says the two-level architecture produces better work, only that it finishes sooner and with less variance.
For a scheduling paper that is a fair scope. For anyone quoting it as proof that their agent should be rebuilt, it is the whole argument: this is evidence about latency and cost, and silence about output quality. The authors say as much in their own limitations — the results are indicative, the workloads synthetic, and parts of the setup could be more rigorous.