Skip to content
SemSwitch
Contact

Anatomy of a True Cold Start

Hassan Ali·8 min read·Aug 24, 2026

How the fastest sandboxes in the industry actually start — and a documented 96 ms true-cold result for a 2-vCPU, 16-GiB Firecracker microVM.

Why cold starts got expensive again

For most of the serverless era, cold-start latency was a background annoyance: a few hundred milliseconds on the first request, amortized away by traffic. AI agents broke that arithmetic. An agent doesn't invoke one function and return — it plans, writes code, executes it, inspects the result, and iterates, often dozens of times per task. Because the code it runs is synthetically generated and inherently untrusted, execution belongs in a hardware-isolated environment, not a shared-kernel container. When an agent provisions a fresh sandbox for an execution or evaluation step, that startup cost lands directly on the interaction's critical path.

That demand profile — thousands of short-lived, hardware-isolated environments, provisioned on the critical path of an interactive session — has made microVM cold-start latency one of the most competitive numbers in infrastructure. It has also made it one of the most creatively measured.

What a true cold start actually is

A microVM cold start is a pipeline, and where you place the timer's two ends changes the number by an order of magnitude:

  1. A create request arrives and is scheduled.
  2. The host spawns a new VMM process — for Firecracker, this includes the jailer applying seccomp filters and dropping privileges.
  3. A new KVM virtual machine is created; memory and vCPUs are allocated.
  4. The guest Linux kernel is loaded and boots.
  5. Guest userspace initializes: init, networking, the in-guest agent.
  6. The workspace reaches a state where it can actually accept work.

A true cold start runs this entire pipeline, from nothing. The contract is strict: no snapshots, no snapshot restores, no warm pools, no prebooted guests, no prestarted VMMs, no reused KVM VMs. Every start is a new process, a new VM, a new kernel boot.

Very few published numbers measure this. Most measure something else.

The escape hatches everyone uses

The standard way to make a microVM "start" fast is to not start it — restore it.

Snapshot resume. E2B's own architecture documentation is admirably direct about this: sandboxes "resume pre-booted snapshots instead of cold-booting." A template is a pre-booted VM image — memory, disk, and machine state — and creating a sandbox means restoring it, with memory pages faulted in lazily as the guest touches them. Their template docs cite roughly 80 ms for that restore. It's clever engineering, and it's a legitimate trade-off — but the guest kernel booted once, at template build time. Everything after is restoration.

Suspend/resume. Fly.io's documentation draws the same distinction cleanly: resuming a suspended machine from a Firecracker snapshot takes "a few hundred ms," while a cold start is "~2+ seconds for common apps." Notably, Fly discourages suspend for machines above 2 GB of memory, because snapshot restore time grows with the memory footprint. The escape hatch stops scaling exactly where memory-hungry workloads begin.

Warm pools and preboot. The remaining approach is to keep booted VMs idle and hand them out on request. It works, and it's economically painful: idle RAM is billed to someone, and the pool must be sized for peak demand.

None of this is deceptive engineering — snapshots and pools are rational answers to a hard problem. The trouble is only in the accounting, when a resume time is quoted where a cold-start time is implied. The two are different operations with different failure modes: restored state can be stale, lazily-faulted memory pushes latency into the tail, and snapshot storage is a standing cost.

What true cold actually costs today

Here is the public record for sandbox creation across the major platforms, using each vendor's own documentation where available and LogRocket's independent 2026 benchmark for measured figures. Note what each number actually is:

PlatformIsolationPublic create/start latencyDocumented optimized path
E2BFirecracker microVM717 ms measured public create (LogRocket) — snapshot-backed per E2B's own architecture~80 ms snapshot restore (vendor docs)
ModalgVisor2,437 ms measured sandbox create (LogRocket)2,347 ms snapshot boot (measured, LogRocket)
Fly MachinesFirecracker microVM~2+ s actual cold start (vendor docs)"a few hundred ms" resume; suspend ≤ 2 GB (vendor docs)
Vercel SandboxFirecracker microVM1,852 ms measured public sandbox create (LogRocket)3,333 ms resume (measured, LogRocket)
BlaxelFirecracker microVM200–600 ms vendor-reported creation from template; 2,824 ms measured public create (LogRocket)< 25 ms standby resume (vendor-reported)

Two reference points bracket the table. At the floor, Firecracker's official specification publishes a 125-ms kernel-start reference: the time from the InstanceStart API call to the start of /sbin/init, measured on a minimal guest with 1 vCPU and 128 MiB of RAM, ending before networking, agents, or workspace readiness exist. That is a kernel-start metric, not a usable-environment metric.

At the other end of the spectrum, faster startup classes exist by giving up the kernel: container platforms such as Daytona report sub-100-ms-class startup using namespace isolation (a shared host kernel — a different security boundary), and V8 isolates start in single-digit milliseconds without any operating system at all. Those are different compute classes, not faster microVMs.

The fastest independently measured public sandbox creation in LogRocket's test was E2B at 717 ms — 7.4× Setsuna's 96-ms p50 — but E2B's own architecture says normal sandbox creation resumes a pre-booted VM snapshot, so even that is not a comparable true-cold microVM boot. The fastest vendor-reported creation figure is Blaxel's 200–600 ms — creation from a template. Several of the industry's "create" numbers, in other words, aren't true-cold kernel boots at all.

The Setsuna result

Setsuna is SemSwitch's Firecracker-based microVM runtime. In a 1,000-run benchmark executed on Azure (Standard_E8ads_v7, AMD EPYC 9V45), Firecracker 1.16.1, with a guest configuration of 2 vCPUs and 16,384 MiB of final memory, Setsuna recorded the following request-to-strict-ready latencies across 1,000 sequential true-cold boots — 1,000 successful, 1,000 cleaned up, 1,000 unique:

minp50meanp90p95p99max
83 ms96 ms96.32 ms103 ms104 ms107 ms113 ms

Every sample in that distribution is a full cold start under the strict contract: a new jailer and Firecracker process, a new KVM VM, a new guest kernel boot with a unique boot ID, and a new per-launch workspace and rootfs instance. No snapshots, no restores, no warm pools, no prebooted guests, no prestarted VMMs, no reused VMs.

Two comparisons put the number in context.

Against the industry: the fastest independently measured public sandbox creation in the record — E2B's 717 ms, which per E2B's own architecture resumes a pre-booted snapshot rather than cold-booting — is 7.4× slower than Setsuna's true-cold p50. The rest of the measured field sits at 1.8 to 2.8 seconds.

Against Firecracker's published 125-ms kernel-start reference: that figure is measured on a 128 MiB guest and ends at /sbin/init. Setsuna's 113-ms maximum across 1,000 launches still finished below that reference — while measuring a substantially wider lifecycle span (request through verified workspace readiness) and using 128× the final configured memory.

How the boot path achieves this is not something we're detailing here. What we can detail completely is how it was measured.

Methodology: what "strict-ready" means

The benchmark measures host-local wall-clock time from the start of the sandbox create request until strict-ready. Strict-ready is not "the API returned" or "the kernel started." It requires, for every sample:

  • the guest agent is responsive;
  • guest networking is ready;
  • the final guest memory total is sane;
  • the guest reports the full configured memory capacity available and usable;
  • independent host and guest observations agree that the configured memory requirement has been satisfied; and
  • the sandbox is persisted in RUNNING state.

For every boot, the harness independently verifies the configured memory capacity from both the VMM and guest perspectives — measured per launch, not assumed.

After strict-ready, the harness runs a deterministic guest workload: it writes a fixed payload, reads it back, verifies its SHA-256, deletes it, confirms the deletion, and returns BENCH_OK. That workload validates that the workspace is genuinely usable; it is not included in the request→strict-ready number. The sandbox is then destroyed and cleanup is verified. Failed samples are not replaced — the 1,000 runs reported are 1,000 consecutive successes.

The proof bundle — README.md, result.json, the full 1,000-row samples.csv, and SHA256SUMS — is published alongside the interactive results, with the runtime identity and source-evidence manifest pinned by SHA-256.

What the 96 ms measures

Precision about what 96 ms is:

  • It is host-local request→strict-ready — the sandbox stack's own latency. It is not public-Internet API round-trip time, and it does not include Azure's provisioning of the host itself.
  • It was measured on one cloud, one instance SKU, one guest configuration, sequentially. Concurrency behavior and other configurations are separate questions with separate benchmarks.
  • Timer boundaries differ across providers. Setsuna's readiness boundary is substantially deeper than kernel-start references such as Firecracker's specification, while managed-service measurements may include public network and control-plane latency that Setsuna's host-local benchmark intentionally excludes. Those market figures provide context; the Setsuna dataset is the directly auditable result.

That is the measurement contract behind the 96-ms result.

Conclusion

A 2-vCPU, 16-GiB Firecracker microVM, booted from nothing to a verified, strictly ready workspace, in a median of 96 ms across 1,000 consecutive successful runs — with a worst case of 113 ms.

Based on the public record we reviewed — vendor documentation, independent benchmarks, and Firecracker's own specification — we found no published comparable true-cold microVM result faster than Setsuna's 96-ms p50. The fastest independently measured public sandbox creation in the record is 7.4× slower — and per the vendor's own architecture, even that number is a snapshot resume, not a cold boot.

If a faster documented result exists — same contract: true cold, no snapshots, no warm pool, no preboot, request to verified readiness — we want to see it.

The full dataset, checksums, and interactive charts are at semswitch.com/setsuna.

Sources

<- Back to the SemSwitch Blog