Rent the Sandbox or Own the Fleet? What a 26-Provider Survey Says About Agent Isolation

Every team shipping an AI agent hits the same question within weeks of the first demo: where does the generated code actually run? On a laptop it is fine until the agent deletes something it should not have. In production it is a non-starter — an agent that writes and executes arbitrary code needs a sandbox with a real isolation boundary, a cold start fast enough to feel interactive, and a bill that does not scale with your anxiety. A 2026 survey from engine.build lined up 26 hosted, platform-native, open-source, and self-hosted sandbox options across startup time, persistence, pricing, and SDK surface, and the spread is the whole story: the fastest option boots in under 30 milliseconds with a shared kernel, the most isolated takes over ten times longer behind its own kernel — and there is no option that wins both axes at once.

Here is the verdict up front, distilled from the survey's four buckets plus the one option the survey cannot price — your own fleet:

Two things pop out immediately. First, E2B, Daytona, and Blaxel converge on exactly the same normalized price — about $0.083 per hour for a 1 vCPU + 2 GB slot — while running three different isolation stacks, which tells you the market has priced the slot, not the isolation. Second, the owned-fleet row is 3–8x cheaper per slot-hour at healthy utilization, and it is the only row where the isolation column is a choice rather than a vendor decision. The rest of this post earns those two claims: the curve both tables sit on, the workload math that decides build vs. rent, and the June 2026 event that repriced "rent" for everyone paying attention.

One curve to place them all: startup time vs. isolation strength​

Every sandbox in the survey sits somewhere on a single curve, and the curve is set by four primitives, not by vendors. Vendors pick a point on it; they do not move it.

At the fast, weak end are plain containers (runc, Docker): Linux namespaces plus cgroups on the shared host kernel, booting in roughly 100 ms with tens of megabytes of overhead. Isolation is only as strong as the host kernel's syscall surface — a kernel exploit escapes every tenant on the box at once. Fine for dev, disqualifying for running untrusted agent code multi-tenant.

One step up is gVisor (runsc): a user-space kernel that intercepts syscalls before they reach the host. Typical startup lands at 50–100 ms with 10–15 MB of overhead, and it is the reason Modal can offer sub-second sandboxes with a container-like density model. The cost is compatibility and throughput: intercepted syscalls are slower, and the file-I/O benchmarks consistently rank gVisor behind Firecracker — one study measured Firecracker at 4,749 MB/s sequential read on 1 MB blocks versus 3,766 MB/s for gVisor and 1,113 MB/s for Kata. You pay for the interposition layer on every hot path.

Then come microVMs (Firecracker, Cloud Hypervisor): a real guest kernel per sandbox under KVM, booting in about 125 ms with a ~5 MB VMM footprint, resuming from snapshot far faster — copy-on-write fork restores have been measured near a millisecond on tuned hosts, and hosted products quote 25 ms resume times from standby. This is the isolation serious multi-tenant platforms converge on: hardware virtualization boundary, own kernel, snapshot/restore as a first-class operation. E2B, Blaxel, Fly Machines, and Vercel Sandbox all live here.

At the heavy end sits Kata Containers: a full lightweight VM per pod, typically 150–300 ms to boot on modern stacks (older QEMU-backed setups stretch past a second) with the highest memory overhead of the four. Kata buys Kubernetes-native semantics — it is a pod — at the price of booting the most machine per sandbox.

The curve, stated bluntly: each step toward a stronger boundary costs roughly a doubling of cold-start latency and per-sandbox memory, right up until snapshots cheat the tradeoff by separating boot time (paid once, at template build) from resume time (paid per sandbox). That is why the lead table splits cold start from resume — any comparison that merges them is comparing one vendor's boot against another's resume, which is how marketing numbers beat engineering numbers.

The field, bucket by bucket​

The survey's 26 options fall into four buckets, and the bucket predicts the business model more reliably than the technology does.

Hosted sandboxes (E2B, Daytona, Morph, Blaxel, Freestyle and kin) sell an API and an SDK, bill per second, and converge on nearly identical unit prices: E2B and Daytona both land at $0.000014 per vCPU-second ($0.0504 per vCPU-hour) plus about $0.0000045 per GiB-second for RAM, and independent normalizations put E2B, Daytona, and Blaxel at exactly $0.0828/hour for the reference 1 vCPU + 2 GB slot. Freestyle undercuts slightly at $0.04032 per vCPU-hour. Differentiation lives in lifecycle semantics — Daytona's sub-90 ms starts with pause/fork for parallel agents, E2B's Python-REPL ergonomics and template library, Blaxel's standby-plus-hibernate perpetual sandboxes with scale-to-zero in about a second — not in the meter rate. When every vendor charges the same per slot-hour, pick on resume latency, persistence model, and SDK surface, because the bill will not distinguish them.

Platform-native runtimes (Modal, Vercel Sandbox, Fly Machines) bundle the sandbox into a broader compute platform and price accordingly. Modal's gVisor-based sandboxes run about $0.00003942 per core-second — roughly $0.14/hour per core before memory, nearly 3x the hosted-sandbox slot price — but buy 50,000+ concurrency, snapshots, and the strongest GPU story in the survey. Vercel Sandbox bills active CPU at $0.128 per vCPU-hour, which is cheap for spiky agent traffic and punishing for a sandbox that idles hot. Fly Machines bills per second by machine size with persistent volumes, making it the only platform-native option where a sandbox can cheaply exist without running. The pattern: platform natives charge a premium per slot-hour and return it as GPUs, concurrency, or colocated app hosting.

Open-source runtimes are the survey's most strategically interesting bucket, because June 2026 rearranged it. Daytona moved its core development to a private codebase that month — last open release v0.190.0 under AGPL-3.0, with the company citing the risk of AI-assisted attackers studying a public isolation implementation as an exploit blueprint — and the community immediately forked it as Nightona to keep a self-hostable path alive. E2B's infrastructure remains open source (Firecracker orchestrated on Nomad/Terraform, though self-hosting it is honestly a small infrastructure project, not a weekend deploy). And kubernetes-sigs/agent-sandbox gives the Kubernetes-native option an upstream Apache-2.0 home. The bucket's lesson is that open today is not a permanent property of a vendor — it is a property of a license plus a community willing to fork.

Self-hosted primitives (raw Firecracker, gVisor, Kata, Cloud Hypervisor) have no price and no SDK — they are the engines under everyone else's table, documented in depth by the community's curated lists. A June 2026 arXiv security study systematized exactly this layer, comparing engine-level attack surface, leakage, CVE history, and patch cadence across the Docker/OCI, gVisor, Firecracker, and Cloud Hypervisor classes. Its existence is itself a signal: the industry now treats the isolation engine as a security decision demanding its own literature, not an implementation detail.

Build vs. rent: two workload shapes decide it​

Cost comparisons usually pick one workload and declare a winner. The honest version runs two shapes, because sandboxes serve two masters: the always-on agent workspace and the bursty per-task execution.

Shape A: the always-on workspace. One 1 vCPU + 2 GB sandbox, running 730 hours a month. Rented from E2B, Daytona, or Blaxel at the normalized $0.0828/hour, that is about $60/month. On Modal-class pricing it is roughly double. On an owned node — say a dedicated 8 vCPU / 32 GB box at ~$45/month, packing 1 vCPU + 2 GB slots at 70% utilization (~11 slots) — the same slot costs about $4/month amortized. Owned wins by more than 10x, and this is the shape where every "just rent E2B" recommendation quietly bleeds: an idle-but-alive sandbox bills identically to a busy one on per-second meters with no scale-to-zero.

Shape B: bursty task execution. Two thousand agent runs a month, two minutes each — about 67 slot-hours. Rented, that is roughly $5.50 on E2B/Daytona pricing, under $4.50 on Freestyle, with zero capacity planning and resume latencies no self-hosted pool will beat without pre-warmed hosts. Owned, those same 67 hours still cost the full $45 node (or a scale-to-zero pool with its own cold-start tax on every burst). Rented wins by nearly 10x, and this is the shape where every "just self-host Firecracker" recommendation quietly bleeds: you are buying 730 hours of hardware to consume 67.

The breakeven sits where the two lines cross: sustained utilization around 15–25% of a slot favors owning; below that, renting wins, and the exact crossing moves with resume-latency requirements (pre-warmed pools cost money even when idle) and GPU needs (owned GPUs amortize brutally well at high utilization and brutally badly at low). Run both shapes against your actual trace before committing — the survey's pricing convergence means the arithmetic is stable, but your utilization is the entire game.

Risk box: renting has a failure mode no price table captures. In June 2026 Daytona closed its core — the self-host path teams had adopted became a frozen AGPL snapshot plus a community fork. Any rented sandbox can relicense, reprice, or deprecate the exact lifecycle feature you built on. Treat the rent decision as carrying an exit-cost term: prefer vendors with open inevitability (exportable snapshots, standard SDKs) and keep the migration path warm.

Where your own fleet sits on the curve​

Here is the row the survey cannot print: a Cluster-API-managed fleet running Kata or Firecracker pools lands at ~125–300 ms cold start plus image-pull time, with snapshot or pool-warming to reach the 25–90 ms resume band the hosted vendors quote — at roughly $0.01–0.03 per slot-hour amortized at healthy packing. That puts it strictly below every rented row on price and squarely mid-curve on latency, with one structural advantage no vendor row has: the isolation column is per-pool, not per-vendor. Run gVisor pools for cheap, dense, low-risk tenants and Kata/Firecracker pools for untrusted agent code on the same fleet, and you have placed two points on the curve where every vendor gets one.

The decision guide that falls out:

• Bursty, spiky, or exploratory (evals, CI-adjacent runs, a hackathon): rent. Freestyle or E2B on price, Daytona-class fork/resume if agents run parallel sandboxes, Vercel Sandbox if traffic is spiky enough for active-CPU billing to win. Keep snapshots exportable.
• Always-on workspaces or sustained agent fleets past ~25% slot utilization: own. The 10x delta at full utilization funds a lot of platform engineering, and the isolation choice becomes yours per workload class.
• GPU-backed agent sandboxes: rent first (Modal's GPU depth is unmatched), own the moment utilization justifies a card — fractional sharing via DRA or HAMi slicing is what makes one owned GPU serve many tenants, and that is a fleet-level feature no per-slot meter can replicate.
• Regulated or paranoid: own on hardware you control, Kata or Firecracker boundary, with the arXiv engine-security comparison as your audit starting point — and note Daytona's stated rationale for closing its source before dismissing "attackers study public isolation code" as theoretical.

The survey's real finding is not a ranking. It is that the market has settled: slots cost ~$0.08/hour, isolation costs latency, and snapshots are the only free lunch — they move a sandbox along the latency axis without moving it along the isolation axis. Vendors sell you one point on that curve. A fleet you own lets you pick the point per workload, keep the 3–8x slot margin, and never discover via changelog that your sandbox provider has a new license. That is the tradeoff; the curve does the rest.

Running agent sandboxes you own instead of renting them by the second? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.