# A Practical Guide to Agent Sandbox Platforms in 2026: Cold Starts, Costs, and Network Controls
Every AI coding agent needs an environment where it can actually execute code. That environment has become a distinct product category, populated by at least a dozen vendors, each with different pricing structures, architectural trade-offs, and marketing claims that rarely compare cleanly. This guide cuts through the noise by focusing on the measurements and properties that actually affect how your agent performs and what it costs to run.
The platforms covered here span the range most teams evaluate: E2B, Daytona, Modal Sandboxes, Cloudflare Sandbox SDK, Vercel Sandbox, Runloop, Fly.io Sprites, and Northflank. Each brings a different combination of speed, isolation, persistence, and cost to the table.
—
## The Four Properties That Actually Matter
Feature comparison tables for this category tend to drown readers in trivia. In practice, four architectural decisions dominate everything else:
1. **Cold start under concurrent load** — An agent loop that provisions a fresh sandbox for each tool call pays this overhead thousands of times daily. The question is not “how fast is a single creation?” but “how fast is a creation when the system is already under pressure?”
2. **Filesystem persistence across turns** — Does the second turn of an agent session see the `pip install` from the first turn, or does the agent start from a clean slate every time? This single property determines whether your agent spends its time rebuilding dependencies or actually doing work.
3. **Egress policy** — Can the sandbox reach the internet? Can you disable that access, and can you change the policy mid-session without restarting? This is increasingly relevant as agents handle sensitive credentials and need to make authenticated calls safely.
4. **Idle billing** — Agents spend the vast majority of their wall-clock time waiting on a language model to respond. Whatever billing model a platform uses, someone is paying for those idle seconds.
—
## Cold Start Performance: What the Numbers Reveal
Vendor marketing pages are not comparable to one another. One platform may advertise sub-90ms sandbox creation under sequential conditions, while another reports sub-second cold starts for pre-cached containers. These numbers describe different tests and cannot be directly compared without understanding what was measured.
The most useful public benchmark in this space is an open-source leaderboard maintained by ComputeSDK, which runs on a regular schedule. It measures **Time to Interactive (TTI)** — the elapsed time from calling the creation API to the first successful command executing inside the sandbox. Each provider is tested with 100 iterations, launched concurrently in a single burst, from a 4 vCPU host in Northern Virginia.
### Results from the August 2026 benchmark run:
| Provider | Median TTI | P95 | P99 | Success Rate |
|———-|———–|—–|—–|————-|
| Vercel Sandbox | 0.67s | 1.04s | 1.12s | 100% |
| Modal | 0.88s | 1.00s | 1.08s | 100% |
| Runloop | 0.89s | 3.27s | 3.50s | 100% |
| E2B | 1.61s | 1.77s | 1.81s | 100% |
| Cloudflare | 5.06s | 6.04s | 6.48s | 100% |
| Daytona | 0.27s | 0.43s | 0.44s | 37% |
### Three things that matter more than the ranking
**Burst performance is not sequential performance.** Daytona’s fastest published median is real, and in earlier single-instance runs it has created sandboxes at a 0.10s median. But in a concurrent burst scenario, it only completed 37 out of 100 attempts. A median that you reach on only a third of your calls is not a latency number — it is a capacity number. Retry logic is essential on every platform in this category.
**Tail latency is the number your architecture must be designed around.** Runloop’s median and Modal’s median sit just 10ms apart. Runloop’s P95, however, is 3.3 times Modal’s P95. If your agent’s user experience budget is one second, the median tells you almost nothing useful.
**Cloudflare is measuring a fundamentally different operation.** Its Sandbox SDK runs on Cloudflare Containers, which schedules a container instance and boots a full image. This is architecturally a heavier operation than resuming a pre-warmed Firecracker microVM, and the 5-second medians reflect that reality. Cloudflare’s own documentation is candid about this: booting a sandbox, cloning a repository, and running `npm install` takes roughly 30 seconds, while restoring the same environment from a backup takes about two.
### How to measure this yourself
The workload worth measuring is the actual workload your agent runs, not a trivial `echo hello` command. A solid harness runs the same unit of work against every provider: install pandas, load a CSV, generate a plot, return a PNG file. Time four checkpoints separately — creation, ready state, dependency installation, and task completion — across 100 iterations run both sequentially and concurrently. Report creation time and task time independently, because vendors optimize for the first metric while your users experience the second. Pin the region, pin the image, and publish both the sequential and concurrent results, since they answer different questions.
—
## Per-Second Pricing, Normalized
Published rates change frequently, but as of late August 2026, the following table converts every platform to a common unit for direct comparison. Modal’s sandbox tier bills per physical core, which Modal defines as 2 vCPU, so the vCPU-equivalent rate is shown alongside for apples-to-apples comparison.
| Platform | CPU Rate | Memory Rate | Billing Basis | Plan Floor |
|———-|———-|————-|—————|————|
| E2B | $0.0504 / vCPU-hr | $0.0162 / GiB-hr | Wall-clock, per second | Free Hobby; $150/mo Pro |
| Daytona | $0.0504 / vCPU-hr | $0.0162 / GiB-hr | Wall-clock, per second | None; $200 credit |
| Modal Sandbox | $0.1419 / core-hr (~$0.0710 / vCPU-hr) | $0.0240 / GiB-hr | max(request, actual), per second | Free Starter; $250/mo Team |
| Vercel Sandbox | $0.128 / vCPU-hr (active CPU only) | $0.0212 / GB-hr (provisioned) | Split: active CPU, wall-clock memory | Hobby allotment; Pro credit |
| Cloudflare Sandbox | $0.072 / vCPU-hr (active CPU only) | $0.009 / GiB-hr (provisioned) | Active CPU + provisioned memory/disk | $5/mo Workers Paid |
| Fly.io Sprites | $0.07 / CPU-hr | $0.04375 / GB-hr | Active use only; sleeps when idle | Subscription tiers |
| Runloop | $0.108 / CPU-hr | $0.0252 / GB-hr | Running state; suspended is storage-only | Free Basic; $250/mo Pro |
| Northflank | $0.01667 / vCPU-hr | $0.00833 / GB-hr | Allocated resources, per second | Free Sandbox tier |
### Two common misconceptions
**Modal’s sandbox tier costs roughly three times its standard Function rate** — approximately $0.00003942 versus $0.0000131 per core-second — and regional selection adds another 1.5 to 1.75 times on top. Sandbox pricing is not Modal’s headline compute pricing, and anyone comparing it to standard Functions will get a misleading picture.
**Daytona’s GPU rates have been widely reproduced at $3.95/hr for H100, but its live pricing page now lists on-demand H100 at $2.27/hr and H200 at $2.61/hr.** Third-party comparison tables in this category go stale within a quarter. Always verify against the vendor’s current pricing page before committing.
—
## Real-World Cost: Cost Per 1,000 Executions
Published rates are not the same as actual costs. The scenarios below fix a workload and run it through each platform’s rate card.
### Assumptions: 2 vCPU / 4 GiB sandbox, 1,000 executions, no plan floors, no egress charges, default region.
#### Scenario A: Short Burst — 90 seconds alive, 50% average CPU
This models a one-shot code execution tool where the sandbox spins up, does work quickly, and then shuts down.
| Platform | Cost per 1,000 | Composition |
|———-|—————|————-|
| **Northflank** | **$1.67** | $0.83 CPU + $0.83 memory |
| **Cloudflare** | **$3.70** | $1.80 CPU + $1.80 memory + $0.10 disk |
| E2B / Daytona | $4.14 | $2.52 CPU + $1.62 memory |
| Vercel | $5.32 | $3.20 active CPU + $2.12 memory |
| Modal | $5.95 | $3.55 CPU + $2.40 memory |
| Fly Sprites | $7.88 | $3.50 CPU + $4.38 memory |
| Runloop | $7.92 | $5.40 CPU + $2.52 memory |
#### Scenario B: Idle-Heavy — 10 minutes alive, 5% average CPU
This models a real agent loop where the sandbox stays open, the model is thinking, and nothing is actively computing.
| Platform | Cost per 1,000 | Change vs Scenario A |
|———-|—————|———————|
| **Northflank** | **$11.11** | 6.7x |
| **Cloudflare** | **$13.87** | 3.7x |
| **Vercel** | **$16.27** | 3.1x |
| E2B / Daytona | $27.60 | 6.7x |
| Modal | $39.66 | 6.7x |
| Fly Sprites (kept awake) | $52.50 | 6.7x |
| Runloop (kept running) | $52.80 | 6.7x |
The shift from Scenario A to Scenario B reveals a dramatic insight. Vercel jumps from fourth-cheapest to third, and its CPU cost line drops from $3.20 to $2.13 while every wall-clock-billed platform scales linearly with waiting time. Cloudflare’s active-CPU cost line falls to just $1.20. That is the entire economic argument for active-CPU billing — it is worth roughly 2x on idle-heavy workloads.
#### Scenario B with Suspend
Platforms that lose Scenario B can recover, if your orchestration suspends the sandbox between turns rather than keeping it open. Same workload, 30 seconds awake per execution:
| Platform | Cost per 1,000 | Mechanism |
|———-|—————|———–|
| **E2B (auto-pause)** | **~$2.16** | Pause costs ~4s per GiB of RAM; resume takes ~1s |
| Fly Sprites | $2.62 | Idle monitor sleeps the sprite within seconds |
| Runloop | $2.64 | Suspend stops compute billing; storage continues |
E2B’s figure includes approximately 17 seconds of pause and resume overhead for a 4 GiB sandbox. That overhead is the deciding variable: pausing only pays off when the gap between turns is meaningfully longer than the pause and resume time themselves.
Fly’s idle detector is specific about what counts as activity: an in-flight HTTP or API request, output written to a session’s stdout, an open TCP connection, or an active task. An agent that holds a TCP connection open while waiting for the model is an agent that continues to be billed. Redirecting output to a file instead of stdout is a small code change that has real cost implications.
—
## Filesystem Persistence Between Turns
This is where platforms diverge most sharply, and where the wrong choice reveals itself as a rebuilt `node_modules` directory on every single turn.
| Platform | Default on Stop/Idle | Memory State Preserved | Mechanism |
|———-|———————|———————-|———–|
| **E2B** | `onTimeout` defaults to `kill` | Yes, via pause | `pause()` / `connect()`, paused boxes kept indefinitely |
| **Daytona** | Persistent by default; auto-stop 15 min (containers), auto-pause 60 min (VMs) | VM sandboxes only, via pause/resume | Stop, archive, pause, fork, volumes |
| **Modal** | Terminated at `timeout` (default 5 min, max 24h) | Memory snapshots, 7-day expiry | Filesystem snapshots become Images, 30-day default TTL |
| **Cloudflare** | Sleeps after 10 min; **disk resets to image** | No | `createBackup()` / `restoreBackup()`, R2 mounts |
| **Vercel** | Persistent; snapshots filesystem on stop | No | Snapshots, 30-day default expiry, $0.08/GB-mo |
| **Runloop** | Suspend preserves state | Yes, via suspend/resume | Suspend/resume and snapshot branching (Pro plan only) |
| **Fly Sprites** | 100 GB root filesystem persists indefinitely | Checkpoint/restore | Object-storage-backed disk, no container image |
### Three details that catch teams off guard
**E2B’s default kills your work.** The `onTimeout` setting defaults to `kill` unless you explicitly set `lifetime: { onTimeout: ‘pause’ }` at creation time. The killed state is terminal — there is no shutdown signal before termination. Any unsaved work in that sandbox is gone. Treat it as lost.
**Cloudflare’s disk is ephemeral across sleep.** Official documentation states plainly that a sleeping container instance restarts with a fresh disk from its image. Backup and restore to R2 works today, and an automatic `persistAcrossSessions` disk snapshot was announced at general availability but was still rolling out at the time of this writing.
**Daytona splits persistence by sandbox class.** Container sandboxes preserve the filesystem across stop and start but do not support pause, so memory is cleared every time. Linux VM sandboxes support both stop/start and pause/resume. GPU sandboxes are ephemeral and are deleted on stop; any results must be written to a volume beforehand.
—
## Egress Policy: What Each Platform Allows
Every platform in this comparison can now run a sandbox with no internet access. The differences lie in precedence, granularity, and whether policy can change without restarting the sandbox.
| Platform | Default | Block All | Allowlist | Change at Runtime |
|———-|———|———–|———–|——————-|
| **E2B** | Open egress | `allowInternetAccess: false` | Domains, IPs, CIDRs; wildcards | Yes, `updateNetwork()` replaces entire policy |
| **Daytona** | Tier-dependent | `networkBlockAll` | `domainAllowList` (20 max), `networkAllowList` (10 CIDRs, IPv4 only) | Yes, Tier 3 and 4 only |
| **Modal** | Open egress, no inbound | `block_network=True` | `outbound_cidr_allowlist`, `outbound_domain_allowlist` (beta) | Alpha; allowlists must be set at creation |
| **Cloudflare** | Open egress | `enableInternet = false` | `allowedHosts` / `deniedHosts`, glob patterns | Yes, handlers and host rules apply live |
| **Vercel** | `allow-all` | `deny-all`, including DNS | Domains via SNI, plus IP/CIDR fallback | Yes, without restarting |
| **Runloop** | Network policies per devbox | Yes | Yes | Documented per devbox |
### The precedence trap
E2B and Vercel resolve policy conflicts in opposite directions. In E2B, allow rules take precedence over deny rules — an IP address appearing in both lists is allowed. In Vercel Sandbox, denied ranges override allowed ranges. A policy written for one platform and ported directly to the other does not mean the same thing. Always test your exact policy configuration on the target platform.
### The failure-mode trap
E2B documents that blocked TCP connections can appear successful from inside the sandbox. The firewall accepts the connection before it decides whether the destination is allowed, so a socket opens and no packets arrive. Verify egress with an application-level response — an HTTP status code, a successful TLS handshake — not by checking for a connection error. Any test suite that asserts “network is blocked” by checking for a failed `connect()` will pass against a sandbox that is actually unblocked.
### Credential injection: the real differentiator
Blocking external access is table stakes. Letting a sandbox make an authenticated call without ever holding the credential in its environment is a fundamentally different security posture.
Cloudflare runs outbound handlers in the Workers runtime, outside the sandbox, with access to Workers bindings. The sandbox issues a plain request; the handler attaches the secret, and `ctx.containerId` scopes credentials per instance. Vercel brokers credentials on egress with matchers scoped by path, method, query string, or headers, and states the firewall runs on the host outside the microVM where sandbox code cannot disable it. E2B ships per-host request transforms in public beta that inject headers at the egress proxy, including workload-identity tokens the sandbox never sees. Runloop offers a Credential Gateway with opaque token injection.
For agents processing untrusted input, this design matters more than cold start. A prompt-injected agent with a GitHub token in its environment is a different incident than one that can only reach GitHub through a proxy holding the token.
—
## Isolation, Limits, and the Fine Print
| Platform | Isolation Model | Max Session | Concurrency | GPU in Sandbox | Self-Host / BYOC |
|———-|—————-|————-|————-|—————|——————|
| E2B | Firecracker microVM | 1hr Hobby, 24h Pro; resets after pause | 20 Hobby, 100 Pro, up to 1,100 | No | Apache-2.0 infra repo, Terraform + Nomad + Consul |
| Daytona | Containers, plus VM and Windows classes | Configurable, wall-clock TTL optional | Tier-based | Yes (ephemeral) | BYOC, enterprise |
| Modal | gVisor | 5 min default, 24h max | 100 Starter, 5,000 Team | Yes, full rate card | No |
| Cloudflare | Containers on Workers | Sleeps at 10 min idle; `keepAlive` available | 15,000 lite, 1,000+ standard-2 | No | No |
| Vercel | Firecracker microVM | 45 min Hobby, 24h Pro | 10 Hobby, 10,000 Pro | No | AWS BYOC in private beta |
| Runloop | microVM | Suspend/resume | 10,000 demonstrated | No | VPC deployment |
| Fly Sprites | Firecracker microVM | Persistent | Subscription tiers | No | No |
| Northflank | microVM (Kata, Firecracker, gVisor) | Persistent or ephemeral | Platform-level | Yes | Self-serve BYOC |
—
## Frequently Asked Questions
**Q: Why does Daytona’s median cold start look so fast but its success rate is only 37%?**
Daytona’s fast median reflects sequential, low-pressure creation. Under concurrent burst — the scenario that matters for agent loops — it fails on nearly two-thirds of attempts. A platform that only meets its latency target on a third of calls is a capacity problem, not a speed advantage. Design for the P95 and P99, not the median.
**Q: Which platform is genuinely the cheapest?**
There is no single answer. Northflank is cheapest for short burst workloads and has the lowest published rate card. But for idle-heavy agent loops, the cheapest option depends on whether you suspend between turns (E2B, Fly Sprites, or Runloop with suspend) or keep the sandbox running (Cloudflare or Vercel with active-CPU billing). The billing model matters more than the headline rate.
**Q: Is active-CPU billing always better than wall-clock billing?**
Not always. Active-CPU billing saves money when the sandbox is mostly idle — the agent is waiting on the model. But if your agent is doing continuous computation, active-CPU billing and wall-clock billing converge. The benefit is specific to workloads with long gaps between active computation.
**Q: Which platform should I pick for a coding agent evaluation pipeline?**
Runloop is purpose-built for this use case. It supports SWE-Bench-style evaluation and offers suspend/resume functionality, though that feature requires the $250/month Pro plan.
**Q: What happens if I don’t configure persistence explicitly?**
On E2B, the sandbox is killed on timeout by default, and unsaved work is lost permanently. On Cloudflare, the disk resets to the base image when the sandbox sleeps after 10 minutes of inactivity. On Vercel, the filesystem is snapshotted when the sandbox stops. Always check the default behavior for your chosen platform and configure it explicitly.
**Q: Can I change egress policy without restarting the sandbox?**
E2B, Vercel, Cloudflare, and Daytona (on Tier 3/4 plans) support runtime policy changes. Modal’s runtime policy change feature is in alpha and requires allowlists to have been set at creation time. Always verify the current state of runtime configurability in the vendor’s latest documentation.
**Q: How often do these rates and benchmarks change?**
Vendor pricing pages and sandbox behaviors change monthly. The rates and latency figures in this guide reflect a specific date in August 2026 and should be treated as a snapshot. Re-verify against primary sources before making architectural decisions or signing contracts.
—
## Conclusion
Choosing an agent sandbox platform is not about finding the single best option — it is about matching a platform to your specific constraints. The four properties that matter most — cold start under load, filesystem persistence, egress policy, and idle billing — interact in ways that make head-to-head rankings misleading.
If your agent waits on models more than it computes, active-CPU billing platforms like Vercel Sandbox and Cloudflare Sandbox offer meaningful cost advantages, and Vercel’s measured burst latency is the tightest in this set. If you need per-session kernel isolation for adversarial code or a path to self-hosting, E2B remains the strongest choice — but set `onTimeout: ‘pause’` from day one and budget for its Pro tier early. If persistence and forking are central to your workflow, Daytona offers the most developed lifecycle tooling in the category. If any part of your agent’s work touches a GPU, Modal is the only platform here with a full GPU rate card inside the sandbox.
The platforms that win on paper sometimes lose in practice, and the platforms that look expensive on a rate card can become the cheapest once you account for how your agent actually uses them. Measure the workload your agent runs, not the microbenchmark the vendor publishes, and let your actual usage pattern — not a feature matrix — drive the decision.
Thank you for reading
