# What is a warm pool?

A warm pool is a set of machines started ahead of demand. A request takes a
machine that is already running, instead of waiting for a boot.

**Runtime keeps its own warm pool of the most common sandbox shapes. Most
agents can skip building a pool and paying for its idle time.** A create of
such a shape is given a machine Runtime started ahead of time, which costs you
nothing until the create.

## Why teams build warm pools

A pool exists to hide a slow boot. If a new VM or container takes several
seconds to start, a chat user who asks the agent to run code waits those seconds
before anything happens. Keeping ten machines booted and idle turns that wait
into a lookup.

The cost is paying for machines that nobody uses. It is also the work of sizing
the pool, refilling it, and cleaning out a machine before the next tenant. A
pool that is too small still leaves some requests on a cold start. A pool that
is too large is idle spend.

## What a pool costs, and the alternatives

| Approach                       | What the next request waits for                                           | What idle time costs on Runtime                                |
| ------------------------------ | ------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Fresh create per task          | A new sandbox; Runtime starts machines of the common shapes ahead of time | Nothing; there is no idle machine                              |
| Pool of running sandboxes      | Nothing beyond the command itself                                         | $0.03125 an hour each at 2 vCPU, 4 GiB                    |
| Pool of paused sandboxes       | A wake                                                                    | $0.08 per GB of saved state per 30-day month |
| Fork of one prepared sandbox   | A copy with the base's memory, 1 to 100                       | Only the base, if you keep it                                  |
| Custom image with dependencies | A create, with no install step                                            | Stored image, charged on its size                              |

Ten 2 vCPU, 4 GiB sandboxes kept running and idle cost $0.3125 an
hour. Over 30 days, they cost $225. These are Runtime's
rates: $0.025 per active vCPU-hour with a floor of a twentieth of a vCPU, and
$0.0075 per reserved GiB-hour ([pricing](/docs/pricing)). The same ten
sandboxes, paused, cost only their saved state
([paused storage](/docs/pricing#paused-storage)).

## A pool without the idle bill

When the expensive part is setup rather than boot, such as a long `pip
install` or a loaded model, prepare one sandbox and fork it. Each copy starts with the
base's files, memory and running processes.

```ts check
import { Sandbox } from "withruntime";

await using base = await Sandbox.create();
await base.exec("pip install --quiet requests");
const workers = await base.fork({ count: 3 }); // three ready copies, running
await Promise.all(workers.map((w) => w.stop()));
```

```python check
from withruntime import Sandbox

with Sandbox.create() as base:
    base.exec("pip install --quiet requests")
    workers = base.fork(count=3)
    for worker in workers:
        worker.stop()
```

For a machine that each user returns to, `getOrCreate` by name with
`idlePauseSeconds` works like a pool of one per user. It pauses when idle and
wakes on the next request ([pause when idle](/docs/javascript#pause-when-idle)).

## Related

- [What is a cold start?](/glossary/cold-start)
- [Sandbox cold start benchmarks: what they leave out](/blog/compare-sandbox-cold-start-benchmarks)
- [What is a sandbox fork?](/glossary/sandbox-fork)
- [What is idle pause?](/glossary/idle-pause)
- [Custom images](/docs/images)

Facts on this page were checked on 25 October 2026.