Try Hanzo

Benchmarks / Sandbox cold start

measured

Cold start, by primitive

A V8 context in 0.13 ms, an isolate measured at 0.35 ms rather than cited, and a hanzo-vm microVM in 309 ms — and the reason the fastest row is not the answer: an isolate runs JavaScript and cannot run pytest, pip, cargo or a shell.

harness
hanzoai/cloud · bench/sandbox
node sandbox/sandbox.mjs

prints the table on this page — transcribed from bench/README.md, the pass of 2026-09-07

What is measured

The time from asking for a sandbox to having one that will execute code. Three primitives answer that request in three different ways, and they are not interchangeable: a V8 context is a new heap inside a process that is already running, an isolate is a heap of its own, and a microVM is a kernel started from nothing. Timings are the median of the pass.

Results

M-series laptop · the pass of 2026-09-07 · median of the pass

primitivemeasured herepublished elsewherewhat it can run
V8 context0.13 msJavaScript, sharing the heap
V8 isolate, isolated-vm 7.0.12.79 ms, 1.2 MBJavaScript, its own heap
hanzo-vm, cold boot309 msE2B under 200 ms · Modal ~1 s · Cloudflare 1–3 s
hanzo-vm, from a checkpoint311 msMorph under 250 ms resume · E2B ~1 s from pause

The isolate row used to be the context row, and that was wrong in our favour. A vm.createContext makes a fresh global inside an isolate that is already running; it is cheap because it shares that heap, which is the one thing an isolate does not do. Reporting the context against a published isolate figure and calling it seventeenfold compared two different primitives. Installing the library the 2.79 ms is attributed to and running it on this laptop puts an isolate at 0.35 ms, under the figure cited at us by eightfold rather than seventeen, and a measurement rather than an argument. It read 0.59 ms here once; five consecutive runs give 0.35 ms, because the first run of a session reads high. The megabyte is V8's too: a fresh isolate's heap measures 1.00 MiB here, close to the 1.2 MB cited, because that is what any isolate costs including one of ours.

The row that matters for an agent that needs a shell used to be a container started by Docker, and nothing here runs Docker: the builds run buildkit inside a microVM. Measured on the runtime we ship, a hanzo-vm boots in 309 ms, which is slower than the under-200 ms E2B publish for Firecracker. Their figure was taken by other people on other hardware under a protocol we did not run, so it is their claim quoted rather than a matched measurement, which is the reason neither number settles it and not a defence of ours. Starting from a checkpoint costs 311 ms, the same: a checkpoint carries the disk an earlier run left, and the kernel boots either way.

Why the fastest row is not the answer

An isolate runs JavaScript. It cannot run pytest, pip, cargo or a shell, which is most of what a coding agent is actually asked to do. Putting 0.13 ms and 309 ms in one column invites the reading that the first is the same service two thousand times faster, and it is not the same service. The comparison is per workload: for a JavaScript transform the isolate is the right primitive and the container is waste, and for anything that installs a package the isolate cannot take the job at any latency.

That is also why the table above carries a column for what each primitive can run. A latency table without it is the kind of chart that wins an argument and loses the deployment.

What this does not measure

Cold start is not throughput. This is the time to the first instruction, on an idle machine, with the image already local. It says nothing about what happens when a thousand sandboxes are asked for at once, and nothing about pulling an image that is not cached — both of which dominate in production and neither of which is on this page.

One machine, one day. A single pass on one laptop, reproducible by one command. Read it as a floor that has been established rather than as a service level, and note that the published figures in the right-hand column were taken by other people on other hardware under protocols we did not run — they are the vendors’ own claims, quoted, not a matched measurement.

It is one of three costs, not the cost. A sandbox is what an agent needs to run a command. What it costs to keep an agent that is doing nothing is 477 bytes and a 0.034 ms resume, and what a running agent holds is 601 bytes of heap and 125 ns to spawn. The three are separate measurements with separate commands and they do not add up into a single number.

harness and the committed table: hanzoai/cloud · bench/sandbox · sandbox.mjs needs a container runtime; colima start is enough on macOS