How many coding agents fit on one box?
Nobody publishes this number, so we measured it: nine coding agents, each ramped on its own identical 8 GB machine until the box ran out of room.
- 298 MB
- First session
- 167 MB
- Every session after it
- 997 MB
- A hard-working session
Pays for the shared runtime the rest go on to use.
Marginal cost across the 1 → 32 ramp, idle.
p90 of 17 observed sessions actually doing work.
How many can you run?
Pick the machine you actually use. Each figure is that agent's own measured cost, at the version we tested.
assumed 4 GB reserved for the OS, browser and editor already running. A server needs far less.
On a 16 GB laptop, memory only limits OpenCode and Gemini CLI. The rest fit more idle sessions than you would realistically open.
Pi
0.83.050+sessions
156 MB first, then 104 MB each · live session
Claude Code
2.1.22850+sessions
298 MB first, then 168 MB each · live session
OpenCode
1.18.1633sessions
699 MB first, then 278 MB each · live session
GitHub Copilot CLI
1.0.7950+sessions
235 MB first, then 164 MB each · repl, no credentials
Gemini CLI
0.55.138sessions
356 MB first, then 253 MB each · repl, no credentials
Grok CLI
1.0.0 (3cd0d0cbce)50+sessions
75 MB first, then 13 MB each · login screen
OpenAI Codex
0.147.050+sessions
122 MB first, then 19 MB each · login screen
Cursor CLI
2026.08.11-e8db85450+sessions
174 MB first, then 108 MB each · login screen
Amp (Sourcegraph)
0.0.1786509137-g755e1f50+sessions
157 MB first, then 115 MB each · login screen
Memory is only the first limit. A 4-core machine will run out of CPU and disk long before it runs out of room for dozens of agents, which is why counts above 50 are shown as "50+" rather than a precise-looking number nobody should act on. These are also sessions sitting open and idle. An agent actually working costs more: on a developer box we watched, the median Claude Code session doing real work measured 238 MB and the p90 measured 997 MB. Halve these numbers if you expect every session to be busy at once, and read the session-state column before comparing two agents.
Size your own box
Every figure here is one of the measurements further down the page. Nothing is a multiplier we made up.
Sessions working in parallel.
Usually one per project you keep running.
Playwright, Puppeteer, screenshot tooling.
Running alongside the agents, not after them.
Memory you need
1.9 GB
1.6 GB of workload, plus 15% headroom.
- OS and shell0.3 GBmeasured 348 MB, measured at rest on a stock Computer before any agent started
- 4 × Claude Code (working)0.9 GBmeasured 238 MB per session, median of 17 observed working sessions
- 1 × Vite dev server0.3 GBmeasured 353 MB peak, measured over 64 samples
- Headroom0.2 GBassumed The one number here we chose rather than measured. Linux kills the biggest process instead of slowing down.
Cheapest Computer that fits
Personal
$48/mo
4 vCPU · 8 GB memory · 64 GB disk, capped at 5 parallel agents.
Start freeSelf-hosting instead? Buy a 2 GB box (see below) and follow the VPS guide. The software is free either way.
Every coding agent, same box, same ramp
Each CLI was ramped on its own identical 4 vCPU / 8 GB Computer (7.8 GB of that is actually allocatable), with the same harness and the same steps. The bar is the marginal cost: what one more open session added, once the first had paid for the shared runtime. Measured 2026-08-12.
Only compare within a group. An agent stuck on a sign-in screen has not loaded a session at all, so it will always look lighter than one that has. That is a property of our test credentials, not of the agent.
Live session
Signed in and sitting in a real REPL. These are comparable with each other.
REPL, no credentials
Interface fully loaded, but no credentials. Auth is only enforced when you send a prompt.
Login screen
Never got past a sign-in screen. A floor, not a footprint: these numbers would rise once signed in.
Memory added per extra open session, measured to 20 sessions for every agent
Full numbersFirst session, marginal cost, how far each ramp got, and session state
| Agent | Version | First | Each after | Held | Session state |
|---|---|---|---|---|---|
| Grok CLI | 1.0.0 (3cd0d0cbce) | 75 MB | 13 MB | 32/32 | Login screen |
| OpenAI Codex | 0.147.0 | 122 MB | 19 MB | 32/32 | Login screen |
| Pi | 0.83.0 | 156 MB | 104 MB | 32/32 | Live session |
| Cursor CLI | 2026.08.11-e8db854 | 174 MB | 108 MB | 32/32 | Login screen |
| Amp (Sourcegraph) | 0.0.1786509137-g755e1f | 157 MB | 115 MB | 32/32 | Login screen |
| GitHub Copilot CLI | 1.0.79 | 235 MB | 164 MB | 32/32 | REPL, no credentials |
| Claude Code | 2.1.228 | 298 MB | 168 MB | 32/32 | Live session |
| Gemini CLI* | 0.55.1 | 356 MB | 253 MB | 28/28 | REPL, no credentials |
| OpenCode* | 1.18.16 | 699 MB | 278 MB | 20/20 | Live session |
A * marks a run whose box locked up before the harness could write its own result file; those steps were recovered from the run's live log. "Held" is how far the ramp got before the kernel started killing sessions. Where it says OOM, that is a real out-of-memory kill on this box, not a projection, and the marginal cost above is measured over the last step where every session was still alive. Using the failing step instead would divide a shrunken total by the full session count and flatter exactly the agent that just fell over.
What each session actually showedThe terminal output behind every row, quoted
- Grok CLI · curl -fsSL https://x.ai/cli/install.sh | bash (native binary, no node)launched:
grokGrok logo, "Connecting…", then "Approve in your browser to finish signing in." with a device code and "Waiting for approval…". - OpenAI Codex · bun install -g @openai/codexlaunched:
codex"Welcome to Codex, OpenAI's command-line coding agent" → "Finish signing in via your browser" with an auth.openai.com OAuth link. - Pi · bundled in the image (@earendil-works/pi-coding-agent)launched:
pi/home/user/repo (main) · 0.0%/1.0M (auto) · claude-opus-4-8 • medium · pi v0.83.0 - Cursor CLI · curl https://cursor.com/install -fsS | bashlaunched:
cursor-agentSigning in — "If your browser didn't open, click this link to log in: https://cursor.com/loginDeepControl?challenge=…" - Amp (Sourcegraph) · bun install -g @sourcegraph/amp (resolves to @ampcode/cli)launched:
ampNo API key found. Starting login flow… "Would you like to log in to Amp? [(y)es, (n)o]:" — parks there indefinitely. - GitHub Copilot CLI · bun install -g @github/copilotlaunched:
copilot"Please use /login to sign in to use Copilot", with the normal dashboard chrome (Current/Sessions/Issues/Pull requests tabs) and /home/user/repo [main]. - Claude Code · bun install -g @anthropic-ai/claude-codelaunched:
claudeTerminal capture not retained for this run. - Gemini CLI · bun install -g @google/gemini-clilaunched:
gemini --skip-trustReaches a real "Get started — How would you like to authenticate?" menu (Sign in with Google / API Key / Vertex AI). Bare `gemini` instead blocks on an interactive folder-trust prompt, so `--skip-trust` was required to reach an idle REPL at all. - OpenCode · bun install -g opencode-ailaunched:
opencodeopencode logo, prompt box "Ask anything...", status bar "Build · Claude Sonnet 4.6 · Anthropic", cwd /home/user/repo
Where to get the box
The same 4 vCPU / 8 GB shape as the machine we benchmarked, priced at four providers. Read off each vendor's own pricing page on 2026-08-12; they move, so check before you buy. The agent software is free and open source on all of them.
| Provider | Plan | Spec | Per month |
|---|---|---|---|
| OVHcloudCheapest of the four at this spec; listed as a 'from' price. | VPS-2 | 4c · 8 GB · 75 GB | $8.50 |
| HetznerSpecs from Hetzner's own plan page; price is region-picked client-side, so check it there. | CPX32 | 4c · 8 GB · 160 GB | check |
| DigitalOcean | Basic Droplet 8 GB | 4c · 8 GB · 160 GB | $48.00 |
| Akamai (Linode)North America pricing page. | Linode 8 GB | 4c · 8 GB · 160 GB | $48.00 |
| omg ComputerManaged, with the agent stack and a phone client already on it. | Personal | 4c · 8 GB · 64 GB | $48 |
Read that table honestly: on machine cost alone a VPS wins, and our own guide walks you through setting one up. What a managed Computer buys is the part after the machine. Keeping it alive, the phone client, and not being the person who gets paged when it dies. Start with the free path; pay someone else when the box becomes a chore.
The evidence
Every number above came from a measurement we ran. Here is all of it.
The ramp32 Claude Code sessions on one 8 GB Computer, step by step
Total memory used by every agent process tree as sessions were added, sampled 8 times per step after a 20s settle. The line is close to straight, which is the useful part: after the first session, each additional one costs about the same 167 MB. The run finished the whole ladder with 2.2 GB still available, no swap, and no OOM kills.
Concurrent sessions
Show the numbers
| Sessions | Total | Median each | MemAvailable | OOM kills |
|---|---|---|---|---|
| 1 | 0.29 GB | 298 MB | 7.27 GB | 0 |
| 2 | 0.46 GB | 235 MB | 7.09 GB | 0 |
| 4 | 0.79 GB | 202 MB | 6.76 GB | 0 |
| 6 | 1.11 GB | 190 MB | 6.44 GB | 0 |
| 8 | 1.43 GB | 185 MB | 6.11 GB | 0 |
| 12 | 2.08 GB | 178 MB | 5.46 GB | 0 |
| 16 | 2.74 GB | 174 MB | 4.80 GB | 0 |
| 20 | 3.40 GB | 173 MB | 4.15 GB | 0 |
| 24 | 4.06 GB | 172 MB | 3.47 GB | 0 |
| 28 | 4.70 GB | 171 MB | 2.81 GB | 0 |
| 32 | 5.36 GB | 171 MB | 2.15 GB | 0 |
Idle versus workingWhy one number for 'RAM per agent' is misleading
The ramp above is the flattering number, and quoting it alone would be dishonest. Those sessions were open and waiting. To get the other end we watched a real developer machine for 10 minutes with 17 Claude Code sessions on it doing actual work: reading files, running builds, spawning subagents.
167MB
Open, waiting
Sessions parked at a prompt between tasks.
ramp marginal cost on a clean Computer
238MB
Working
Reading, editing, running the odd command.
median of 17 observed working sessions
997MB
Working hard
Builds, test suites and subagents underneath each session.
p90 of 17 observed working sessions
That is an eightfold spread on the same agent, which is why "how much RAM per agent" has no single honest answer. The one figure worth memorising is the worst case, because that is the one that decides whether a session survives.
What fits on each planSessions per Computer tier, at three measured intensities
Claude Code sessions per tier, at three measured intensities. On every tier the plan's own agent cap binds before memory does.
Personal
5sessions
8 GB · $48/mo · limited by the 5-agent cap
Pro
16sessions
16 GB · $149/mo · limited by the 16-agent cap
Always On
24sessions
36 GB · $498/mo · limited by the 24-agent cap
Method, and how to repeat itHow it was measured, and a script to check it on your own machine
Both datasets measure the whole process TREE of each session, meaning the CLI plus its MCP servers, language servers and anything it spawns, in proportional set size, which splits shared pages between the processes mapping them. Summing RSS instead would count the shared runtime once per agent: the same ramp reads 340 MB per session in RSS against 238 MB in PSS.
- The ramp (idle)
- A stock omg Computer with 4 vCPU, 7.8 GB usable, Linux 6.1.177, carrying 348 MB in use at rest. Sessions were started 20s apart in a pty so each behaved like a real REPL, then sampled 8 times per step. Run on 2026-08-12.
- The observation (working)
- A 8-core, 22.9 GB developer box carrying 17 Claude Code sessions through real work, sampled every 2s for 10 minutes (247 sweeps). Each session's figure is the peak of its own tree. Run on 2026-08-12.
The other things sharing the box
Measured the same way, by starting each one and sampling its tree until it exited or the window closed. Peaks, not averages: these are spikes that have to fit while every agent is also resident.
- Vite dev server
bun run dev353 MB peak - Production build
bun run build432 MB peak - Headless Chromium
/home/dev/.cache/ms-playwright/chromium-1234…526 MB peak
Measure your own box
Paste this on any Linux machine while your agents are working. It walks /proc, sums each agent's process tree, and prints one line per session. Nested subagents are counted inside their parent's total as well as their own.
python3 - <<'PY'
import os, re, collections
proc = {}
for pid in filter(str.isdigit, os.listdir('/proc')):
try:
st = open(f'/proc/{pid}/status').read()
pss = re.search(r'^Pss:\s+(\d+)', open(f'/proc/{pid}/smaps_rollup').read(), re.M)
except OSError:
continue
proc[int(pid)] = (int(re.search(r'^PPid:\s+(\d+)', st, re.M)[1]),
re.search(r'^Name:\s+(.*)', st, re.M)[1].strip(),
int(pss[1]) / 1024 if pss else 0)
kids = collections.defaultdict(list)
for pid, (ppid, _, _) in proc.items():
kids[ppid].append(pid)
def tree(pid):
return proc[pid][2] + sum(tree(k) for k in kids[pid] if k in proc)
for pid, (_, name, _) in sorted(proc.items()):
if name in ('claude', 'codex', 'opencode', 'pi'):
print(f'{name:10} pid {pid:<8} {tree(pid):7.0f} MB')
PYIf your numbers disagree with ours, yours are the ones that matter. Size for them.
Questions
How much RAM does a Claude Code session use?
It depends entirely on what it is doing, which is why one number is misleading. On a clean 8 GB machine, an open session waiting at its prompt cost 167 MB once the first session had paid for the shared runtime. On a developer box with 17 sessions doing real work, the median session's whole process tree measured 238 MB and the p90 measured 997 MB. Size for the working number, not the idle one.
How many Claude Code sessions can I run at once?
More than most people expect, if they are idle: 32 sessions on a 4 vCPU / 8 GB Computer used 5.4 GB in total, with 2.2 GB still free, no swap and no OOM kills. Working sessions are the real constraint. At the observed p90 the same box holds about 6. Memory is also only the first limit; CPU and disk contention arrive next.
Why does my machine crash when I run several agents?
Because each session is a process tree, not a process. The CLI, its MCP servers, the language servers and anything it spawns are all charged to the same box, and a session running a build can be several times the size of one reading a file. When the total passes your RAM, Linux does not degrade gracefully. The OOM killer takes the largest process, which is almost always an agent mid-run.
Is it cheaper to self-host coding agents on a VPS?
In pure machine cost, yes, and by a lot. The same 4 vCPU / 8 GB shape ranges from about $8.50 to $48 a month depending on the provider, and the agent software is free and open source either way. What you buy with a managed Computer is not the machine, it is not having to keep it alive. Start with the free path and pay someone else only when the box becomes a chore.
Can I reproduce these numbers?
Yes, and you should. Both scripts are on this page: a one-paste snippet that measures the agent sessions already running on your machine, and the ramp harness that adds sessions to a fresh box until it runs out. If your numbers disagree with ours, yours are the ones that matter.