I would have bet that the model in the lead role decides how well sub-agents work. The paper below says the agent's own delegation habits matter at least as much, and that for bounded tasks the safest default is to not delegate at all.
Li, Li, Jiang and Lou ran "When Sub-Agents Work in Parallel" as a controlled switch: the same backbone, prompt, environment and time budget, once with dynamic concurrency on (the main agent decides at runtime whether and when to spawn sub-agents) and once with it off. Three native scaffolds: Codex with GPT-5.4, Claude Code with Claude Opus 5, Kimi Code with Kimi K3. 354 tasks, 2,124 executions, about 11.2B tokens, roughly $20,780 at API rates.
The cost is certain, the speedup is not#
Token use under concurrency ran 1.41 to 3.31 times the sequential level. Codex went from about 7.7M tokens per solved task to about 24.1M. Runtime went up overall for every agent, and in 14 of 15 agent-benchmark combinations.
The speed argument is the one I hear most often for parallel sub-agents, so look at the tasks solved in both modes. There were 366 of them. Concurrency was faster on 102 (27.9%) and at least 20% faster on 46 (12.6%). On the other 72% it was equal or slower.
Where it broke things: a bounded benchmark#
On 100 sampled SWE-bench Verified tasks, Claude Code fell from 83.0% to 59.0% and Kimi Code from 77.0% to 59.0%. Both drops are significant under Holm-corrected McNemar tests (p about 5.1e-7 and 0.013). Codex stayed at 71.0%, and its difference was not significant.
Across all benchmarks the pass-rate effects ranged from an 11.9-point decrease to a 2.3-point increase. RepoZero averaged -8.29 points, NL2Repo -0.04, ProgramBench +1.24, LoopsBench +4.31. On LoopsBench the best case was up to 14.3 points for Codex and Claude Code.
My read: a bug fix is a small, tightly coupled change. Splitting it across workers mostly adds coordination surface. Long, decomposable repo-scale work is where the upside lives, and even there it is modest.
Three agents, three very different delegation habits#
The scaffolds do not behave alike, so "sub-agents" is not one thing. On hard LoopsBench tasks Claude Code created about 134 sub-agents per task and Kimi Code about 67, while Codex kept its peak concurrency at 1.2 to 3.0. The median share of a run with two or more sub-agents active was 52.7% for Claude Code, 23.9% for Codex and 15.6% for Kimi Code. And 24.3% of Codex executions spawned sub-agents that never overlapped, which is delegation without any parallelism.
Delegation also scales with difficulty: a mean of 6.69 sub-agents on easy tasks, 7.53 on medium, 15.84 on hard. The agent spends more when the task is harder, which is sensible, but nothing in the paper shows it spends well.
Timing differs too. Codex starts delegating earliest, at a median 4.0% into the trace, while Claude Code and Kimi Code wait until roughly 22% and 26%. Early delegation means the lead splits work before it has read much of the repo, which is exactly when a split is most likely to be wrong. I would want to see that tested directly, because this paper observes the habit but does not intervene on it.
What goes wrong, from 804 annotated failures#
The authors labelled 650 trajectories and found 804 failure-pattern instances (inter-annotator kappa 0.77), grouped into four categories:
Shared state and merge: 267 (33.2%)
Execution governance: 233 (29.0%)
Task orchestration: 229 (28.5%)
Global context management: 75 (9.3%)
The most common individual patterns were load imbalance (20.6%), wrong start, join or result timing (20.6%), fan-out budget exhaustion (19.2%) and deliverable overwrite (14.9%). Those are classic concurrency bugs, reproduced by LLMs with no locks and no scheduler. A third of all failures are two workers touching the same state, which is something a harness can prevent mechanically instead of hoping the prompt covers it. If you build orchestration yourself, give each sub-agent its own working directory or branch and make the merge an explicit step the lead has to perform and check.
The benefits are real, just narrower than the pitch#
Concurrency produced solves the sequential run missed in nearly every agent and benchmark; Claude Code solved four LoopsBench tasks only under concurrency. Across 131 matched pairs the authors found three recurring mechanisms: complementary work done in parallel, alternative attempts that the main agent picks between or combines, and independent validation that corrects the main agent.
The third one is the interesting one to me. A reviewer sub-agent with a fresh context is useful whether or not anything runs in parallel. It is also cheap to try: one extra context, one review pass, no fan-out budget to exhaust.
What I'd do with it, and what I wouldn't conclude#
Every configuration was run once, because runs at this scale are expensive, and the failure labels rely on manual annotation. It covers three scaffolds and five benchmarks, with SWE-bench Verified sampled at 100 tasks. Treat the exact gaps as indicative.
Still, I'd change two things. First, stop treating sub-agent count as a quality signal; log tokens per solved task and compare against a sequential baseline before you keep any fan-out. Second, for small fixes, restrict delegation to a single verifier sub-agent rather than letting the lead fan out freely. I expect the next useful result here to be a scaffold that caps fan-out and serializes writes to shared files, since overwrites and bad join timing account for so much of the damage.