How many AI coding agents can you actually run at once?
Ten. That is the number of coding agents I can keep busy at once on one subscription, and the limit has never once been the model. It is four shared resources underneath the agents: the link to the vendor and its quota window, the git checkout, the network port the test suite binds, and the one file every branch regenerates. Push past ten and one of those four gives way before any agent produces a bad line of code.
Yesterday 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.
Questions this post answers
- How many AI coding agents can run in parallel on one subscription?
- About ten workers at a time, in my experience, and three or four per vendor. A wave of frontier-tier agents tripped my subscription's limits on 2026-07-06, so the frontier model now supervises alone and the workers run on cheaper tiers across three vendors. When four parallel launches on one CLI lost two runs within three minutes, my own resolver was failing that hour, so that one counts against my network, not the vendor. The binding limits are the vendor's quota window and the link to it, not the number of processes your machine can hold.
- What breaks when several coding agents work on the same repository?
- Shared state, not code. In one seven-agent wave: two branches conflicted on the same generated index file, two sessions verifying at once fought over port 3000 and produced false end-to-end failures, a shared checkout was moved by another session in the middle of a run so a passing verification was recorded against the wrong commit, and a cleanup step followed a filesystem junction and deleted the shared node_modules. Every agent needs its own worktree with its own dependencies.
- Do parallel coding agents make a project faster?
- They make typing faster. Verification stays serial. In the same wave, seven agents finished their edits inside about forty minutes of wall clock, and landing the five resulting branches through a one-at-a-time verification gate took roughly four more hours. The throughput ceiling is branches verified per hour, not agents running.
- Should each AI agent get its own git worktree?
- Yes, with a real copy of node_modules, not a junction or symlink to the shared one. Kill the agent's CLI before touching its worktree, unlink any junction before deleting the tree, and rebase and regenerate generated files before running the verification gate.
Keep reading
An orchestration mode is only as good as its backlog
Anthropic published a guide on building a session-level orchestration mode. I built it two ways, on the CLI and on the API, and then hit the part the guide does not cover: an orchestrator that fans out is useless without a backlog of real work to fan out over.
Fable Thinks, Opus Builds, Kimi Types
I split a day of development across two AI subscriptions: judgment on the Anthropic meter, typing on Moonshot's. Five merged PRs later, here is where the tokens went, how K3's pricing actually compares, and how I'm tuning the mix.
Leverage by subtraction: keeping an AI agent fleet small enough to maintain
The instinct with agentic tooling is to add: more agents, more skills, more clever prompts. The leverage runs the other way. Here is the test I use to decide whether a piece of work should be a script, a hook, a skill, or an agent, and why most of them should not be an agent at all.
One summer of building with AI agents, counted commit by commit
The third post in the SDD numbers series is not about velocity. Since June the platform's effort moved into four quiet systems: an externalized memory, a statistical screen that refuses to flatter me, a point-in-time data floor, and a product designed entirely on paper. What that did to the shape of a productive week.
Watch the agent write
A polish agent drafts an essay against a pre-approved topic.
Multi-Region Workflow Orchestration Platform
Own the multi-region orchestration platform: shared execution guarantees, mandatory safety checks, and self-service onboarding for development teams.
Follow the work
New tools and writing as they ship — pick a channel.