A sandbox cold start is the wall-clock time between an API call requesting isolated compute and that compute being ready to execute code. For AI agent platforms, the target is under 300ms P99 from request to a running VM — the latency floor for the computers for AI agents that agents run on. Traditional cloud VMs boot in 30–60 seconds; unoptimized microVM stacks land at 2–5 seconds. Hitting sub-300ms means attacking three layers: how the VM's memory and disk state is reconstituted (snapshot/restore), how many machines are pre-warmed (pool management), and how many bytes the guest must touch before it runs (image optimization). This guide walks the kernel-level mechanics and gives you a latency budget you can hold your platform to.
Why Cold Starts Kill Agent UX
An agent turn is interactive. A sandbox must materialize before a single line of tool-call code executes. If provisioning costs 2–5 seconds, it stacks on top of model inference latency and the perceived response time balloons past the threshold where the interaction feels live. Agents also fan out: one reasoning loop may spawn several sandboxes for parallel tool calls, so the slowest one gates the whole turn.
This is why P99 matters more than P50 for agent workloads. If your median cold start is 200ms but P99 is 4 seconds, one in a hundred launches stalls the agent — and because agents launch sandboxes constantly, a user hits that tail within minutes. For sandboxes that cater to AI agents, the engineering target throughout is: request-to-running under 300ms at P99, with headroom at P50.
The Cold Start Stack: Where Time Goes
Cold start is not one operation. It is a pipeline, and each stage contributes measurable latency. Instrument each independently — an aggregate "cold start" metric hides which layer is your bottleneck.
Technique: Memory Snapshots and Restore
The single largest win is to stop booting and start restoring. You boot one VM to a known-good warm state — kernel up, init complete, runtime imported, server listening — then serialize its full memory and device state to a snapshot file. Every subsequent launch maps that file instead of re-executing boot and warm-up.
How restore beats boot
The mechanism is demand paging over a copy-on-write mapping. Firecracker's snapshot/restore creates a MAP_PRIVATE mmap of the guest memory file rather than copying the entire image up front. Pages fault in on-demand as the guest touches them, so restore latency is dominated by device reconstruction and the working set actually accessed, not total snapshot size (Firecracker snapshotting docs).
The numbers are decisive. As of July 2026, AWS Lambda SnapStart, built on Firecracker snapshots, reports restore-path latencies in the single-digit milliseconds range versus a full Firecracker cold boot at roughly 110ms P50 / 340ms P99 (AWS Lambda SnapStart docs). Modal's memory snapshots show the application-layer payoff: an import torch workload that cold-starts in ~5s restores in ~1.05s P50 and ~0.69s P0. Snapshot restore runs roughly 2.5x faster than an equivalent cold container start. These are vendor-published figures at a moment in time; re-verify them against the linked sources periodically (roughly every 90 days), since providers tune these paths continuously.
Tradeoffs
- Snapshot freshness. A snapshot freezes state at capture time. RNG seeds, wall-clock, secrets, and open connections are all captured; naively reusing one can leak entropy or replay stale state across tenants. Re-seed RNGs and refresh time on restore.
- Memory cost. Hot snapshots want to be cached in RAM close to the compute — real memory you pay for.
- Snapshot size vs. restore speed. Larger working sets mean more page faults on restore. Trim warm state to what the agent needs.
Technique: Warm Pool Management
Snapshots make individual launches cheap; warm pools make them instant. Keep N pre-booted (or pre-restored) VMs idling, ready to be handed to the next request. A request that hits a warm pool skips provisioning entirely — the cold start is effectively a scheduling decision measured in single-digit milliseconds.
Technique: Image Optimization
Every megabyte the guest must read before it runs is latency. Image optimization attacks the largest layer in the stack directly.
Minimal base images
Strip the rootfs to the runtime and its direct dependencies. A distroless or purpose-built base cuts both the bytes to load and the userspace init work — fewer packages means fewer files to page in and fewer init steps.
Copy-on-write shared base layers
When hundreds of sandboxes share one base image, back them with a single copy-on-write layer. Each VM gets a private writable overlay while the shared read-only base is paged in once and reused, slashing both memory footprint and cold-load cost for every VM after the first.
Measured impact: these techniques together typically move image-dominated cold starts from ~3 seconds to under 500ms, and in a snapshot-plus-CoW stack the image layer drops into the tens of milliseconds.
Where Dedalus fits
Dedalus Labs uses warm pool management, minimal base images (plus some of our own engineering magic) to achieve snapshot-level cold start times for agent computers without the downsides of snapshotting. Dedalus Machines are full Linux VMs that start in 50ms with VM-level isolation — full kernel, memory, and filesystem isolation, safe for untrusted code — versus traditional virtual machines that benchmark at ~30 seconds (dedaluslabs.ai), we achieve a more than 100x improvement, achieved through its custom Cloud Hypervisor-based VMM and custom filesystem, among other optimizations.
The contrast with alternatives is architectural. Traditional cloud VMs boot in 30–60 seconds — disqualifying for interactive agents. Docker containers start fast but share the host kernel, a weaker boundary for untrusted agent-generated code. V8 isolates are faster still but constrain you to one language runtime and a restricted syscall surface. Container-based sandbox platforms like E2B are fast but rest on a different isolation model than a true VM. The VM path gives you both sub-second cold starts and hardware-enforced kernel isolation — the combination agent workloads need.
Frequently Asked Questions
How fast can a VM cold start?
With snapshot/restore over demand paging, VM restore lands in single-digit to low-tens of milliseconds. Dedalus machines provide full Linux VMs start in under 50ms (dedaluslabs.ai).
What causes sandbox cold starts?
Four layers, in decreasing order of typical unoptimized cost: VM image/rootfs loading (1–3s), guest kernel boot (125–500ms), userspace init (200–800ms), and application/runtime warm-up (0.5–5s). Image loading is the largest lever; application warm-up collapses most under snapshotting.
How to reduce AI agent latency?
There are lots of optimizations that you can make to your agents harness to improve speed, but at the end of the day you are reliant on your model provider and compute provider to not bottleneck your performance. Keeping cold start times and tool calls quick is essential to reducing noticeable lag for users. That’s why Dedalus Machines are optimized for 50ms P50 cold start times.