The pitch for parallel sub-agents is throughput. Break the job into pieces, run the pieces at once, finish sooner. Researchers at Nanjing University, Central University of Finance and Economics and the University of Illinois tested that directly, running Codex, Claude Code and Kimi Code across five benchmarks with each tool's own concurrency switched on, then off, holding the model, prompt, environment and time budget steady on both sides. The bill came to over $20,000 in API spend.
The parallelism did not buy speed. Average runtime went up rather than down in 14 of the 15 agent-and-benchmark combinations. Among tasks both modes finished, the concurrent run came in faster on roughly a quarter of them. Token consumption reached as much as three times the sequential figure.
"These results indicate that the current concurrency mechanisms generally trade substantially greater resource consumption for limited aggregate effectiveness gains."
Success rates moved in both directions, and where they moved is the useful part. Concurrency helped on the longest tasks, the ones that mean building or sustaining a whole repository, tens of thousands of lines of output. On short, bounded bug-fix tasks it hurt. One agent's success rate fell by 24 percentage points once it was allowed to spawn sub-agents, and another fell by a similar margin.
The failed runs say more than the scores do. The largest single group of failures was sub-agents overwriting each other's work, with two agents editing the same file, a finished deliverable clobbered by a straggler, two sub-agents fighting over the same scratch directory, and in one run a sub-agent swapping out the shared git binary underneath everyone else.
"These problems arise when concurrent agents read or modify shared files, artifacts, or environments without proper coordination, resembling data races in traditional concurrent programs."
These aren't reasoning failures, and no better model fixes them. They're the ordinary failure modes of concurrent programming, and the discipline has had answers for decades in ownership, isolation, locking and a merge step somebody is accountable for. On this evidence these harnesses are missing a scheduler, and a smarter model won't supply one. Vendors have shipped the fan-out and left the merge to improvisation.
So the decision in front of a team is narrower than "do we use multi-agent." Treat parallel execution as a switch, not a default, and set the test at the work rather than the tool. If two sub-agents are going to touch the same files, the concurrency is a liability before it's a speedup. A concurrency feature sold on latency deserves wall-clock numbers on tasks the buyer recognises, since this study found the parallel runs mostly finishing later.
One caution against over-reading it. Concurrency also solved tasks the sequential run never solved, including on the benchmark where its overall score was worse. The ceiling and the average moved in different directions.
The authors recommend enabling it selectively rather than by default, which their own data supports. But the cost of these runs allowed only one attempt per combination, so the study can't separate how much of any single agent's swing is the concurrency policy and how much is run-to-run randomness. Nor does it test its own explanation, since the coordination failures were catalogued, never fixed and re-run, so whether better plumbing would recover the losses remains open.
Sources
- Li, H., Li, H., Jiang, Z. et al., "When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks" — https://arxiv.org/abs/2610.10263