# 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](/docs/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](/docs/choosing-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

```ts check
import { 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"
```

```python check
from withruntime import Runtime

runtime = 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](/glossary/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](/docs/fly-alternative)
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?](/glossary/cpu-floor)
- [The sandbox environment: disk, CPU and memory](/docs/sandbox-environment#disk-cpu-and-memory)
- [Fly Machines vs Fly Sprites](/compare/fly-machines-vs-fly-sprites)
- [Sandbox cost calculator](/calculators/sandbox-cost-calculator)

Facts on this page were checked on 25 September 2026.