The AI Agent Sandbox Wars: E2B vs Daytona vs Modal vs Fly Machines Compared

Daytona raised $24M in February 2026 to build faster containers. Not model training clusters, not GPU capacity for inference — containers that run code an AI agent just wrote, and might delete your database with. By May 2026 the company was running 850,000 of those sandboxes a day, growing 74% month over month. "Where does an agent's generated code actually execute" has quietly become its own infrastructure category, with real venture money and four genuinely different architectures competing for it: E2B's Firecracker microVMs, Daytona's container-first pivot, Modal's Python-native serverless cloud, and Fly Machines as a raw primitive teams wire up themselves.

The Comparison, Upfront​

Four products, four different bets on what "isolated enough" means for code an LLM wrote a few seconds ago:

Three genuinely different isolation technologies are hiding in that "self-hosted PaaS" row: hardware-virtualized microVMs (E2B, Fly), OS-level containers with an optional VM escape hatch (Daytona), and a userspace kernel that intercepts syscalls without a hypervisor (Modal's gVisor). That distinction — not the marketing copy — is what should drive a platform's build-vs-buy decision, so it's worth taking seriously before the pricing math.

What "Isolated" Actually Means Here​

Firecracker, the AWS-built microVM technology underneath both E2B and Fly, gives each sandbox its own kernel via KVM hardware virtualization — no device emulation, no BIOS, a minimal attack surface purpose-built for running untrusted code at Lambda-scale. If an agent's generated code manages to escape the sandboxed process, it's still trapped inside a separate kernel from the host. That's the strongest isolation boundary of the four, and it's why E2B and Fly both lead with it in security-conscious sales conversations.

Daytona's default is a plain Docker/OCI container — the same namespace-and-cgroup isolation any container runtime provides, which is faster to schedule and cheaper to run, but shares the host kernel with every other tenant on the box. Daytona's answer to that gap is optional Kata Containers, which wraps a lightweight VM (via QEMU, Cloud Hypervisor, or Firecracker itself) around the container so it gets a dedicated guest kernel without the team having to hand-build microVM tooling. It's the same tradeoff most platforms eventually make: containers by default for speed and cost, VM isolation as an opt-in for anything actually untrusted.

Modal sits in a third position. gVisor doesn't use hardware virtualization at all — it's a userspace kernel written in Go that intercepts a sandboxed process's syscalls and re-implements the ones it decides to allow, running as a normal process rather than a separate VM. That's weaker than a full hypervisor boundary against a determined kernel-exploit attacker, but it's also why Modal can schedule up to 20,000 concurrent containers and give agents native GPU access in the same breath — there's no VMM overhead to work around.

None of these is "wrong." The isolation-strength ordering (Firecracker/Kata ≥ gVisor > plain containers) has been stable across every serious comparison for two years; what's changed in 2026 is that a $24M-funded startup is now betting its entire product on the "containers by default, VM on demand" middle tier, which tells you where the market thinks most agent workloads actually sit on the risk spectrum.

What a 4-Hour Agent Session Actually Costs​

Vendors quote per-second and per-core-hour rates that don't compare cleanly across billing models. Normalized to the same workload — 1 vCPU, 1 GiB RAM, a 4-hour session, no GPU — here's what each provider's own published rate card works out to:

Two caveats keep this honest. First, none of these providers bill quite like the others — E2B's flat per-sandbox rate bundles a memory allowance the others charge for separately, so the ~$0.20 figure is directionally low rather than a true apples-to-apples floor. Second, this is a light, non-GPU workload; the moment an agent needs a GPU for local inference or fine-tuning, Modal's native GPU scheduling and per-second GPU billing (T4 at $0.59/hr up to B200 at $6.25/hr) change the calculus entirely, since E2B and Daytona require separate GPU infrastructure and Fly Sandboxes don't offer GPUs at all.

The pattern holds regardless of the exact cents: paying by the metered second for a container or microVM you don't own costs real money at agent scale, and the gap between "cheapest" (E2B's bundled flat rate) and "most expensive" (Modal, gVisor plus GPU-scheduling overhead built into the CPU rate) is roughly 2.5-3x for the identical light workload — before either provider's GPU line items enter the picture.

The Kubernetes-Native Option Nobody's Marketing Yet​

All four products above are vendor infrastructure — you rent sandbox-seconds from someone else's fleet. There's a fifth option quietly taking shape inside Kubernetes itself: agent-sandbox, a Kubernetes SIG Apps subproject that shipped its first CNCF blog writeup in March 2026. It introduces a Sandbox custom resource purpose-built for exactly the workload shape an AI agent needs — a singleton, stateful pod with a stable identity and persistent storage, unlike the stateless, horizontally-scaled pods most of Kubernetes was designed around.

The part that matters for a self-hosted platform: Sandbox natively supports both gVisor and Kata Containers as pluggable runtimes via standard Kubernetes RuntimeClass — the exact same two non-plain-container isolation technologies Daytona and Modal are selling as their differentiator, available as a RuntimeClass field on a CRD you already run. A SandboxWarmPool resource keeps a pool of pre-provisioned, isolated pods on standby so a SandboxClaim gets a warm environment immediately instead of paying cold-start latency on every request — the same warm-pool trick E2B and Daytona built proprietary infrastructure to solve, expressed as three Kubernetes objects.

It's not a finished answer yet. As of its initial 2026 release, agent-sandbox is explicitly not production-ready for every workload, and Kata Containers itself trades roughly 150-300ms of VM-boot startup time for the operational simplicity of a RuntimeClass versus the 100-200ms a hand-tuned Firecracker deployment can hit with pre-warming. For a platform already running Cluster API on owned machines, though, the direction of travel is clear: the isolation primitives the sandbox vendors charge per-second for are becoming things a Kubernetes cluster does natively, the same way Gateway API absorbed what used to be a paid ingress-controller feature.

Build, Buy, or Wait​

For a self-hosted, git-push PaaS deciding whether to offer agent sandboxes as a platform primitive, the decision reduces to three questions, not a vendor bake-off:

• Shipping a demo or an MVP this quarter? Vendor it. E2B or Daytona's SDKs get an agent running untrusted code in an afternoon, and $0.20–$0.27 per 4-hour session is not the line item that kills a startup.
• Running agent sandboxes at real tenant volume, on infrastructure you already operate? This is where the math flips. A platform running Cluster API on owned Hetzner machines is already paying for the control plane that agent-sandbox's Sandbox/SandboxWarmPool CRDs slot into — Kata Containers via RuntimeClass gets you the same VM-grade isolation E2B sells, on hardware you already own, with no per-second meter running. The tradeoff is operational: you're now the one who patches the Kata runtime and the guest kernel image.
• Need native GPU scheduling for agent workloads? None of the container-first options (Daytona, Modal) hand you that for free either — Modal built a whole serverless GPU platform to make it work. A Kubernetes-native platform gets there through Dynamic Resource Allocation and the same GPU-Operator tooling it needs for tenant inference workloads generally, not a sandbox-specific bolt-on.

Bex.co is built on Cluster API and owned Hetzner machines rather than a third-party control plane — which is exactly the substrate agent-sandbox's Kata/gVisor RuntimeClass support is designed to sit on top of. It doesn't manage the sandbox layer today (no non-goal claims here — that's not yet a shipped feature), but the architecture is the one this whole comparison points toward: isolation as a Kubernetes primitive on hardware you own, not a per-second line item from a fifth vendor. Star the repo on GitHub if that's the direction you're building toward too.

Sources:

• Daytona — Secure Infrastructure for Running AI-Generated Code
• Daytona Pricing
• E2B Pricing
• Modal — Best Serverless Sandboxes for AI Code Execution
• Fly — AI on Fly.io
• Kubernetes Blog — Running Agents on Kubernetes with Agent Sandbox
• kubernetes-sigs/agent-sandbox
• Agent Sandbox — Kata Containers docs
• Kata, gVisor, or Firecracker? Container Isolation Guide — Edera