How Many Agents Can You Actually Run at Once?

The machine is not the limit. You can start twenty agents on a laptop. You cannot review twenty diffs. The real ceiling is your own attention, and for most people running agents like Claude Code or Codex on real work it sits somewhere around three to five at a time.

That number isn’t a technical cap. Nothing in Claude Code enforces it. Anthropic’s own guidance on team size says there’s no hard limit, then recommends starting with three to five, notes that token cost scales linearly with each one you add, and lands on “three focused teammates often outperform five scattered ones.” Which is the same shape as what people find by trial: the fourth agent helps, the ninth is theatre.

Here’s what actually binds, roughly in the order you’ll hit it.

Four constraints, and the order they bite

1. Your review capacity. Every agent produces work you have to read before it lands. That’s the bottleneck, and it’s the one nobody plans for. Reading a 400-line diff you didn’t write, well enough to catch the thing that’s subtly wrong, takes real minutes of full attention. Three agents finishing at once is a queue, not a speedup.

2. Token spend. Each parallel agent carries its own context window and pays for it independently. Anthropic’s writeup on their multi-agent research system puts the multiplier at roughly fifteen times the tokens of a single chat for a fan-out research task. Coding work has a different profile, but the direction is the same: parallelism is bought with tokens, not saved on them.

3. Rate limits. Subscription plans meter on a rolling window plus a weekly cap, and both are per account rather than per session. Five agents don’t get five quotas. They get one quota, consumed five times faster, and they’ll cause rate limiting sooner than the same total work done in sequence. On API billing the ceiling is just money.

4. Memory and machine. Each session holds its context plus its own MCP server processes. It adds up, and a dozen sessions on an 8GB machine will be noticeable. But this is the constraint that binds last for almost everyone. If RAM is what stopped you, you got much further than the previous three should have allowed.

Notice that three of the four are invisible while they’re happening. You don’t get a warning that you’ve exceeded your review capacity. You just merge something you skimmed.

Why more agents ships less code

Past a certain point, adding agents reduces the amount of work that actually lands. Three reasons, all mechanical.

Review becomes the queue. If you can properly review two diffs an hour and you’re running six agents, four of them are producing work that sits unreviewed. Unreviewed work isn’t shipped work. It’s inventory, and like all inventory it goes stale: the branch drifts, the assumption it was built on changes, and by the time you get to it you’re re-reading a codebase that moved.

Coordination cost is quadratic. Two agents on one repo have one boundary to manage. Six have fifteen. Each pair can collide on a shared file, contradict each other’s refactor, or duplicate the same helper under two names. Even with clean isolation, integrating six branches is a different job from integrating two, and that job is yours.

Supervision degrades. With two agents you notice when one goes down a wrong path in its third tool call. With eight, you notice when it hands you the finished result. Catching a wrong turn in minute three instead of minute forty is most of what supervision buys you, and the more agents you run, the less of it you do. An agent that ran forty minutes in the wrong direction has cost you more than the agent you didn’t start.

This is the same argument made from a different angle in roundtable agent orchestration: the count of agents isn’t the metric. How they coordinate, and whether you can see them do it, is what decides the outcome. “Manage hundreds of agents” is a headline, not a workflow.

Parallel subagents are a different question

Two things get called parallel agents, and they behave nothing alike. Worth separating, because the right number is different for each. (The full breakdown of what people mean by “agents” is in Claude Code agents.)

Parallel sessions are what you start yourself: separate processes, separate terminals, each one you can watch, interrupt, and correct mid-flight. You are the orchestrator. The count that matters is how many you can supervise.

Parallel subagents are spawned by an agent from inside a session. The parent hands out tasks, the subagents work in their own context windows, and you see a summary of what came back. Their reasoning never enters your view, and it never enters the parent’s view in full either, only whatever the subagent chose to report.

That invisibility changes the calculation. Subagents don’t consume your attention while they run, so you can afford more of them, and they’re genuinely good at read-only fan-out: search this codebase five ways, check these six files, gather and summarize. What they’re bad at is writing. When several subagents make changes on partial information, they contradict each other and the parent stitches together a result that no single agent would have produced on purpose. Fan out for reading, keep writing narrow.

So: more subagents when the task is research, fewer sessions when the task is code you have to merge.

How to pick a number for real work

Start from your review throughput, not from your CPU count.

Ask how long a task takes and how long its review takes. If an agent works for twenty minutes and the diff takes you ten to review properly, you can sustain two agents indefinitely. Three, and you fall behind. That ratio is the actual answer, and it’s different for a test-writing task than for a schema migration.

Match agent count to independence, not to ambition. Two agents on genuinely unrelated features is easy parallelism. Two agents on the same subsystem is one agent’s work with extra merge conflicts. Before starting a third, ask what file it will touch that the other two won’t.

Give each writing agent its own working directory. Non-negotiable past one. A git worktree per agent means each has its own branch, staging area, and file state, and their collisions become ordinary merges instead of silent overwrites. Two agents on the same repo covers exactly how the naive version fails.

Stagger the starts. Launching four agents simultaneously means four reviews landing simultaneously. Offset them by ten minutes and the same four agents feed you a steady queue instead of a pile.

Add one, then measure. The honest test is not “did it feel busy.” It’s how much merged into main today. If it went up, you had room. If it went down, you found your ceiling, and it’s lower than you’d like. Everyone’s is.

When the count is limited by not knowing what’s happening

There’s a version of this problem that isn’t really about capacity. If you’re running four agents and three of them are done, but you can’t tell which without clicking through four terminal tabs, you’re running at one agent’s throughput with four agents’ token spend. An agent waiting on an approval prompt looks identical to an agent thinking hard, and it will wait all afternoon.

Fix the visibility and the sustainable number goes up on its own, without any change to your machine or your plan. That’s the specific problem crystl exists for: sessions listed rather than hunted for, approvals surfaced in one place, a visible signal for which agent is working, finished, or parked. Parallel sessions has the mechanics, monitoring multiple agents has the argument, and managing multiple AI sessions has the habits that help even without any tooling.

But the ordering holds regardless of what you run it in. Review capacity first, tokens second, rate limits third, hardware last. The agent you can’t review isn’t helping.