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

"How many can I run?" is the first question everyone asks after their second agent. The answer people expect is a hardware number. It almost never is.

The machine is not the bottleneck

An idle agent session is a shell and a language-model client waiting on a network response. It costs you a few hundred megabytes and roughly no CPU. On a modern laptop you can have a dozen open before the fans notice.

The real constraints show up in this order, and hardware is last:

1. Your review capacity — how much generated code you can actually read and judge.
2. Merge contention — how often two agents touch the same files.
3. Rate limits and cost — your plan's ceiling, not your machine's.
4. Memory and CPU — usually only if you're also running builds, test suites, or containers per agent.

If you've ever had six agents finish at once and felt a small wave of dread, that was constraint #1 introducing itself.

Find your review number

There's a simple way to calibrate. For one week, note two things per task you hand an agent: how long the agent took, and how long you took to review and accept or redirect the result.

Your sustainable fleet size is roughly:

agent time ÷ your review time

If an agent works for 12 minutes and you need 4 minutes to review it properly, three is your steady state. Running eight doesn't make you faster — it makes five agents sit finished while you work through a queue, and it tempts you to skim. Skimmed AI output is where the expensive bugs come from.

This number is personal and task-dependent. Boilerplate migrations review fast; a change to auth logic does not. Most people land between three and six for real work.

Reduce contention before adding agents

The second constraint is cheaper to fix than the first, and fixing it is what lets your number go up.

• Give each agent its own working directory. Two agents editing one checkout will clobber each other. Separate worktrees or clones remove the whole class of problem.
• Split by boundary, not by ticket. One agent per module, package, or service beats one agent per issue, because issues cross files and modules mostly don't.
• Keep one agent as the integrator. A dedicated session whose only job is pulling branches together is more effective than trying to make every agent merge-aware.

Once agents can't step on each other, adding one more costs you only review time — which is the constraint you now know how to measure.

The tasks worth parallelizing

Not all work fans out. Good candidates share a shape: independent, verifiable, and boring to do serially.

• Applying one mechanical change across many packages
• Writing tests for modules that already have clear behavior
• Porting or upgrading a dependency in several services
• Exploratory spikes you intend to throw away

Poor candidates: anything where step two depends on what you learned in step one. Architecture decisions, tricky debugging, and schema design go faster with one agent and your full attention. Running four agents on one hard bug gives you four confident, mutually incompatible theories.

What actually breaks first

In practice the failure isn't a crash. It's losing track. At three sessions you remember which is which. At seven, terminal tabs all look the same, you type into the wrong one, and you can no longer answer "what is that agent doing right now?" without reading scrollback.

That's a tooling problem, and it's worth solving before you scale up:

• Identity — each session visibly labeled with its project and state, so you don't have to read output to know what it is.
• Grouping — the ability to send one instruction to a chosen subset, so "pull main and rerun the tests" doesn't mean typing the same line seven times.
• Durability — surviving a restart without losing every in-flight session, each in its own folder.

Get those three and your ceiling becomes your review capacity, which is where it should be.

A reasonable place to start

Run three. Measure your review time honestly for a week. Fix contention with separate working directories. Then add a fourth and see whether your throughput actually moved or you just acquired a longer queue.

Most people discover their number is smaller than their ambition and larger than their current setup comfortably handles. Both halves of that are fixable.