Dora NodaE2B and Daytona now charge exactly the same price for an AI agent sandbox: $0.0504 per vCPU-hour plus $0.0162 per GiB-hour, billed per second. A typical agent run — 2 vCPU, 4 GiB of RAM, alive for ten minutes — costs about $0.028 on either platform. Modal looks 3x more expensive on the rate sheet, and per executed run it lands around $0.040 for the same shape. That is the whole pricing story in one paragraph, and it is also almost none of the buying decision.
Here is the verdict table this post will defend, for one 2-vCPU / 4-GiB / 10-minute-alive sandbox run:
| Platform | Per-run cost | What you are billed for |
|---|---|---|
| E2B | ~$0.028 | Whole alive window, per second |
| Daytona | ~$0.028 | Whole alive window, per second |
| Modal Sandbox | ~$0.040 | Provisioned resources while running; nothing while idle |
| Self-hosted slice of a fleet you already run | ~$0 marginal | Capacity you already pay for |
The rate sheet converged. Everything around the rate sheet — what counts as a billable second, how fast a sandbox starts, how strong the isolation is, whether you can take the whole stack home — diverged. This post normalizes all three vendors to one comparable run, totals a realistic month, and then prices the alternative the TODO item actually asks about: scheduling the same short-lived, isolated workloads as pods on a Cluster-API fleet you already operate.
The rate sheet, normalized to one unit
Every vendor publishes different units, so normalize first. The comparable unit is 1 vCPU with 2 GiB for one hour, plus the billing rule that decides which seconds count.
E2B. CPU at $0.000014 per vCPU-second ($0.0504/vCPU-hr), RAM at $0.0000045 per GiB-second ($0.0162/GiB-hr), billed per second for the entire time the sandbox is alive — not just while code executes. The Hobby tier carries a one-time $100 credit; the Pro tier adds a $150/month subscription on top of usage. Isolation is Firecracker microVMs with a dedicated kernel per sandbox, and cold start is roughly 150 ms.
Daytona. Identical compute rates: $0.0504/vCPU-hr plus $0.0162/GiB-hr, per-second wall-clock billing while the sandbox lives, plus a small storage charge ($0.000108/GiB-hr). Pricing starts with $200 in free credits and no mandatory plan fee. Cold start leads the category at sub-90 ms from a warm pool. The headline caveat is isolation: Daytona defaults to plain Docker containers on a shared kernel, with Kata Containers, gVisor, or Sysbox available as options — a weaker default boundary than E2B's always-on microVM.
Modal Sandbox. This is where the "3x" number needs care, because there are two different 3x claims and only one of them matters. Modal bills sandboxes at $0.00003942 per physical-core-second plus $0.00000667 per GiB-second — exactly 3x its own standard Functions rates ($0.0000131 and $0.00000222), because sandbox isolation is metered separately from regular serverless execution. But a billed Modal core equals 2 vCPUs, so the vCPU-equivalent rate is about $0.071/vCPU-hr: roughly 1.4x E2B/Daytona per unit of CPU, not 3x. The genuinely different part is the billing rule: Modal meters max(requested, actual) per second while the sandbox runs and charges zero while it sits idle. GPU rates carry no sandbox multiplier at all — an A100 40 GB inside a sandbox is still $2.10/hour — which makes Modal the only vendor of the three with first-class GPU sandboxes.
One independent normalization is worth citing: a 2026 landscape analysis that reduced fourteen sandbox vendors to a single 1-vCPU/2-GB/730-hour unit found E2B, Daytona, and Blaxel landing on exactly $0.0828/hour — parity confirmed by a third party, down to the fourth decimal.
A worked month: 200 agent runs a day
Rates per second mean nothing until they meet a workload. Take a typical coding-agent shape: 2 vCPU, 4 GiB, sandbox alive ten minutes per task (clone, install, run tests, report back). The per-run math:
- E2B/Daytona: CPU 2 × $0.000014 × 600 s = $0.0168; RAM 4 × $0.0000045 × 600 s = $0.0108. Total $0.0276 per run.
- Modal: CPU 1 core × $0.00003942 × 600 s = $0.0237; memory 4 × $0.00000667 × 600 s = $0.0160. Total $0.0397 per run.
At 200 runs a day for 30 days (6,000 runs), usage totals ~$166/month on E2B/Daytona and ~$238/month on Modal. E2B's $150/month Pro fee roughly doubles its bill to ~$316/month at this volume — the plan fee, not the per-second rate, is the largest line item on the invoice, which is exactly the kind of thing a rate-sheet comparison hides.
Now the self-hosted side, computed honestly. 200 ten-minute runs a day is 2,000 sandbox-minutes daily — an average concurrency of about 1.4 sandboxes, or ~2.8 vCPU and ~5.6 GiB sustained. A single 8-vCPU/16-GB cloud box (about $19/month on Hetzner) absorbs the average with room for 3–4x peaks. And that is the expensive framing: the TODO item asks about a Cluster-API fleet the platform already operates, where sandbox workloads land on nodes that exist anyway and the marginal cost is ~$0 plus the engineering to build it. Breakeven against vendor usage rates sits near two dozen runs a day — above that, fixed capacity wins on dollars alone.
Sensitivity matters more than the point estimate, so here it is across run length (per-run cost on E2B/Daytona parity pricing):
| Run shape (2 vCPU / 4 GiB) | Per run | 200/day × 30 days |
|---|---|---|
| 2-minute quick exec | ~$0.006 | ~$33 |
| 10-minute agent task | ~$0.028 | ~$166 |
| 30-minute long session | ~$0.083 | ~$497 |
Short, dense executions are nearly free on any vendor; long-lived sessions are where the bill compounds — and where the billing-rule difference starts to bite.
The fine print that moves the decision
Alive vs. active. E2B and Daytona meter wall-clock: a sandbox that sits alive-but-idle for eight of its ten minutes (waiting on LLM tokens, a human approval, a slow test suite) bills all ten. Modal meters provisioned resources while running and nothing while idle, so that same 10-minutes-alive / 2-minutes-active session costs E2B/Daytona the full ~$0.028 and Modal something closer to $0.01–0.02 depending on the requested shape. For agents that think longer than they compute — which is most of them — the billing rule outweighs the rate.
Cold start. Daytona ~90 ms, E2B ~150 ms, Modal sub-second. This decides architecture, not just latency budgets: at 90 ms you can spawn a fresh sandbox per tool call; at multi-second starts you must pool and reuse, which reintroduces state-leakage hygiene between tasks. Anyone building on owned infrastructure should know the target is reachable — E2B's own trick is resuming pre-booted snapshots, a pattern Firecracker snapshot-resume reproduces at ~100–150 ms on your own nodes.
Isolation strength. E2B gives every sandbox its own kernel via Firecracker, always. Daytona gives shared-kernel Docker by default and charges the complexity cost of opting into Kata or gVisor. Modal sits between with gVisor. If sandboxes execute untrusted model-generated code — the actual threat model — "Docker by default" deserves a harder look than the price parity suggests.
GPUs. Only Modal offers them inside sandboxes today, from T4s to B200s with no sandbox multiplier. If the roadmap item includes GPU-backed agent sandboxes (inference, eval harnesses), there is no three-way race; there is Modal versus building it.
Can you take it home? E2B's infrastructure is Apache-2.0 open source — genuinely self-hostable, but only on GCP (full support) or AWS (beta), as a Nomad-plus-Consul-plus-Terraform stack requiring nested virtualization. That is a second platform to operate, not a Helm chart. Daytona, meanwhile, closed its open-source core in June 2026 and archived the repository. Buying Daytona is buying a vendor API with no self-host exit; buying E2B at least preserves one, at the price of running E2B's ops model rather than your own.
The build path on a fleet you already run
The alternative is not "buy a sandbox vendor or buy servers." For a PaaS already operating a Cluster-API fleet, the alternative is scheduling short-lived, isolated workloads on capacity that exists anyway. The primitives are all upstream: Kata Containers or gVisor for the isolation boundary, Firecracker or Cloud Hypervisor where a real microVM is warranted, snapshot-resume for the cold-start target, per-task namespaces plus network policy for the blast radius. None of this is exotic — it is the same stack the vendors assembled, minus their control plane.
The honest cost is engineering, not hardware: sandbox lifecycle APIs, template snapshotting, idle reaping, and the security review of running tenant-adjacent untrusted code on shared nodes. A reasonable rule of thumb falls out of the numbers above: buy while volume is spiky and low (tens of runs a day), while you need GPUs today, or while the team has no sandbox-shaped expertise — build once steady-state volume passes breakeven and the fleet already has spare headroom, because at that point the vendor is reselling you your own utilization curve at a 5–15x markup over raw capacity.
Parity on the rate sheet, divergence everywhere else
E2B and Daytona reaching identical per-second rates is real, verified, and worth knowing — it means the vendor decision is no longer about price per vCPU-second. It is about which seconds get billed, how fast sandboxes start, how strong the default isolation is, whether GPUs exist, and whether an exit to self-hosting stays open. On every one of those axes the three vendors diverge sharply, and the self-hosted alternative on an existing fleet undercuts all of them past modest volume. Price the whole bill, not the rate.
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.
