Capacity,
measured
A guide to what a sandboxed agent run costs and how to size a host for the fleet you want. Every run gets its own gVisor sandbox, network namespace, and private subnet — the isolation machinery adds about 25 MB and a quarter of a second per run, and one host scales to 256 concurrent runs without latency bending.
The sandbox is 10% of the footprint.
A run's memory footprint is dominated by the model runtime, its context, and its tools. The sandbox wrapped around it (a gVisor kernel, a dedicated network namespace, per-run firewall rules) adds about 25 MB.
Marginal, not naive: the engine's read-only code pages are shared across every sandbox on a host, so each additional run costs only its private memory — measured at fleet scale, not extrapolated from one process.
Linear latency scaling.
The isolation primitives are constant-time: spawning the 250th sandbox costs the same as spawning the 8th, and starting one more run while the host is loaded stays in the same third of a second.
| Live sandboxes | Sandbox spawn | One more full run |
|---|---|---|
| 8 | 220 ms | 340 ms |
| 16 | 270 ms | 340 ms |
| 32 | 240 ms | 340 ms |
| 64 | 190 ms | 320 ms |
| 96 | 195 ms | 315 ms |
| 128 | 200 ms | 330 ms |
| 192 | 205 ms | 335 ms |
| 256 | 215 ms | at capacity |
“One more full run” is the whole lifecycle — allocate a subnet, create the namespace, install firewall rules, boot the sandbox, execute, tear everything down — started while every other sandbox on the host stays live. At 256 the line ends because a 257th subnet can’t exist.
Capacity is a straight line.
Memory is the budget; everything else has slack. Each concurrent run costs a flat ~0.25 GB all-in, and the relationship stays linear all the way to the ceiling — no cliff, no per-run tax that compounds. Size a host by working backwards from the fleet you want.
| Host memory | Concurrent runs |
|---|---|
| 16 GB | about 16 |
| 32 GB | about 80 |
| 48 GB | about 144 |
| 64 GB | about 200 |
| 96 GB | 256 (per-host ceiling) |
Reserve ~12 GB for the host — the platform itself plus safety headroom the scheduler never touches — then budget a quarter-gigabyte per concurrent run, up to the 256-run ceiling.
Agents are I/O-bound — a typical run averages ~5% of one core while it reasons, edits, and waits on builds. CPU pressure only appears under sustained all-core synthetic load, and even at 2× oversubscription runs complete without failures. Memory runs out first.
256 by construction.
The 256-run limit isn't a tunable someone forgot to raise — it falls out of the isolation design. Every run owns a private /24 subnet carved from one reserved /16, so exactly 256 can exist on a host at once. The same structure that makes cross-run snooping impossible at the link layer sets the ceiling.
Runs never share a network segment, so there is no bridge to police and no policy to misconfigure — and no 257th slot to hand out. Need more than 256 concurrent agents? Add a host; capacity scales horizontally.
Inside the sandbox →Figures are medians measured on commodity x86 server hardware with a warm sandbox image cache — synthetic workloads for the latency curves, and fleets of the real agent engine driving multi-turn tool-use conversations for the per-run memory numbers. Real runs vary with task size, model, and repository; treat the sizing rule as planning guidance and validate against your own workloads before committing hardware.