When Sub-Agents Work in Parallel: Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding
A · Strong evidence First controlled study of native sub-agent concurrency in Codex, Claude Code and Kimi Code: 2,124 executions over 354 tasks, about $20.8K of compute, significance tests and a failure taxonomy from 650 trajectories.
Summary based on the full text·Original: about 50 minutes to read
In short
A software engineering paper by Han Li, Ziqian Jiang (Nanjing University), HanHaoNing Li (Central University of Finance and Economics) and Yiling Lou (UIUC), posted on arXiv on 7 October 2026. It tests what happens when frontier coding agents are allowed to spawn their own parallel sub-agents on demand. Concurrency helped most on the longest tasks, hurt on short bounded ones, and multiplied token use without matching gains in solved tasks. The authors catalogue 28 coordination failure patterns and the conditions where parallel work does pay off.
Key numbers
- 1.41-3.31xtoken usage of concurrent versus sequential execution across agents
- -24.0 / +14.3 ppClaude Code task pass rate change with concurrency on SWE-bench Verified versus LoopsBench
- 24.12M vs 7.69Mtokens per solved task for Codex, concurrent versus sequential
- 12.6%tasks solved in both modes where concurrency was at least 20% faster
As reported by the source.
English·Web page·opens arxiv.org
What it reports
- Agents and models (July 2026 configurations): Codex with GPT-5.4, Claude Code with Claude Opus 5, Kimi Code with Kimi K3. 354 tasks, 2,124 executions, 11.2 billion tokens, $20,780.02 at API rates.
- LoopsBench (longest tasks): concurrency raised task pass rates for Codex and Claude Code by up to 14.3 points; test pass rates rose for all three, up to 6.0 points.
- SWE-bench Verified (bounded): no gain. Claude Code fell from 83.0% to 59.0%, Kimi Code from 77.0% to 59.0%, Codex unchanged at 71.0%. Pooled declines for Claude Code and Kimi Code were significant; Codex's gain was not.
- Average test-pass difference rises with task size: -8.29 points on RepoZero, -0.04 on NL2Repo, +1.24 on ProgramBench, +4.31 on LoopsBench.
- Tokens rose 1.41-3.31x; runtime rose in 14 of 15 agent-benchmark combinations (Claude Code on SWE-bench: 27.8 versus 17.5 minutes).
- Of 366 tasks solved in both modes, concurrency was faster in 102 (27.9%) and at least 20% faster in 46 (12.6%).
- 804 failure instances in 650 trajectories: execution governance 29.0% (early sub-agent termination 15.9%), task orchestration 28.5% (load imbalance 20.6%, fan-out budget exhaustion 19.2%), global context management 9.3%.
- Benefits came from complementary parallel work, exploring alternative solutions, and independent validation of the main agent's work.
How they got it
Each agent ran each task with its native dynamic concurrency on and off, holding model, prompt, environment and time budget fixed. Tasks came from four long-horizon benchmarks (RepoZero, ProgramBench, NL2Repo, LoopsBench; reference sizes 0.8-54.4 thousand lines) plus 100 SWE-bench Verified tasks. Significance used exact McNemar tests with Holm correction; failure patterns came from manual trajectory review and 131 paired trajectories where concurrency won.
Limits
- One run per task-mode pair, so per-task variance is not estimated.
- Results are tied to specific agent versions and July 2026 configurations, which change quickly.
- Long-horizon benchmarks were sampled (about 25% of tasks per difficulty group) to control cost.
Why it matters for companies
Turning on parallel agents does not make work faster or cheaper by default; in this study it usually cost two to three times more tokens and took longer. Gains appeared only on large, decomposable tasks, while short tasks got worse. The failure list reads like a project management checklist: no owner for assembly, unequal workloads, sub-agents stopped early, results never collected. Teams should switch concurrency on per task type, and measure cost per solved task rather than activity.
Summary based on the full text. Read the original for the full argument and data.Read the original on arxiv.org
- Tags
- Coding agents, Cost of AI