# What is a cold start?

A cold start is the wait between asking for a new sandbox, VM or function and the moment it can run your first command.

**A new Runtime sandbox ran its first Python command 351 ms after the create
request at the median**, with a p95 of 815 ms across 20 sequential starts,
measured from a laptop through the public API on 24 September 2026
([speed](/docs/speed)). That figure includes the network, so it is the wait
your own code sees.

## Why it matters for AI agents

An agent that runs each task in a fresh machine pays the cold start every time.
A chat assistant that starts a sandbox when a user asks a question adds the
cold start to the answer. When starting is slow, teams keep machines warm and
pay for them while they wait, or reuse one machine across users and give up
isolation. A fast cold start removes that trade: a new, clean machine per task
costs a fraction of a second.

## Cold, warm and resumed

| Kind of start        | What happens                                         | On Runtime                                                           |
| -------------------- | ---------------------------------------------------- | -------------------------------------------------------------------- |
| Cold                 | A new machine boots from an image                    | 351 ms median to first Python result, p95 815 ms (24 September 2026) |
| Create until running | The machine is up, before any command                | 207 ms median, p95 620 ms (24 September 2026)                        |
| Warm                 | A command in a machine already running               | 105 ms median (24 September 2026, earlier 100-run benchmark)         |
| Resumed              | A paused machine wakes with its memory and processes | Usually about half a second when a request wakes it                  |
| From a snapshot      | A new machine starts from a saved machine            | Starts as a copy of the saved machine                                |

The Runtime runs used the free trial's default sandbox: 2 vCPU, 4 GiB of memory,
4 GiB of disk and shared CPU, one at a time, with `python3 -c pass` as the first
command. They are observations of that shape and workload, not a latency
promise.

Firecracker, the virtual machine monitor under every Runtime sandbox, states
that a microVM can "boot in <125ms" on its own site. That is the project's
claim for the VM alone; the figures above are end to end over the internet.

## Measure it yourself

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

const started = performance.now();
await using sbx = await Sandbox.create();
await sbx.exec(["python3", "-c", "pass"]);
console.log(`${Math.round(performance.now() - started)} ms to first result`);
```

The client's first call opens a connection to the API, which a fresh process
pays once (about 140 ms in the September benchmark). The full script in
[speed](/docs/speed#run-the-latest-measurement-yourself) warms the connection
first, runs 20 starts and reports the median and p95.

## How to avoid paying it at all

- **Pause instead of stopping.** A paused sandbox keeps its files, memory and
  running processes for 1 to 365 days and costs no compute while it waits
  ([pause and resume](/how-to/pause-and-resume-a-sandbox)).
- **Bake dependencies into an image.** A [custom image](/docs/images) starts
  with everything installed, so no task spends its first minute in `pip`.
- **Fork a prepared machine.** A [fork](/glossary/sandbox-fork) copies a running
  sandbox with its memory, so every copy starts where the original was.

## Related

- [What is a sandbox snapshot?](/glossary/sandbox-snapshot)
- [What is a microVM?](/glossary/microvm)
- [What is Firecracker?](/glossary/firecracker)
- [Runtime speed measurements](/docs/speed)

## Sources

- [Firecracker](https://firecracker-microvm.github.io/), checked 25 September 2026

Facts on this page were checked on 25 September 2026.