How Many Claude Code Agents Can One Machine Actually Run?

I had six Claude Code agents open across three worktrees last week, each mid-task, and Activity Monitor showed 4% CPU. Not 4% per agent, 4% total, on a laptop that was otherwise doing nothing. That's the part nobody warns you about when you go from one coding agent to several at once: the number you can run isn't bounded by how much compute your machine has, because your machine isn't doing the compute that would normally worry you.

The model runs somewhere else entirely

Every time Claude Code sends a prompt, that call goes over the network to Anthropic's servers. The forward pass, the thing that would actually spike a GPU to 100%, happens in a datacenter you don't own and never touches your CPU. What runs on your machine is a thin client: a process that renders a PTY, calls tools (read a file, run a shell command, apply an edit), and waits for the next response. Most of an agent's lifetime, especially on anything past a one-line fix, is spent waiting on that round trip.

This is why watching Activity Monitor while an agent "thinks" is misleading. The spinner in your terminal isn't doing anything computationally interesting on your machine, it's holding a connection open. Five agents in that state at once means five idle processes waiting on five HTTP responses, not five cores pegged at 100%.

What's actually eating resources locally

None of that means concurrency is free. Three things cost you something, and they cost you in different currencies.

Idle memory per agent. Each running agent is a process, sometimes a few (the CLI itself, any MCP servers it spawned, a language server if your editor is open on the same project) that sits in RAM for as long as it's alive, working or not. A reasonable idle estimate is 300 to 600MB per agent once you count its editor tooling, though this swings a lot with project size, how many language servers are attached, and what else that workspace loads on start. Treat it as a planning number you verify on your own machine, not a spec.

Disk IO under concurrent load. When two or three agents kick off git status, a test run, or a build within the same few seconds, they're competing for the same disk queue. On a lightly loaded SSD this is invisible. On a spinning disk, a heavily loaded NVMe drive, or a git worktree setup where several checkouts share the same underlying object store, it's the first thing that visibly stalls.

Bursty CPU. An agent idle between model calls costs almost nothing. An agent that just told a shell tool to run your full test suite or kick off a compile does not. These spikes are real, but they're short and staggered rather than sustained, since your agents aren't all running builds in the same second, they're each at a different point in their own task.

Try it: estimate your own number

The formula below is deliberately simple, meant as a starting point you adjust after watching your own machine under real load, not a guarantee. It reserves 8GB for the OS and your editor, divides what's left by 0.5GB per agent for a memory-based ceiling, then caps that number at three times your core count, on the assumption that once memory stops being the constraint, bursty CPU from concurrent builds and tests is the next one to hit.

Drop RAM to 16GB on an 8-core machine and the memory ceiling binds first (16 agents, well under the 24-agent CPU cap). Push RAM up to 64GB on that same 8-core machine and the answer doesn't move, it's still 24, because the CPU cap is now what's binding. Past a certain point on a given core count, more RAM alone stops buying you more agents. If you want the number to keep climbing, you need more cores, not more memory.

A rough budget by machine size

Same formula as the calculator, applied to a few common configurations. These are illustrative, not measurements of any specific machine, and they're here as a sanity check before you plug in your own numbers.

The pattern worth noticing: below roughly 20GB of RAM on an 8-core machine, memory is the wall no matter what else you throw at it. Above that, the CPU cap takes over and stays flat until you add cores. Neither of these estimates accounts for what happens on disk, which is the part that actually surprises people.

Where it actually breaks: disk, not RAM

In practice, the first symptom of pushing concurrency too far isn't an out-of-memory error, it's everything getting slow. When several agents each try to run git operations against worktrees that share the same repository's object store, or multiple test suites hit the disk within the same window, you get contention that shows up as tool calls taking noticeably longer, terminal output stalling, or an agent that looks hung when it's actually just queued behind someone else's disk access.

This is worth watching closely if you're already running one agent per git worktree, since worktrees are cheap to create and do isolate the working directory, but they still funnel through the same underlying .git object database and index locking. A burst of concurrent git operations across five or six worktrees can queue up in a way that's easy to misread as an agent problem when it's really a disk problem. Spinning disks feel this first and worst. A loaded NVMe drive under six simultaneous test runs will feel it too, just later and less dramatically.

The practical takeaway: if agents start feeling sluggish before your RAM usage looks alarming, don't reach for more memory. Check what's happening on disk first, especially git status calls, build output, and test runs landing at the same moment.

What Bernato does and doesn't enforce here

Bernato doesn't put a hard ceiling on how many agents you can run on a machine. Nothing in the runtime, the bernatod daemon plus the dashboard, stops you from starting a tenth or twentieth session; that number is on you to work out. What Bernato gives you instead is visibility: fleet supervision across every machine you own, a live PTY per agent so you can see what each one is actually doing rather than guessing from a spinner, and capability-token sandboxing (workspace_rw, network, subprocess, screen_capture, accessibility, full_disk_access) so each agent's blast radius stays scoped even when you're running a lot of them at once.

If you're going to push concurrency past what feels obviously safe, that visibility is what tells you when you've crossed from comfortably parallel into fighting the disk, instead of finding out from a stalled terminal an hour into a task.