Runtime

What is a warm pool?

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

A new Runtime sandbox answers its first Python command 351 ms after the create request at the median, so most agents can skip the pool and its idle bill. That figure is end to end through the public API, p95 815 ms over 20 starts, measured on 24 September 2026 (speed).

Why teams build warm pools

A pool exists to hide a slow boot. If a new VM or container takes several seconds to come up, 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 price is paying for machines nobody is using, and 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; one 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: 351 ms median to Python 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, usually about half a second $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 10 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, $225 over 30 days, at Runtime's rates of $0.025 per active vCPU-hour with a floor of a twentieth of a vCPU and $0.0075 per reserved GiB-hour (pricing). The same ten paused cost only their saved state (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.

TypeScriptimport { 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, runningawait Promise.all(workers.map((w) => w.stop()));
Pythonfrom withruntime import Sandboxwith Sandbox.create() as base:    base.exec("pip install --quiet requests")    workers = base.fork(count=3)    for worker in workers:        worker.stop()

For a machine each user comes back to, getOrCreate by name with idlePauseSeconds behaves like a pool of one per user: it pauses when idle and wakes on the next request (pause when idle).

Facts on this page were checked on 25 September 2026.