Key takeaways
- Vendor cold starts and measured startup are not the same number. Blaxel quotes 25ms resume; an August 2026 benchmark measured median time to interactive of 0.27s at Daytona and 5.06s at Cloudflare Sandbox.
- Isolation has consolidated on three boundaries: E2B, Vercel Sandbox and Blaxel run Firecracker microVMs, Modal runs gVisor in userspace, and Cloudflare Sandbox runs containers on Workers with a shared kernel.
- GPU narrows the field before latency does. Modal, Daytona and Northflank offer it, with Modal spanning T4 through B300 and Daytona adding AMD MI355X alongside NVIDIA.
- Retention of stopped state spans four orders of magnitude: 10 minutes of idle before Cloudflare Sandbox resets disk to image, 7 days for Modal memory snapshots, 30 days for Vercel and Modal filesystem snapshots, indefinite at E2B and Blaxel.
- Startup only matters if you create 1 sandbox per task. Across a run of 20 tool calls in one sandbox, a 100ms difference is paid once and disappears.
An agent that writes code and then runs it needs somewhere to run it that is not your production host. The market has converged on three isolation technologies and diverged sharply on everything else.
It has also diverged on what counts as a startup number, which is why the published figures span 25 milliseconds and the measured ones span five seconds.
What are the actual isolation options?
Three boundaries, in descending order of strength.
| Platform | Isolation | Vendor claim | Measured median TTI | GPU |
|---|---|---|---|---|
| Daytona | Linux containers, plus VM class | ~90ms, unsourced | 0.27s | Yes |
| Vercel Sandbox | Firecracker microVM | Not published | 0.67s | No |
| Modal | gVisor with syscall filtering | Not published | 0.88s | T4 to B300 |
| E2B | Firecracker microVM | ~150ms, unsourced | 1.61s | No |
| Cloudflare Sandbox | Containers on Workers | Not published | 5.06s | No |
| Blaxel | Firecracker microVM | 25ms resume | Not in benchmark | Not reported |
| Northflank | Kata, Firecracker or gVisor | Not published | Not in benchmark | Yes |
Two rows deserve a warning label. The Blaxel figure is a resume from standby, not a cold start, and comparing the two is comparing different operations. The Daytona figure of 0.27s came with a 37% success rate under the same benchmark’s concurrent burst test, which means the fastest median in the table is also the one that most often did not return a sandbox at all.
Why do vendor cold starts and measured startup disagree?
Because they stop the clock in different places.
A vendor cold start typically measures the time for the platform to create the virtual machine or container. A measured time to interactive adds image pull, agent process boot, SDK handshake and the first command round trip. The MarkTechPost run in August 2026 measured the second, and the gap against circulating vendor-class numbers runs roughly tenfold.
Cloudflare Sandbox is the sharpest illustration. Its documentation publishes no latency figure at all, yet sub-50ms claims for it appear across comparison posts, apparently by borrowing the startup time of a Workers isolate. The measured median was 5.06 seconds, a factor of one hundred away.
The practical rule: treat any startup figure without a disclosed methodology, sample size and region as marketing, and measure the one operation you actually perform.
Why per-task sandboxes change the calculation
If you create a sandbox per agent task, startup is user-visible latency and the difference between 0.27s and 5.06s is real. If your sandbox lives for a whole session and handles twenty tool calls, that difference is paid once and disappears into a run measured in tens of seconds.
Most teams overweight startup because it is the number vendors publish. Count sandbox creations per completed task in your own traces first, then weigh it against the rest of what one agent task costs. If the answer is one creation, startup is a rounding error.
How strong does the boundary need to be?
That depends entirely on where the code came from.
A Firecracker microVM, used by E2B, Vercel Sandbox and Blaxel, boots its own guest kernel. An escape has to break the hypervisor rather than the container runtime, which is the boundary Blaxel describes as meaning an LLM cannot be prompted into escaping its sandbox.
Modal’s gVisor sits in between. It intercepts system calls in userspace with custom filtering, so the guest never talks to the host kernel directly, and it starts at container speed. gVisor also forwards selected NVIDIA CUDA workloads through its nvproxy layer, which is how Modal offers GPU without giving up the userspace boundary.
Container isolation, used by Daytona and Cloudflare Sandbox, shares the host kernel. It is the weakest of the three and the most familiar to operate.
The decision rule is short. Code your own team wrote, running against your own data, does not need a separate kernel. Code a model generated in response to an untrusted prompt does, which is the failure mode behind agents that got out of containment three times in three months.
What breaks first in production?
Retention of stopped state, and it breaks quietly.
| Platform | Idle default | Retention of stopped state |
|---|---|---|
| E2B | Pause saves filesystem and memory | Indefinite, no time-to-live |
| Blaxel | Suspends after 15 seconds | Indefinite standby |
| Modal | Snapshot on demand | 30 days filesystem, 7 days memory (alpha) |
| Vercel Sandbox | Snapshot on demand | 30 days default, $0.08 per GB-month |
| Daytona | Auto-stop after 15 minutes | Auto-archive after 7 days stopped |
| Cloudflare Sandbox | Sleeps after 10 minutes idle | Disk resets to image |
The spread runs from ten minutes to indefinite. If your product lets a user return to a paused agent session after a fortnight, Daytona’s 7-day archive and Modal’s 7-day memory snapshot expiry both mean that session is gone, and the failure surfaces as a confused customer rather than as an alert.
This is also where a platform default quietly substitutes for a design decision. Deciding what actually belongs in a checkpoint is your call, not the sandbox vendor’s, and the answer determines whether a resume restores a working run or just a shell.
| Check | Why it bites later |
|---|---|
| Retention of stopped sessions | Decides whether a returning user finds their work |
| Success rate under concurrent burst | A 37% success rate makes a 0.27s median meaningless |
| Whether GPU exists at all | Cannot be added by configuration if the platform lacks it |
| Egress policy from inside the sandbox | An isolated process with open internet is half isolated |
| Startup measured in your region | Published figures are usually best case, sometimes by 100x |
The egress row is the one that undermines the whole exercise. Isolating an agent’s process while leaving it unrestricted outbound access protects your host and does nothing about what the code can reach. Sandbox and egress policy are two controls, and teams frequently buy the first while assuming they bought both.
What would we pick?
Our recommendation, not a benchmark result. For arbitrary generated code with no GPU requirement, a Firecracker microVM from E2B or Vercel Sandbox, accepting the extra latency for a hardware boundary. For GPU workloads the list is three platforms long, so the isolation choice is made for you. For long-lived sessions where users come back after days, E2B’s indefinite retention outranks every latency figure in the table.
The question to answer before you shortlist
Not “which sandbox is fastest”. Ask: how many sandboxes do we create per completed task, and what happens to a session nobody touches for a month? The first number tells you whether the range from 0.27s to 5.06s matters at all. The second is the one that generates support tickets.
Frequently asked questions
What is the fastest sandbox for AI agent code execution?
That depends on which number you mean. Blaxel quotes a 25ms resume from standby, which is not a cold start. Of platforms measured end to end in an August 2026 benchmark, Daytona had the lowest median time to interactive at 0.27s, ahead of Vercel Sandbox at 0.67s and Modal at 0.88s.
What is the difference between a microVM and a gVisor sandbox?
A Firecracker microVM boots a separate guest kernel, so an escape has to break the hypervisor rather than the container runtime. Modal's gVisor intercepts system calls in userspace instead, giving container-class startup and a boundary that is weaker than a separate kernel but much stronger than a plain container.
Which agent sandboxes support GPUs?
Modal, Daytona and Northflank are the three that offer GPU-backed sandboxes. Modal publishes the broadest lineup, from T4 through B300 including H100, H200, L40S and RTX Pro 6000 Blackwell. Daytona offers NVIDIA H100, H200, RTX 4090, RTX 5090 and AMD Instinct MI355X, with GPU sandboxes deleted on stop.
How long does a paused agent sandbox survive?
It ranges from ten minutes to forever. E2B documents that paused sandboxes are kept indefinitely with no time-to-live, Blaxel advertises indefinite standby, Modal expires memory snapshots after 7 days and filesystem snapshots after 30, Daytona auto-archives after 7 days stopped, and Cloudflare Sandbox resets disk to the image after 10 minutes idle.
Do you need a sandbox to run an AI agent?
Only if the agent executes code or commands it generated. An agent that calls typed APIs does not need one. The moment it can run arbitrary code, the question stops being whether to isolate and becomes how strong the boundary has to be.
Method and sources
- Best Agent Sandboxes in 2026: Cold Start, Per-Second Pricing, and Network Policy, MarkTechPost, 27 August 2026, marktechpost.com: median time to interactive of 0.27s for Daytona, 0.67s for Vercel Sandbox, 0.88s for Modal, 1.61s for E2B and 5.06s for Cloudflare Sandbox, plus the concurrent burst test in which Daytona returned a 37% success rate. This is the only end to end measurement cited here. Checked 16 September 2026.
- E2B documentation, docs.e2b.dev/sandbox/persistence: paused sandboxes are kept indefinitely, with no automatic deletion and no time-to-live, and are released only by an explicit kill. This supersedes the 30-day deletion policy still quoted in third-party comparisons. Checked 16 September 2026.
- Daytona documentation, daytona.io/docs/en/sandboxes: sandboxes run as Linux containers by default, auto-stop after 15 minutes of inactivity and auto-archive after 7 days stopped, with auto-delete disabled by default. GPU sandboxes cover NVIDIA H100, H200, RTX Pro 6000, RTX 4090, RTX 5090 and AMD Instinct MI355X. Checked 16 September 2026.
- Modal documentation, modal.com/docs/guide/sandbox-snapshots: filesystem and directory snapshots persist 30 days after creation and are generally available; memory snapshots expire 7 days after creation and remain alpha behind experimental methods. Checked 16 September 2026.
- Blaxel, blaxel.ai/sandbox: every sandbox is an individual microVM built on Firecracker, suspended after 15 seconds of inactivity with no 24-hour timeout and resumed in about 25ms with state intact. Vendor claim, not independently measured. Checked 16 September 2026.
- Cloudflare documentation, developers.cloudflare.com/sandbox: each sandbox runs in its own isolated container with a full Linux environment, built on Cloudflare Containers. The documentation publishes no startup latency figure. Checked 16 September 2026.
- The figures of about 90ms for Daytona and about 150ms for E2B circulate widely in 2026 comparison posts, but we could not find a primary publication disclosing methodology, sample size or region behind them, so they appear here only as vendor-class claims and never as measurements.
- We have not run any of these benchmarks ourselves. Startup latency is sensitive to region, image size, warm pool state and concurrency, and every figure above should be re-measured in your own account before it decides anything.