Sandbox Startup Latency

"Started ≠ ready." The metric everyone benchmarks — container scheduling + boot — is usually the smallest part of what a user actually waits through. The real cost is everything that happens after the container boots but before the sandbox can do useful work: git clone, npm install, a server coming up. Optimizing the wrong number (shaving ms off boot) does nothing for a 30-second setup. Source: Modal, https://modal.com/blog/unpacking-sandbox-startup-latency, 2026-06-22

The full startup lifecycle (5 events)

Modal models a sandbox's startup as five distinct events, not one "running" flip:

1. Created — requested, no compute allocated yet. Sandbox.create is async and returns immediately; latency negligible.
2. Scheduled — assigned to a worker provisioning CPU/mem/GPU/volumes. Latency = how fast the provider finds capacity.
3. Started — container live, entrypoint running, tunnels + volume mounts active; you can exec(). This is what benchmarks measure (e.g. ComputeSDK's "time to interactive": create() → first successful command).
4. Ready — application-level init finished and the sandbox can actually do the work the user wanted. Use-case specific, often multiple seconds.
5. In use — handling real work.

The Started → Ready gap is excluded from almost every benchmark, yet it dominates real workloads. It's also your code's responsibility once the container is running. Source: Modal, 2026-06-22

Why the gap is the cost (it's universal)

In every case the expensive part is application setup, not container scheduling — and it's invisible to a benchmark that stops at the first exec.

What actually matters: perceived latency

The only metric users feel is perceived latency — time from "give me a sandbox" to "I can use it." A 30s setup is a 30s wait; trimming container boot doesn't move it. The goal for production is to take that setup off the user's critical path entirely.

Three mitigation techniques

1. Warm Sandbox pools. Pre-initialize sandboxes in the background before anyone asks. Hand out an already-ready one on request; perceived latency drops to "pop from pool." On Modal, a modal.Queue holds pre-warmed sandboxes — a producer creates + sets up + pushes; the app pops one and immediately spawns a replacement to keep the pool full. Warm pools are often dismissed as a workaround, but latency-sensitive apps almost always need one because you cannot make a git pull or dependency install disappear — you can only pay it ahead of time.
2. Directory Snapshots (solves the warm-pool generality problem). A warm pool is generic by design — you build sandboxes before knowing which user/project will claim each one, so you can't pre-bake project-specific code. Directory Snapshots keep a pool of identical running sandboxes and mount a project's specific state in at claim time. Mounts are instant, so you get warm-pool latency and per-user customization. (This is the application-layer cousin of VMM memory snapshots — see MicroVM and Sandbox Isolation Architecture.)
3. Readiness Probes (GA on Modal, 2026-06-22). Define a probe — a shell command that should exit 0, or a TCP port that should accept connections — and the platform polls it; sandbox.wait_until_ready() blocks until it passes. Replaces fragile fixed sleeps and bespoke health-check loops, and gives a clean sequencing primitive even for on-demand (not just pooled) sandboxes. A ready event then joins scheduled/started/terminated on the dashboard timeline so you can quantify your own Started→Ready cost.

Why this matters to Kevin / Dedalus

This is the operational core of the Persistent Sandbox Thesis: if cold-start (re-cloning, re-installing) is unavoidable per-request, the way to win is to not start cold — keep environments warm/persistent and snapshot their state. Modal's warm-pool + Directory-Snapshot + readiness-probe stack is the productized version of that thesis and sets the table stakes for any agent-sandbox provider (Dedalus Machines - Positioning & Pitch, E2B Code Sandboxes): the differentiator is no longer raw boot time (Firecracker already made that milliseconds) but time-to-ready and the primitives that hide it. It also reframes the "fast sandbox" marketing race — started is a vanity metric; ready is the product.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: "Started ≠ ready." The metric everyone benchmarks — container scheduling + boot — is usually the smallest part of what a user actuall... Source: User request, 2026-07-01
• 2026-06-22 | Captured from Modal's "Unpacking sandbox startup latency" (Rebecka Storm) + the @modal announcement. The 5-event lifecycle (Created/Scheduled/Started/Ready/In use), the started≠ready thesis, and the three mitigations (warm pools, Directory Snapshots, Readiness Probes GA). Wired to the persistent-sandbox / microVM cluster. Source: Modal blog + X/@modal, 2026-06-22