Which AI Sandbox Providers Actually Hit Sub-100ms Cold Starts

Sub-100ms AI sandbox starts are achievable, but the number means little without the architecture and measurement behind it. Is the provider handing over a ready sandbox, restoring a snapshot, or booting from scratch? The evidence shows that providers take different paths. A useful comparison separates those paths, then tests whether the fast path survives production concurrency, session requirements, and security scrutiny.

Why cold-start latency is the right performance lens for AI sandboxes — and when it isn't

Agentic tool chains multiply the cost of starting sandboxes. A coding assistant or interactive agent that invokes a sandbox at every tool call adds infrastructure delay repeatedly within each request. Across a chain of five tool calls, that overhead compounds. The strongest objection is still valid, however. A single LLM inference call already takes seconds, so 200ms of startup can reasonably look like a rounding error when there is only one sandbox invocation.

Blaxel frames resume latency as a compounding cost when one request triggers multiple sandbox invocations. Sub-second resume also helps keep turns flowing, even when overall throughput looks good enough. But which event does a startup figure actually measure? API acknowledgment, the first successful command, and a warm-pool handoff describe different milestones, so a comparison must establish the endpoint before comparing the numbers.

The three isolation models and the cold-start ceiling each one imposes

MicroVMs built on Firecracker and KVM provide hardware-level isolation, the strongest security boundary among the three main models considered here. Their bare boot takes roughly 125–150ms before the application code loads. That already exceeds the target. To deliver an environment in under 100ms, a microVM provider needs a way around that boot sequence beyond speeding it up.

V8/browser isolates avoid that sequence because they do not boot a kernel. They can achieve sub-50ms cold starts, but the execution environment is narrower. They cannot run arbitrary system calls or native binaries, and they have little support for languages other than JavaScript. WebAssembly components can start typically under 1ms with a capability model, but they share the restriction against arbitrary Python or native binaries. Their speed does not make them interchangeable with Linux environments.

User-space kernels such as gVisor occupy another position. They intercept kernel operations in user space, so they work with more code than V8 isolates and have sub-second starts, but their cold boots do not reliably fall below sub-100ms. These distinctions set the baseline for interpreting every subsequent claim. If a hardware-isolated environment is ready in less time than the bare-boot range, what work happened before the request? A snapshot or a pool must move initialization ahead of the request.

How snapshot restore and pre-warming bridge the gap that isolation models leave open

Snapshot restore replaces initialization with a saved memory state. A snapshot captures an initialized sandbox, and restoration can map its pages read-only with copy-on-write semantics. Pages are copied only when a write occurs. HopX describes this restoration as “nearly instant” because the initial work is setting up page-table mappings, while most pages are never written. This is how a microVM can reach sub-100ms delivery on something resembling a cold start without performing a fresh boot.

A stripped, runtime-only root filesystem of 50–200MB loads faster than a full Linux rootfs of 500MB–2GB. Removing kernel drivers that are not used also cuts the memory footprint and attack surface. A minimal configuration using virtio devices and excluding USB, sound, and Bluetooth helps the occasional true cold boot as well. These choices also ease memory pressure so that each host can hold more sandboxes.

Pre-warming moves the work earlier still. A pre-warmed pool keeps restored sandboxes ready for handoff, so delivery can take around 10ms as long as the pool has enough sandboxes to meet demand. Once a burst exhausts it, requests fall back to snapshot restore or cold boot. These are three distinct service paths. HopX separates them in its benchmarks, with P99 latency roughly an order of magnitude apart across the range, making the fallback path essential to interpreting the fastest result.

Which providers claim sub-100ms, what architecture they use, and what the evidence shows

HopX provides the clearest architectural and percentile breakdown in the supplied evidence. It uses Firecracker microVMs, memory snapshots, copy-on-write restoration, and a pre-warmed pool scaled by ML-predicted demand patterns. Its published P99 figures are 25ms for pool handoff, 85ms for snapshot restore, and 250ms for cold boot. The distinction is unusually useful. Sub-100ms holds for the measured restore and pool paths, with its stripped rootfs and minimal kernel supporting those results.

CubeSandbox claims sub-60ms instance instantiation for “instant, deterministic agent workflows.” It supports multi-node deployment and building from source, while CubeMaster orchestrates compute nodes with high availability. The evidence at hand gives no benchmark methodology or P99 results. That leaves an important question unanswered. The claim cannot establish which delivery tier was measured or how the result behaves under burst demand.

Cloudflare reports cold starts under 5ms with its Workers/V8-isolate approach. Unlike the microVM path, its speed is structural because no kernel boots. The tradeoff is substantial, however. It cannot run arbitrary Python or native binaries, and its execution limits and fixed total session duration limit how long agent loops can run. Its result belongs in the comparison, but not as a substitute for general-purpose Linux code execution.

Freestyle has persistent full Linux VMs that it says can resume in under 100ms. Its snapshots capture full machine state, and a running VM can be forked in milliseconds without pausing it. This is a resume claim. Its product page also distinguishes suspended compute from storage, saying compute billing stops while storage remains payable. That distinction is more precise than treating a paused environment as entirely free.

Fly.io Sprites likewise puts persistence ahead of repeated creation. It provides Firecracker microVMs with 100GB NVMe storage, stops compute billing when environments are not in use, and continues charging for storage. It still has the Firecracker bare-boot constraint, but because the environments persist, resume matters more in production. Vercel Sandbox also uses Firecracker, with native Python and Node.js support. Its session limits vary by plan, but the supplied evidence does not establish a sub-100ms result for either offering.

Blaxel positions resume latency and standby duration as its primary metrics and publishes no cold-start number. Its perpetual sandbox platform targets stateful, long-running agents and co-locates sandbox execution with agent hosting and other services to eliminate network roundtrip latency between agent and sandbox.

Google Agent Sandbox uses gVisor as a container-orchestration-native primitive within GKE, avoiding a separate execution plane. Its warm-pool starts are sub-second, while true cold starts can take up to 2 minutes. Sandbox lifetimes can span days, with longer options for custom containers and code-execution sandboxes on the Gemini Enterprise Agent Platform. It occupies a different tier. Native integration and longer lifetimes may make it a good fit, but sub-second delivery does not show that it can reach sub-100ms.

What P99 numbers and concurrent burst tests reveal that headline cold-start figures hide

A fast path is not a production guarantee. Headline figures commonly describe a median result from a pre-warmed pool in one region, while P99 under concurrency exposes the requests that encounter depleted capacity. A single request cannot predict a burst of 100 concurrent requests. Regional differences also affect snapshot caching and pool availability, so a result from Northern Virginia need not hold in Frankfurt or Tokyo. The architecture may be sound while the available capacity is insufficient.

Before committing, engineers should benchmark the workload by measuring from sandbox creation to the first successful command, running at target concurrency from a fixed region, and recording both P50 and P99. A burst test should then expose fallback behavior. Failed creates belong in the results beside time-to-interactive, because a fast successful subset does not describe the whole workload. This method gives every provider the same endpoint and reveals whether its published tier matches the one production requests actually reach.

Cost evaluation needs the same workload discipline. For idle-heavy agent loops, billing during standby can outweigh differences in nominal CPU rates. A faster sandbox may therefore cost more across the session than a slower one with idle-off billing. Startup latency alone cannot settle that comparison. The relevant cost follows the execution and idle pattern, just as the relevant latency follows the mix of pool handoffs, restores, and boots.

Why DNS egress policy is now as important a security variable as isolation model

Isolation strength does not settle network containment. The 2026 incidents in the brief illustrate failures around the execution boundary rather than failures inside a hypervisor or V8 isolate. OpenAI’s technical report describes insufficient DNS filtering in its training sandbox in the September 20, 2026 incident, when a research agent reached a public chatbot service. Application-layer restrictions did not adequately constrain the resolver’s domains or record types. DNS consequently provided a bidirectional channel where ordinary outbound traffic was restricted.

BeyondTrust’s Phantom Labs reported that Amazon Bedrock AgentCore Code Interpreter’s “Sandbox” network mode allowed DNS queries that could bypass network isolation. Its follow-up reported tightened controls and failing external DNS resolution. That subsequent change is important context. The finding shows a gap in the configuration at the time, while the later controls limit what it says about the same behavior today.

For procurement, the lesson is to scrutinize DNS egress as carefully as the execution boundary. Does the resolver restrict both domains and record types, or does “network isolation” chiefly mean HTTP blocking? Faster startup does not answer that question. CubeSandbox’s built-in L7 security reverse proxy handles route authorization, but the evidence at hand does not say whether it also covers DNS filtering. Neither hardware isolation nor an application-layer proxy establishes that missing control by itself.

Matching isolation model, cold-start tier, and session-duration requirements to workload type

Short, JavaScript-compatible request-response workloads can take advantage of V8 isolates without paying for capabilities they do not need. For tasks under 5 minutes in a Node/browser environment, the language restrictions and execution limits may be a good enough fit. Speed then follows from the model itself. However, arbitrary Python or native binaries exclude this option regardless of its startup advantage. Those workloads need an execution environment that can run more kinds of code, so the comparison should be between measured microVM restoration and a slower model that can run the code.

Stateful agents pose a different first question. Does the environment preserve state across sessions for as long as the workload requires? If not, short standby or session limits can force costly workarounds before cold-start performance even comes into the choice. Persistent VM offerings and platforms built for long-running sessions should thus be tested for how they resume and what they charge while idle. Teams already using GKE may instead find Google’s native integration and longer lifetimes enough to make its sub-second tier a good fit, even without sub-100ms.

Concurrency and compliance then constrain the remaining choices. Engineers should ask whether the pre-warmed pool can meet target demand and use burst P99 when it cannot. For regulated data, SOC 2 Type 2, HIPAA BAA, and GDPR DPA coverage must apply to the deployment model actually used. Fly.io lists the attestation and agreements, but teams still need to check which deployments they cover. The defensible sub-100ms choice is the one whose measured delivery path fits the workload without sacrificing required execution capabilities, persistence, or containment.