One GPU Per Sandbox: What Modal's Whole-Card Bet Costs Against E2B and Daytona's CPU-First Lanes

An AI agent that writes code needs a sandbox with a CPU. An AI agent that runs its own model inference inside that sandbox needs a sandbox with a GPU — and that is a completely different machine. In 2026 the agent-sandbox field split on exactly this hardware question: Modal puts a real GPU inside the sandbox, E2B stays CPU-only, and Daytona spent the year moving from the CPU camp into an ephemeral-GPU middle lane. The price tags look comparable until you read the constraints, so here is the whole comparison up front:

The one-line reading: CPU sandbox compute has commoditized at roughly five cents per vCPU-hour on the commodity lanes, while GPU sandbox compute is a whole-card product billed at dollars per GPU-hour no matter how little of the card your agent actually uses. Everything below is about why that gap exists and which lane a workload — or a platform roadmap — belongs in.

Why a GPU in a sandbox is a different isolation problem​

CPU isolation for agent sandboxes is a solved menu. Firecracker gives you a 125–150ms microVM with its own kernel; gVisor gives you a userspace kernel with millisecond-scale startup; Kata Containers wraps the OCI boundary in a lightweight VM. All three keep one tenant's processes away from another tenant's processes, and all three bill by the vCPU-second because a CPU is divisible: the scheduler can hand out fractions of a core and meter exactly what was consumed.

A GPU is not divisible that way, and the two most popular sandbox substrates cannot pass one through at all. Firecracker's minimal device model exposes five emulated virtio devices and no PCI bus — no PCI bus means no PCIe passthrough, full stop. Northflank's Firecracker explainer states it plainly: for GPU workloads, use QEMU or Cloud Hypervisor instead. gVisor has the same ceiling from the opposite direction: its Sentry process emulates syscalls in userspace and has no path to hand a tenant a /dev/nvidia0 it can actually drive, which is why fleet operators who enable gVisor fleet-wide explicitly exempt GPU services from it.

So a provider that wants GPUs inside sandboxes has exactly one honest architecture: whole-device assignment. One physical card goes to one sandbox for the whole session, mediated by VFIO/QEMU passthrough or a dedicated GPU-enabled runner — never shared, never fractional. That single fact explains every constraint in the table above: why Modal's GPU menu reads like a cloud GPU price list (T4 at ~$0.59/hr up to B200 at ~$6.25/hr base rates), why Daytona's GPU sandboxes are required to be ephemeral, and why nobody offers a burstable fractional sandbox GPU. The security boundary for a shared CPU is the hypervisor or the syscall filter; the security boundary for a GPU is sole tenancy of the card.

There is a provider-side cost hiding behind that boundary: bin-packing. A single CPU host can timeslice hundreds of short-lived sandboxes, so idle seconds get recycled across tenants and per-second billing still leaves margin. A 4×H100 host serves at most four concurrent GPU sandboxes — Daytona's own runner logic rejects the fifth request outright — so every idle minute of an assigned card is capacity the provider bought and cannot resell. That is why GPU sandboxes are ephemeral-only everywhere they exist: the provider cannot afford to let a whole accelerator sit attached to a paused session the way E2B can let a Firecracker microVM sit stopped. Whole-card assignment pushes the utilization risk onto whoever holds the session, which is the tenant, which is the invoice.

The three lanes in numbers​

Take a typical code-gen agent workload first: one million short sessions, each holding 2 vCPUs for 30 seconds. That is 60 million vCPU-seconds, or about 16,667 vCPU-hours. On E2B or Daytona at $0.0504/vCPU-hr the compute comes to roughly $840; on Modal's sandbox tier at ~$0.071/vCPU-hr it is roughly $1,180. A ~40% premium for Modal's sandbox CPU — noticeable, but the same order of magnitude, and exactly the kind of gap where cold-start times, snapshot support, and SDK ergonomics can legitimately decide.

Now give the agent a GPU. One thousand inference sessions, each holding an H100 for five minutes: about 83 GPU-hours at ~$3.95/hr, or roughly $330 on either Modal or Daytona. Here is the sensitivity that matters, and it has nothing to do with which vendor you pick: because the card is assigned whole, you pay for the whole five minutes whether the GPU is busy for four of them or for thirty seconds. An agent whose GPU is busy 80% of its session pays an effective ~$4.94 per busy GPU-hour; an agent whose GPU is busy 10% of its session — compile, think, emit tokens, repeat — pays an effective ~$39.50 per busy GPU-hour for the same card. An 8× swing from workload shape alone, invisible in every per-hour price on every pricing page.

That is the breakeven reading the CPU comparison cannot give you. When the workload needs a GPU, CPU price parity is irrelevant: E2B's five-cent vCPU cannot substitute for a card it does not have, and Modal's 3× sandbox CPU multiplier stops mattering the moment the H100 line dominates the invoice. The question is never "which sandbox is cheapest" — it is "does this agent's session need a device, and if so, how busy will that device be?"

What changed in 2026: Daytona left the CPU-only camp​

The older telling of this split — Modal has GPUs, Daytona and E2B structurally cannot — is now half out of date, and the correction matters more than the original claim. Daytona shipped an NVIDIA GPU-enabled runner in release v0.174.0: sandboxes can request NVIDIA GPU devices for inference, fine-tuning, and CUDA work, with sizes up to 16 vCPUs and 192GB RAM alongside the card. But note what did not change: GPU sandboxes must be ephemeral, snapshots of GPU machines need GPU-ready images, and multi-GPU hosts assign exactly one physical card per sandbox — a fifth GPU request against a 4×H100 host is rejected, not queued behind a fractional share.

In other words, Daytona did not solve GPU sharing; it adopted the whole-card model with its constraints intact. The "structurally blocked" framing moved from "no GPU" to "GPU without persistence, without snapshots-as-usual, without packing." E2B, meanwhile, remains genuinely CPU-only: Firecracker's device model has not grown a PCI bus, and the company's roadmap bets on density and sub-200ms boots for code execution rather than device passthrough. So the field is now two whole-card GPU vendors with different heritages (Modal GPU-native, Daytona CPU-first with an ephemeral GPU tier) and one pure CPU lane — not the clean 1-vs-2 split the 2025 discourse assumed.

Pick a lane before your tenants' agents assume one for you​

This is the question the TODO behind this post actually asked: a self-hosted platform with roadmapped E2B-style sandboxes has to choose — CPU-only and cheaper to isolate, or GPU-capable and inheriting Modal's harder boundary problem. The 2026 evidence suggests the choice is not either/or but sequenced, with a hard rule at each step.

Ship the CPU-only lane first. Firecracker or Kata gives you the strongest multi-tenant story (a real hypervisor boundary, per-second metering at commodity rates, sub-200ms boots) for exactly the workload agents generate most: short, bursty, CPU-bound tool calls. Nothing about this lane needs a GPU exception in your admission policy, and the whole-card economics above say most agent sessions would waste a card anyway.

Add GPUs as a separate, explicitly ephemeral, whole-card tier — Daytona's shape, not a fractional vGPU demo. One card, one tenant, no snapshots carried across trust boundaries, and scheduling that rejects rather than overcommits when the cards run out. The trust boundary section of the CNCF's August 2026 AI-factory guidance draws the same line: density within one trust domain is a scheduling problem, but untrusted tenants sharing one card is a boundary problem, and the only production answer anyone has shipped is sole tenancy.

And never let a workload silently assume GPU presence. The failure mode this split creates is an agent built against Modal's GPU-ful sandbox being pointed at a CPU-only lane and failing at 2 a.m. inside generated code that calls torch.cuda.is_available() and gets False. Capability advertisement — a sandbox descriptor that says gpu: none versus gpu: h100-ephemeral — is the cheapest line item on this whole roadmap and the one that prevents the most confusing pages.

The device is the bill​

Sandbox pricing converged on the CPU side and never will on the GPU side, because the products are physically different things: metered fractions of a shared processor versus sole tenancy of a whole accelerator. Modal charges the 3× sandbox multiplier because its sandbox is a heavier product; Daytona matches E2B's five-cent CPU because Firecracker-derived density is a commodity; and every GPU sandbox from every vendor costs ~$4/hr for an H100 because there is exactly one way to isolate it. Plan the lane around the device, measure the busy fraction before you complain about the rate, and the invoice stops being a surprise.

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.