Dora NodaTwo rival sandbox vendors now charge exactly the same price down to the fourth decimal — and that number still tells you almost nothing about your bill. Daytona and E2B both meter running sandboxes at $0.0504 per vCPU-hour plus $0.0162 per GiB-hour, billed per second of wall-clock time. For the typical agent build box — 2 vCPU, 4 GB of RAM — that works out to $0.1656 per hour, or about 1.4 cents for a five-minute build. Cheap enough to stop thinking about. That is precisely the trap.
A deploy-from-chat platform does not buy five-minute builds. It buys a lifecycle: an agent spins up a build sandbox, produces a preview, and that preview sits somewhere — idle, holding state — until a human looks at it or the TTL kills it. Price the build alone and renting always wins. Price the whole session shape, add the plan fee, and compare against an owned box your fleet already provisions, and the answer flips twice before you reach fleet scale. This post works the model all the way through: the parity rates, the all-in monthly table at three volumes, the preview-idle row vendors hope you skip, and the honest self-hosted math including the ops labor most comparisons wave off.
Price parity is real: $0.0504/vCPU-hour on both
Start with the headline both vendors publish. Daytona charges $0.0504 per vCPU-hour, $0.0162 per GiB-hour of memory, and $0.000108 per GiB-hour of storage (with 5 GB free), with no platform fee and $200 in free credits at signup. E2B's per-second rates normalize to the identical $0.0504/$0.0162 pair. Independent comparisons that normalize fourteen vendors to one unit land E2B, Daytona, and Blaxel on exactly $0.0828/hour for a 1 vCPU / 2 GB sandbox. The undercutters sit nearby rather than far away: Freestyle at $0.04032/vCPU-hour (20% under parity), Northflank at $0.01667/vCPU-hour with a bring-your-own-cloud story. The outlier is Modal's sandbox tier at roughly $0.0710/vCPU-hour equivalent plus $0.0240/GiB-hour — and Vercel Sandbox, which meters active CPU at $0.128/vCPU-hour on a different model entirely.
Two normalizations before the model. First, Modal prices per physical core, defined as 2 vCPU — always halve before comparing. Second, Modal bills max(requested, actual) while Daytona and E2B bill wall-clock on allocated size, so an over-provisioned Modal sandbox meters its request, not its usage. Keep those in mind; they return in the preview-idle row.
The worked cost model: build plus preview, all-in
A deploy-from-chat session has two legs, and only the first is cheap. Fix the session shape first, because every number below hangs off it:
- Build leg: one 2 vCPU / 4 GB sandbox, 5 active minutes → 5/60 × $0.1656 = $0.0138 per session.
- Preview leg: one 1 vCPU / 2 GB preview ($0.0828/hour while running), 24-hour TTL, idle policy per vendor.
- Concurrency: sessions arrive evenly; average concurrency, not peak, drives the owned-box comparison. Burst headroom is costed separately in the self-hosted section.
Now the monthly table. Rented all-in means meter plus the E2B Pro plan fee of $150/month (Daytona has no platform fee — more on that split below). Owned marginal means one Hetzner AX42 at ~$54/month plus ~$50 of marginal ops inside a Cluster API fleet the team already runs. Owned greenfield adds a full 8 hrs/month at $100/hr loader for a team standing up Firecracker orchestration from scratch.
| Sessions/mo | Rented meter | Rented all-in (+Pro fee) | Owned marginal | Owned greenfield | Delta (all-in − marginal) |
|---|---|---|---|---|---|
| 1,000 | $13.80 | $163.80 | $104 | $854 | +$59.80 |
| 10,000 | $138 | $288 | $104 | $854 | +$184 |
| 100,000 | $1,380 | $1,530 | $208 (2 boxes) | $908 | +$1,322 |
Three readings:
- 100k sessions: the meter alone ($1,380) exceeds a loaded owned fleet by 50% — renting loses by four figures monthly.
- 10k sessions: the meter looks competitive until the plan fee doubles it; owned-marginal wins by $184.
- 1k sessions: the meter is a mere $13.80 — but the $150 fee alone is eleven times the compute, flipping the low-volume verdict against E2B Pro specifically. On Daytona, which charges no platform fee, those same 1,000 sessions cost just the $13.80 meter and renting wins outright. The fee, not the rate, decides the low end.
The breakeven behind the table: $54 of bare metal divided by $0.0138 per session is 3,913 sessions a month — about 0.45 average-concurrent sandboxes. Sustain more than half a sandbox around the clock and the box beats the meter on hardware alone. With the marginal loader ($104) the line moves to ~7,500 sessions; greenfield ($854) pushes it to ~62,000. State which breakeven you mean before quoting one.
Then the row vendors hope you skip — the preview leg, priced per 24-hour preview at 1 vCPU / 2 GB:
| Vendor | Idle policy | Cost per 24-hr preview | Per 1,000 previews/mo |
|---|---|---|---|
| E2B | Pause stops the meter (~1s resume) | ≈ $0.00 | ≈ $0 |
| Daytona | Idle bills wall-clock | $1.99 | $1,987 |
| Modal | Idle bills max(requested, actual) | $2.86 | $2,856 |
A thousand week-old previews nobody closed cost nothing on E2B's pause model and roughly two thousand dollars on wall-clock billing. At any volume where previews outnumber builds — the normal shape of chat-driven development, where every attempt leaves a preview behind — the idle policy, not the $0.05 rate, is the bill.
Finally, sensitivity. One AX42 (16 threads, 64 GB) comfortably runs 8 concurrent 2 vCPU / 4 GB builds — a ceiling near 69,000 sessions a month. Cost per session on the $104 marginal box therefore depends entirely on how full you keep it: ~1.5¢ at 10% utilization (parity with the meter), ~0.5¢ at 30%, ~0.2¢ at 70%. Owned wins above roughly 10% sustained utilization on marginal cost. Below that, you are heating a box to beat a meter that only runs when you do.
What the $0.05 doesn't include
The parity rate is the compute line, not the invoice. Four add-ons move real money.
Plan fees. E2B Pro at $150/month buys the higher concurrency and the 20 GiB of free storage; Hobby carries a one-time $100 credit and 20 concurrent sandboxes with no card required. Daytona has no recurring fee and opens with $200 in credits. At low volume this single difference outweighs every per-second rate in the comparison — see the 1k-session row above.
Billing basis. Wall-clock (Daytona, E2B) versus max(requested, actual) (Modal) diverges exactly when sandboxes idle oversized. Modal's model is fairer for spiky builds that briefly burst — you pay the burst, not the reservation — and harsher for previews sized generously "just in case." Size previews tightly on Modal or pay for headroom twice: once in the request, once in the dwell.
Memory and storage lines. Memory at $0.0162/GiB-hour is nearly 40% of the 2vCPU/4GB hourly rate — RAM-heavy agent workloads (browser sandboxes, language servers) shift the effective rate well above the quoted $0.05. Storage is negligible while free tiers cover it and a rounding error after; note it once and move on.
The GPU gap. E2B offers no GPU inside sandboxes; Daytona does, and Modal spans T4 through H200 (H100 near $3.95/hour). A platform whose agents occasionally need a GPU burst either pays a second vendor or routes those sessions to Modal/Daytona while the CPU fleet lives on E2B. Either way the "single $0.05 rate" story ends at the first CUDA request.
Where cold start and persistence beat price
Per-second pricing makes every millisecond of startup a billed line item, and agents create and destroy machines constantly — startup latency is a per-turn tax. Daytona claims ~90ms cold starts, E2B ~150ms, Modal sub-second. Treat all three as sequential marketing numbers: one independent August 2026 benchmark that launched sandboxes concurrently — the way real agent fleets do — measured Daytona at 0.27s median with only a 37% success rate at that concurrency, Modal at 0.88s, and E2B at 1.61s, noting explicitly that vendor claims are not comparable to each other. Before signing a vendor for latency reasons, reproduce the concurrent launch test against your own session shape; the ranking under load may not match the pricing page.
Persistence is the sharper differentiator because it changes architecture, not just latency. E2B's pause()/resume() is first-class: filesystem, memory, and processes snapshot, billing stops, resume lands in about a second. That is what makes the $0 preview-idle row possible — and it enables agent workflows (multi-turn tasks with human approval gaps, overnight batch runs) that wall-clock vendors force you to either keep warm or rebuild. Modal's snapshot story covers restart, not billed-pause; Daytona persists state but keeps metering an idle running box. If your sessions have think-time in the middle, pause/resume is worth more than any per-hour discount.
Isolation sits underneath both. E2B and Daytona run Firecracker microVMs — a dedicated kernel per sandbox, the strongest hardware-level boundary in the category. Modal runs gVisor, a userspace-kernel sandbox: lighter and faster to start, with a larger shared-kernel attack surface. For executing untrusted model-generated code at fleet scale, the microVM boundary is the conservative default; gVisor is acceptable when you control the workload and value its GPU breadth. And one governance note that belongs in any 2026 comparison: Daytona went closed-source in June 2026, archiving its open-source repo, while E2B remains open-source with a self-host/BYOC path. If your roadmap ends at "run this on our own fleet," only one of the parity pair lets you take the software with you.
The self-hosted math, honestly
The owned column of the table deserves its own audit, because "a $54 box beats the cloud" posts have a habit of pricing the metal and forgetting everything else.
The packing math first. A Hetzner AX42 — Ryzen 8-core/16-thread, 64 GB ECC DDR5, 2× NVMe, unmetered traffic — lists around €46–55/month after the June 2026 dedicated-price adjustment; call it $54. Eight concurrent 2vCPU/4GB sandboxes consume all 16 threads at 1:1 and 32 of 64 GB RAM — comfortable, with headroom for the host, a Firecracker orchestrator, and a warm pool. Effective hardware cost at full packing is under half a cent per vCPU-hour, roughly two orders of magnitude under the $0.0504 meter. That ratio is real. It is also the most flattering number in this post, because it assumes 100% packing, zero ops, and no bursts.
Now the counter-case, itemized rather than waved off. Ops labor is the honest loader: Firecracker orchestration (pooling, snapshotting, placement, noisy-neighbor isolation), image builds, CVE patching of host and guest kernels, and on-call for the fleet. Inside a Cluster API fleet the team already operates, the marginal cost is small — the machines, monitoring, and upgrade runbooks exist. Greenfield, budget the 8 hrs/month from the table; at US contracting rates that loader alone exceeds the rented meter until ~62,000 sessions. Burst headroom is the second tax: the rented meter absorbs a 10x spike for the price of the spike, while the owned fleet either over-provisions (paying idle) or queues (paying latency). Size owned for the base and burst to rented — the conclusion's decision rule — rather than pretending peaks don't exist. Utilization discipline is the third: the sensitivity math cuts both ways, and a box averaging 5% utilization is the most expensive sandbox vendor in this post.
When renting wins, stated plainly: spiky or low-volume workloads under ~7,500 sessions a month on marginal cost; teams with no existing fleet or ops bench; GPU bursts (Modal's H100s beat buying accelerators for occasional inference); and previews with long TTLs on E2B's pause model, where the idle row reads $0 and no owned box can undercut free.
Rent the spikes, own the base
The parity headline — two vendors at $0.0504 — is the least important number in this comparison. What decides the bill is the session shape (build plus preview dwell), the plan fee at low volume, the idle policy at high preview counts, and whether your team already operates the fleet the owned column assumes. Work those four and the decision writes itself: E2B's pause model for preview-heavy flows, Daytona's fee-free meter for lean build volume, Modal for GPU bursts, and owned Hetzner capacity under a Cluster API fleet for the sustained base once average concurrency clears half a sandbox.
That last line is the one a deploy-from-chat platform should linger on. The sandbox meter is rent on somebody else's orchestrator; the moment your base load is predictable, the same Firecracker isolation runs on machines you own, behind your own pause policies, with no per-second meter attached.
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 run your first deploy-from-chat session on your own fleet today.
