Shared vs reserved CPU: what is the difference?
Shared CPU guarantees a machine a small slice of a core and lets it burst; reserved CPU keeps every one of its vCPUs for it alone.
Runtime's shared CPU bills only what the code measures, so a 2 vCPU, 4 GiB
sandbox costs $0.03125 an hour idle and $0.08 an hour with both cores busy.
When a job needs its cores held for it at all times, cpu: "reserved" gives it
that on the same sandbox (pricing).
Why it matters for AI agents
Most agent sandboxes alternate between long waits and short bursts: the model thinks, then the sandbox installs a package or runs the tests. Shared CPU fits that shape, because the machine pays for the burst and a small floor during the wait. A benchmark run, a build farm or a server with a latency target wants the opposite: the same CPU on every run, whatever the neighbours do. Comparing providers, the difference matters too. A shared CPU ceiling is not a reserved physical core, so a fair benchmark compares like with like (choosing an agent sandbox).
Side by side on Runtime
| Question | cpu: "shared" (default) |
cpu: "reserved" |
|---|---|---|
| What is guaranteed | The floor, cpuFloorMillis, 50 millicores default |
Every vCPU the sandbox asks for |
| How far it can go | Bursts up to vcpu cores |
All vcpu cores, all the time |
| Billing while busy | $0.025 per vCPU-hour of measured CPU | The rate in the sandbox's quote |
| Billing while waiting | Memory plus the floor | Higher: reserved CPU raises the waiting charge |
| Free trial | Yes | Paid sandboxes; a reserved sandbox forks only to paid |
| Forks and snapshot copies | Keep the source's floor | Keep reserved CPU |
| Fits | Agents, chat code runs, CI steps, evals | Benchmarks, steady servers, latency targets |
The exact rate of each sandbox is fixed in its usage-pricing quote when it is
created, and GET /v1/usage shows it. Memory costs $0.0075 per GiB-hour either
way.
Choose one at create
TypeScriptimport { Sandbox } from "withruntime";await using bench = await Sandbox.create({ funding: "paid", vcpu: 4, cpu: "reserved" });const run = await bench.exec("nproc");console.log(bench.info.cpu, run.stdout.trim()); // "reserved" "4"Pythonfrom withruntime import Runtimeruntime = Runtime()with runtime.sandboxes.create(funding="paid", vcpu=4, cpu="reserved") as bench: print(bench.info["cpu"], bench.exec("nproc").stdout.strip())Leave cpu out for shared. A middle path is a shared sandbox with a raised
floor: guaranteed half a core, say, while still billing bursts on measurement
(CPU floor).
How other providers name it
On Fly Machines, performance vCPUs are whole cores kept for the Machine, and a
shared-cpu-2x Machine's vCPUs are guaranteed 6.25% of a core each, with a
small burst allowance, as Runtime's Fly comparison
records from Fly's pricing, checked 23 September 2026. E2B and Daytona bill
every allocated vCPU, whether it is busy or not.
Related
- What is a CPU floor?
- The sandbox environment: disk, CPU and memory
- Fly Machines vs Fly Sprites
- Sandbox cost calculator
Facts on this page were checked on 25 September 2026.