{"slug": "how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs", "title": "How much faster are parallel coding agents? About 1.5x, measured on 364 runs", "summary": "Parallel coding agents working on a single codebase delivered roughly 1.5x the throughput of one agent rather than N times for N agents, according to 364 timed Claude Code task runs in the Stackness repo between 2 July and 7 November 2026, which averaged 1.21 agents working at once and peaked at 1.46 during the busiest four days. A separate 106-task, six-agent run published in November 2026 measured 1.82, and the author's rule of thumb from the mythical-agent-month repo is that effective parallelism is about 0.3 times the agent cap. The author attributes the gap to agents waiting on the test suite, on each other's files and on the merge, concluding that adding a lane buys less than merging existing lanes sooner.", "body_md": "# How much faster are parallel coding agents? About 1.5x, measured on 364 runs\n\nParallel coding agents that work on one codebase deliver about 1.5 times the throughput of a single agent, not N times for N agents. Across 364 timed [Claude Code](https://stackness.dev/tools/claude-code) task runs in the Stackness repo between 2 July and 7 November 2026, I averaged 1.21 agents working at once. My busiest four days, with two lanes and up to four agents running, peaked at 1.46. The run that started the discussion on 6 November, 106 tasks with six agents, measured 1.82.\n\nSo plan for 1.2 to 1.8 times, whatever the agent count. Agents wait on the test suite, on each other's files and on the merge, and most hours of a parallel week have no agent running at all, because the next task waits for me to review a diff. Adding a lane buys less than merging the lanes you have sooner.\n\n## How much faster are parallel coding agents?\n\nParallel coding agents ran 1.2 to 3 times faster than one agent in the real projects I found numbers for, and under 2 times in every run whose timing includes its tests. The faster figures come from benchmarks that leave the tests out of the clock or from search branches that never merge. The table lists the published figures that compare wall clock time with the time the same work takes on one agent, as of 9 November 2026.\n\n| Run | Agents | Effective parallelism | Merges into one codebase | Tests in the timing | \n|---|---|---|---|---|\n| Stackness repo, 364 runs, July to November 2026 | up to 4 | **1.21** overall,**1.46** in the busiest window | yes | yes | \n| [mythical-agent-month](https://stackness.dev/tools/mythical-agent-month) , 106 tasks, published November 2026 | cap of 6 | **1.82** , falling from 1.7 to 1.4 in the later phases | yes | yes | \n| [Cursor](https://cursor.com/blog/scaling-agents) , browser project, January 2026 | 20 | \"two or three\" | yes | not stated | \n| [Co-Coder](https://arxiv.org/html/2606.00953) , DevEval and CodeProjectEval, May 2026 | 1 to 11 groups | **1.81** and**2.10** | yes | no | \n| Claude Code agent teams, in Co-Coder's CodeProjectEval runs, May 2026 | a team | **about 4** , passing 16.3% of tasks against 20.1% for one agent | yes | no | \n| [Vesper](https://arxiv.org/pdf/2605.15221) , algorithm search, May 2026 | 4 | **3.2 to 3.9** | no | its own evaluations | \n\nEffective parallelism is agent-hours divided by the hours in which at least one agent was running. It is the speedup over one agent doing the same tasks in a row. My 1.46 leaves the merge out, and the mythical-agent-month 1.82 already counts its 96 merge runs. A six-agent run at 1.82 uses 30% of its cap, which is where the [mythical-agent-month repo](https://github.com/MedAdemBHA/mythical-agent-month) gets its rule of thumb, \"effective parallelism ≈ 0.3 × your agent cap\".\n\nThe post behind this topic, [\"Claude quoted 50 days, subagents did it in 35h, and the slow part was me\"](https://www.reddit.com/r/vibecoding/comments/1xp9216/claude_quoted_50_days_subagents_did_it_in_35h_and/) on r/vibecoding on 6 November 2026, put it in one line: \"6 agents ≠ 6× speed. Real throughput was 1.8 agents.\" Its headline compares an estimate with a run, as one commenter pointed out, so \"50 days to 35 hours\" is not a speedup. The 1.82 comes from 64.2 agent-hours of work in 35.3 busy hours, read from 398 subagent transcripts. Cursor's own team later wrote [\"1-3\"](https://cursor.com/blog/self-driving-codebases) for the same 20-agent experiment.\n\n## The Stackness repo averaged 1.46 agents in its busiest four days\n\nMy busiest parallel stretch ran 1.46 agents at once. Between 11 and 15 October 2026 one git worktree built 21 organization tasks while the main checkout built 20 others, both through the same Claude Code task command. That came to 41 runs, 55.2 agent-hours and 37.9 busy hours across a 94-hour window. Adding the 56 minutes the merge took to the busy hours brings it to 1.42.\n\nEvery task in my repo runs through `/rock`, a Claude Code command I wrote that implements one task, runs the full check suite, does a security review, updates the end-to-end scenarios and commits. `/work` runs a batch of tasks, with a read-only prep agent reading ahead for the next one, and `/wt` starts a batch in its own [git](https://stackness.dev/tools/git) worktree with its own [PostgreSQL](https://stackness.dev/tools/postgresql) database, [Redis](https://stackness.dev/tools/redis) database and ports. Each run writes a timing report. I joined the 364 reports with the git log: a run ends when its commit lands and starts its wall time earlier.\n\n| Agents running at once | Hours, 11 to 15 October | \n|---|---|\n| 1 | 22.8 | \n| 2 | 13.1 | \n| 3 | 1.9 | \n| 4 | 0.1 | \n| none | 56.1 | \n\nFour agents ran together for about nine minutes. For 60% of the window no agent ran at all, in 19 gaps, seven of them longer than two hours and the longest 12.9 hours. Five of those seven ran overnight and two in the daytime, the longer one seven hours on a Tuesday. A `/work` batch runs its tasks back to back and stops when the batch ends or a task pauses on a question for me, so each gap is a lane waiting for me to answer or start the next batch. The Reddit poster wrote the same thing about their run: \"The slowest part was us: review, decisions, local setup.\"\n\nAcross all 364 runs since July the figure is 1.21, because most weeks I ran one lane. I ran a worktree lane three times, all in October, and the 1.46 comes from the longest of them.\n\n## The merge came 24 days later and git left 92 files to resolve\n\nThe merge is where a parallel lane pays back time it borrowed. My October worktree finished its last task on 15 October and was merged into stage on 8 November, 24 days later. By then stage had 96 new commits against the worktree's 46. Git could not merge 92 files on its own, and resolving them took a Claude Code session 56 minutes and four full check runs.\n\nThe four check runs in that merge failed on 15 lint and format errors, then on 8 Go tests in 3 packages, then on 15 of 11,541 frontend tests, and passed the fourth time. None of the failures was a textual conflict. While the worktree was open, stage had picked up new site-wide rules, a restyle with a new palette and type scale and a rule that every page names its own social card URL, each enforced by tests. The worktree's new pages broke tests that did not exist when they were written, and a test fixture with a fixed date expired while the branch waited.\n\nNothing forced the 24-day wait: I left the worktree open while stage moved on. The longer a lane stays open, the more of the other lane it has to absorb, and the merge cost grows with it. The mythical-agent-month run merged constantly instead: 96 merge runs, fast-forward only behind a per-repo lock, 2.2 hours in total. Its lock had a cost of its own. Locking by lane serialized its busiest repo, which the repo logs as \"Most of a phase at 1× parallelism\". It puts the later fall from 1.7 to 1.4 down to \"disk pressure, Docker restarts and usage brakes\".\n\n## A shared test suite slows down 37 to 54% with a second agent running\n\nA shared machine is the next queue after the merge. In my repo the median `make check` run took 2.12 minutes when no other agent was running and 2.90 minutes when another run overlapped at least half the task. For tasks touching up to 25 files it went from 1.81 to 2.48 minutes, 37% longer, and from 2.30 to 3.54 minutes, 54% longer, for 25 to 60 files.\n\nThe largest tasks showed no difference, 3.78 against 3.76 minutes, and part of the overlap is a read-only prep agent rather than a second test suite, so take the slowdown as a range. The Reddit run had it worse: three test slots for six agents on one 8-core laptop with local [Docker](https://stackness.dev/tools/docker) databases, and the laptop broke first. In the post's words: \"55 leftover test DBs filled the disk, Docker froze, test runs blew past the 10-min tool timeout.\" The repo puts the leftover databases at 4 GB, on a disk that was already low.\n\nThat 10-minute ceiling matches Claude Code's default `BASH_MAX_TIMEOUT_MS` of 600,000 milliseconds, in the [Claude Code environment variable docs](https://code.claude.com/docs/en/env-vars). The agent-loops project merged a [machine-wide test slot](https://github.com/andromarces/agent-loops/pull/849) on 15 October 2026, after its [issue](https://github.com/andromarces/agent-loops/issues/847) found that \"parallel full-suite test runs in different work trees, or in different projects, oversubscribe the host\", and defaults it to one slot per eight cores. Cursor found that once RAM was capped, \"the disk became the hotspot\". Each of my worktrees gets its own database for this reason, and my worktree script refuses a fifth.\n\n## Task size sets an agent task's wall time, not whether it touches billing\n\nBigger tasks take longer, and in my 364 runs the kind of code did not add time on top of size. Tasks that changed a migration, billing or auth code had a median wall time of 42.3 minutes against 22.6 for the rest, 1.87 times longer. But they were also bigger, with a median of 30.5 hand-written source files against 5.5. At equal size they ran 0.89 times as long as other tasks.\n\n| Hand-written source files changed | Billing, auth or migration, median | Other tasks, median | \n|---|---|---|\n| under 5 | 10.6 min (5 runs) | 16.4 min (121) | \n| 5 to 9 | 17.2 min (5) | 21.0 min (67) | \n| 10 to 19 | 27.9 min (18) | 28.3 min (53) | \n| 20 to 39 | 47.4 min (31) | 65.5 min (29) | \n| 40 or more | 64.7 min (29) | 51.0 min (6) | \n\nThe Reddit post reached the opposite conclusion: \"Risk matters more than size. Billing/auth/migration tasks took 2.7× longer, and every real bug was in them.\" Its 2.7 is a median of 30 minutes for high-risk tasks against 11 for normal ones. In that run the high-risk tasks also got a big model and a reviewer agent and ran 19 test commands each against 12, so the 2.7 measures the extra process as much as the code. Its own size table still runs from 4 minutes for an extra-small normal task to 12 for a large one.\n\nI count size as hand-written source files, leaving out tests, generated [Ent](https://stackness.dev/tools/ent) code, migrations and docs, because a migration task in my repo always regenerates code and a raw file count would make it look larger than it is. Every one of my tasks gets the same model, review and checks, so my numbers say nothing about whether billing code needs more review. The post's other claim stands on its own: all five bugs it caught before merge were in high-risk work.\n\n## The case for near-linear speedup\n\nThe strongest case against my thesis is Vesper. In a paper from May 2026, four agents in git worktrees reached a \"parallelism ratio (total sequential agent time divided by wall-clock time)\" of 3.2 to 3.9, cutting a run from about 70 hours to about 20. Co-Coder reached 2.10 on CodeProjectEval. If those numbers carried over, six agents would be worth five or six.\n\nThey do not carry over to a product codebase, and the papers say why. Vesper's agents run independent search branches that never merge into shared code, and its sequential time is a sum of per-agent times, not a second run. Co-Coder's latency leaves out test time, and the Claude Code agent teams it measured at about 4 times faster passed fewer tasks than one agent. Where agents have to land in one codebase, reliability drops too: [CooperBench](https://arxiv.org/html/2601.13295) found \"agents achieve on average 30% lower success rates when working together\", and the [Claim Plane](https://arxiv.org/pdf/2608.00947) study got 96.7% of its runs to integrate only by serializing 96.7% of them.\n\nI would be wrong if someone measured a run that merges into one shared codebase and runs its tests on one machine, from timestamps and with the merge included, at an effective parallelism above about 3. The mythical-agent-month repo ships `calibrate.py`, which reads Claude Code subagent transcripts and prints this number, and its author asked for a second data point. Nobody had added one to the repo as of 9 November 2026.\n\n## Estimate agent wall clock and human hours as two numbers\n\nEstimate agent wall clock as agent-hours divided by 1.5, add a merge per lane, and keep human hours as a separate number. Agent-hours come from your own history: the median task in my repo takes 26.7 minutes of agent time. On a laptop with a shared test suite, 1.5 is the honest divisor until your own transcripts give you a better one.\n\nThe mythical-agent-month repo writes the same idea as a formula, \"wall-clock = max(critical path + phase checks, agent-hours ÷ effective parallelism)\", and adds a failure tax of 15 to 25%. Its own estimator, fitted on phases 0 to 3 of the run, came out 37% short on wall clock for the 40 tasks of phases 4 to 9. Human hours do not shrink with lanes. Review, decisions and local setup grow with the number of commits, and the 56 idle hours of my October window were lanes waiting on me.\n\nMy recommendation for a team deciding how many agents to run: two lanes, a third only once every lane has its own database and test slot, and a merge into the main branch at least once a day. Past that, the lanes wait on you. [Claude Code's agent teams docs](https://code.claude.com/docs/en/agent-teams) also start small: \"Start with 3-5 teammates for most workflows.\" and \"If you have 15 independent tasks, 3 teammates is a good starting point.\"\n\nAn orchestration tool does not raise that ceiling: it starts lanes, and the lanes still share the tests, the merge and you. As of 9 November 2026, 8 real members list Claude Code on Stackness and none of them lists [Conductor](https://stackness.dev/tools/conductor), [Claude Squad](https://stackness.dev/tools/claude-squad) or [Vibe Kanban](https://stackness.dev/tools/vibe-kanban) ([data sources](https://stackness.dev/about/data-sources)). The worktree flag, subagents and [Cursor](https://stackness.dev/tools/cursor)'s eight parallel agents already ship inside the tools people use. The [AI coding tools developers list on Stackness](https://stackness.dev/categories/ai-tools) show what people pair them with, and the [setup and merge check for worktree agents](https://stackness.dev/blog/running-coding-agents-in-parallel-git-worktrees-and-the-merge-check) covers the git side.\n\n## Method and sample\n\nEvery number above from the Stackness repo comes from the timing reports its task command writes, joined with the git log, and the scripts and their output sit in the post's evidence folder. A run's end is the commit that added its timing report and its start is that time minus the report's wall time. A `/work` prep agent's read-ahead counts as part of its task, so one batch on its own shows a little overlap: prep phases came to 10.5 of the 312.6 agent-hours.\n\nThe sample is one repo, one developer and one harness: 364 runs between 2 July and 7 November 2026, all Claude Code, all in a [Go](https://stackness.dev/tools/go) and [Next.js](https://stackness.dev/tools/next-js) monorepo with an 11,541-test frontend suite. Overlap counts any two timed runs, so a worktree batch and the main checkout count as two lanes even when one was a small fix. The billing, auth and migration label comes from the paths a task changed. The mythical-agent-month figures are that author's measurement of one client project, whose raw timings are not published, so they cannot be recomputed.\n\n## Key numbers\n\n- **1.21** : effective parallelism of 364 timed Claude Code task runs in the Stackness repo,**2 July to 7 November 2026** (own measurement).\n- **1.46** : effective parallelism in the busiest window, two lanes and up to four agents,**11 to 15 October 2026** ; 1.42 with the merge (own measurement).\n- **60%** : share of that 94-hour window with no agent running,**11 to 15 October 2026** (own measurement).\n- **92** : files git could not merge on its own when that worktree merged**24 days** later, on**8 November 2026** (own measurement).\n- **37 to 54%** : longer`make check` runs with a second agent on the machine, July to November 2026 (own measurement).\n- **0.89x** : wall time of billing, auth and migration tasks against other tasks of the same size, July to November 2026 (own measurement).\n- **1.82** : effective parallelism of the 106-task, six-agent mythical-agent-month run, published**3 November 2026** ([mythical-agent-month](https://github.com/MedAdemBHA/mythical-agent-month) ).\n- **2 to 3** : Cursor's effective throughput for 20 agents,**14 January 2026** ([Cursor](https://cursor.com/blog/scaling-agents) ).\n\n## New posts by email\n\nAbout one email a week with what we published. No account needed.\n\n## Which of these do you use?\n\nNobody on Stackness runs mythical-agent-month yet. Tick what you use and be the first.\n\n[Play Lonny Eagle Amateur Skater 4A pixel art skateboarding game. Signing up opens it straight away.Sign up to play](https://stackness.dev/games/lonny-eagle)\n\nFor AI agents and assistants: a plain-text index of this site is at [/llms.txt](https://stackness.dev/llms.txt?via=agent-note), the full text at [/llms-full.txt](https://stackness.dev/llms-full.txt?via=agent-note), and Stackness has an MCP server for reading stacks and tools ([/docs/mcp](https://stackness.dev/docs/mcp?via=agent-note)).", "url": "https://wpnews.pro/news/how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs", "canonical_source": "https://stackness.dev/blog/how-much-faster-are-parallel-coding-agents-measured-on-364-runs", "published_at": "2026-11-09 08:29:19+00:00", "updated_at": "2026-11-09 08:51:28.569200+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Claude Code", "Stackness", "Cursor", "Co-Coder", "Vesper", "mythical-agent-month", "DevEval", "CodeProjectEval"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs", "markdown": "https://wpnews.pro/news/how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs.md", "text": "https://wpnews.pro/news/how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs.txt", "jsonld": "https://wpnews.pro/news/how-much-faster-are-parallel-coding-agents-about-1-5x-measured-on-364-runs.jsonld"}}