How many AI coding agents can you actually run at once?

I cap my setup at roughly ten concurrent coding agents across several subscriptions, usually three or four per vendor. That number comes from running this workload on my machine. The constraints I have hit are the link to the vendor and its quota window, the git checkout, the network port the test suite binds, and the file every branch regenerates.

Before launching parallel coding agents#

Shared resource	Check before starting the wave	When I stop adding workers
Vendor connection and quota	Check that a single CLI run completes, then allocate workers across the subscriptions available.	Launches fail or the quota window is exhausted; I inspect the error and connection before retrying.
Checkout and dependencies	Give each worker a separate git worktree and a real dependency install. Record the commit under test.	Verification would use a checkout another session can move.
Test-server port	Check which process owns the test port. Keep full verification serial while suites share it.	Another verification is already using that port.
Generated files	Name the files each build regenerates, even when the source edits do not overlap.	A branch needs rebasing and regeneration after the previous merge.

I bind the passing checks to the commit being reviewed; the local CI gate explains that record. The monthly agent cost breakdown records the subscriptions behind this setup. Neither a worker count nor a subscription price tells me how many branches I can finish verifying in an hour.

What happened in a seven-agent wave#

The day before I wrote this, I ran seven at once and kept a tally of what gave way. The job was a batch of site fixes from a traffic audit: retitle thirteen posts, add a series hub, fix the footer and a dozen links, gate an analytics tag, wire a post-deploy ping, and wire a new exporter into a CDK stack. Each fix had a written brief with the exact files, the verify commands, and an out-of-scope list. I run worker CLIs from three vendors. I put three briefs on one CLI and four on another, each in its own git worktree, and started them within the same minute.

The link to the vendor gives way first#

Two of the four launches on the second CLI exited within three minutes with nothing written. No error text, exit code 1, a thread that had read the brief and then stopped. A third wrote one component and died; the fourth wrote a footer link and died. When I probed that CLI by hand the failure was hostname resolution, Windows error 11002, and my home connection was flapping that hour: pushes to the code host were failing on the same resolution error. That one is on my network. The other CLI, reached over the same connection, stayed up through the flap, and I re-dispatched the four briefs to it rather than wait for the line to settle.

The quota itself has been the ceiling once, and that one was mine to cause. On 2026-07-06 a wave of frontier-tier subagents tripped the subscription's limits, and the routing rule that came out of it is the one I still run: the frontier model supervises alone, at the session level, and never fans out to copies of itself. Workers run on cheaper tiers or on other vendors' subscriptions, capped at roughly ten concurrent, and each vendor gets three or four at a time, not seven. The quota window is a shared resource the same way a database connection pool is, and the agents draining it do not coordinate. A flapping resolver is the same resource failing from the other end.

The checkout gives way second#

Every worker had its own worktree, so the agents never touched each other's files. The shared state that bit was the canonical checkout, the one directory with the real dependencies installed, because the merge gate's full verification wanted to run there. Another session on the same machine was using it for the same purpose at the same time. The reflog for that hour reads like two people grabbing the same steering wheel: detach to their commit, detach to mine, back to theirs, back to main. One of my runs passed every check and then recorded its passing verdict against a commit that was not the one it tested, because the other session had moved the checkout between the last test and the write.

The fix was to stop sharing the checkout at all. Each worktree got a real copy of the dependency tree, about a gigabyte and two minutes per copy, and the verification ran inside the worktree it was verifying. The cost is disk. The alternative is a verdict recorded against a commit nobody tested.

The port gives way third#

The end-to-end suite starts a local server on port 3000. Two sessions running that suite at once do not get two servers; the second connects to the first session's server and asserts against the wrong build. Three of my verification runs failed only on the end-to-end lane, with the unit suite green and the same spec passing in isolation seconds later, and every one of them coincided with another attestation holding the port. A failure that reproduces only when a neighbor is running is not a flake. It is a shared resource with no lock on it, and until there is a lock the rule is one full verification at a time, machine-wide.

The generated file gives way last#

Five branches merged in sequence, and every one had to be rebased onto the main that the previous merge had just moved. Two of them conflicted, both on the same file: the blog index that the build regenerates from post frontmatter. Two agents that never edited the same source file still collided, because the build had written the same derived artifact on both branches. The resolution is mechanical once you know it, take main's copy, regenerate, continue, but it has to happen on every branch, and a wave of ten guarantees it happens ten times.

The same class of problem produced the worst moment of the day. Cleaning up, I removed the finished worktrees with the version control tool's own remove command. Their node_modules directories were junctions into the canonical checkout, and the recursive delete followed the junctions and emptied the canonical dependency tree for two repositories, which cost every session building from those checkouts its toolchain until a reinstall finished. Nothing in version control showed it, because the directory is ignored. The teardown procedure now checks for junctions and unlinks them before any delete, and it caught a second one on the very next run, planted by the build tool inside its own cache directory.

What ten agents buy#

The seven agents finished their edits inside about forty minutes of wall clock, most of it waiting on the four that had to be re-dispatched. Landing the five resulting branches took roughly four more hours, because each one had to be rebased, pushed, verified for about eight minutes through a gate that admits one branch at a time, and merged before the next could start, and three of those verifications had to run twice. Typing was parallel. Everything that made the typing safe to keep was serial.

That ratio is the actual answer to the question. Agents are cheap to add up to the point where the quota, the checkout, the port, or the generated file pushes back, and each of those pushes back at a different count. The number that moved my throughput this year was never the count of agents typing. It was the count of branches I could verify in an hour, and every rule above exists to raise that second number by one.