E2B vs Modal vs Daytona: Idle Time, Not Cold Start, Sets the Bill

Pick E2B for agent code execution unless you have a specific reason not to. Every session gets its own Firecracker kernel, BYOC and Apache-2.0 self-hosting give you a way out, and its rate matches Daytona's exactly. Modal Sandboxes run on gVisor rather than a microVM and cost 41% more per vCPU than E2B or Daytona. Daytona is a fair choice only if untrusted code goes in its VM class, because its docs disagree about whether the default container class gets its own kernel. If your agents mostly wait on the model, billing shape matters more than rate. Vercel Sandbox, Cloudflare's containers and Fly's Sprites stop charging for CPU when nothing runs, and on a month with long idle tails that gap reaches 10x or more.

Every price below was checked on the vendor's live pricing page on October 8, 2026, converted to dollars per vCPU-hour and per GiB-hour.

	Isolation boundary	CPU, per vCPU-hour	Memory, per GiB-hour	What the meter counts	Floor	Concurrency / max session
E2B	Firecracker microVM, own guest kernel	$0.0504	$0.0162	Time the sandbox is alive	$150/mo Pro; $3,000/mo Enterprise minimum	100 on Pro (20 Hobby) / 24 h
Daytona	Container class (namespaces) by default; VM class has its own kernel	$0.0504	$0.0162	Per second, alive time	Pay as you go	Not published / not published
Modal Sandboxes	gVisor, optional VM runtime	$0.0710	$0.0240	Time the sandbox runs	$0 Starter; $250/mo Team	100 containers Starter, 5,000 Team / 24 h
Vercel Sandbox	Firecracker microVM	$0.128, active CPU only	$0.0212 per GB, provisioned	CPU when busy; memory while alive	$20/mo Pro credit	10,000 on Pro / 24 h
Cloudflare Sandbox (Containers)	Firecracker microVM, own kernel	$0.072, active CPU only	$0.009, provisioned	CPU when busy; memory until sleep	$5/mo Workers Paid	Not compared here
Fly Sprites	Not named on Fly's page	$0.0385, CPU actually used	$0.021875 per GB, memory actually used	Only while running	$100/mo Hero plan, usage allowance included	Not compared here

---

What Each Vendor Isolates, and What It Leaves Exposed

The isolation boundary decides what an exploit inside the sandbox has to break next, and the three headline vendors draw it in three different places.

E2B puts each session in its own virtual machine. Its enterprise page describes "a Firecracker microVM with its own guest kernel per session, on KVM," and states the consequence plainly: "A kernel exploit inside the sandbox still needs a Firecracker escape to reach the host." A microVM is a stripped-down virtual machine that boots in milliseconds and exposes a very small device model to the guest. The guest kernel can be compromised without the host being compromised.

Modal intercepts system calls instead. Modal's security guide says "Compute jobs at Modal are containerized and virtualized using gVisor," and its Sandbox guide adds that Sandboxes can run on gVisor or on VMs that give the Sandbox its own Linux kernel. gVisor is a user-space kernel written in Go: the application's system calls go to gVisor's Sentry rather than the host. Google's own gVisor security model is candid about the limits: "gVisor does not provide protection against hardware side channels," and "A sandbox is not a substitute for a secure architecture." That is strong isolation for most code. It is a different boundary from a hardware virtualization line, and you should know which one you bought.

Daytona's default sandbox is a container. Daytona's isolation docs list a container class, an "Isolated container with dedicated namespaces and enforced resource limits," and a VM class, a "Full virtual machine with its own kernel." The container class description does not say whether the kernel is shared, and the docs don't name a runtime for it. Daytona's sandbox overview says something stronger, that each sandbox gets "a dedicated kernel, filesystem, network stack." Both can't describe the same default. Treat the container class as a shared-kernel boundary until Daytona tells you otherwise in writing. Pause and resume, fork and hot snapshots are VM-only features per the isolation docs, which tells you Daytona considers the VM class its strong boundary too.

The other three: Cloudflare's container architecture docs say "Each container instance runs in a Firecracker microVM with its own kernel and network." Vercel's own Terminal-Bench guide says each trial runs in an isolated Firecracker microVM. Fly's Sprites page does not name its isolation runtime, so ask before you assume.

Who should NOT pick Daytona's container class: anyone running code an LLM wrote from untrusted input. Use the VM class or another vendor.

---

The Rates, Normalised to One Unit

On rate alone, E2B and Daytona tie and Modal Sandboxes are the most expensive of the full-duration meters.

• E2B publishes $0.000014 per vCPU-second and $0.0000045 per GiB-second, the same on every plan. That is $0.0504 per vCPU-hour and $0.0162 per GiB-hour. Storage is free.
• Daytona publishes $0.0504 per vCPU-hour and $0.0162 per GiB-hour, with storage at $0.000108 per GiB-hour after the first 5 GiB, billed per second. The match with E2B is exact.
• Modal charges Sandboxes $0.00003942 per core-second and $0.00000667 per GiB-second, against $0.0000131 per core-second for standard Functions: 3.0x its own regular compute rate. Modal's core is a physical core, which the pricing page defines as 2 vCPUs, so the like-for-like figure is $0.0710 per vCPU-hour and $0.0240 per GiB-hour.
• Vercel charges $0.128 per Active CPU hour and $0.0212 per GB-hour of provisioned memory on Pro, in the default iad1 region. The higher CPU rate buys a different meter: "Time spent waiting for I/O (such as network requests, database queries, or AI model calls) does not count toward Active CPU."
• Cloudflare charges $0.000020 per vCPU-second and $0.0000025 per GiB-second beyond the Workers Paid allowance, and "CPU usage is based on active usage only." Memory is billed on the provisioned instance type, and charges stop once the container sleeps.
• Fly bills Sprites $0.0385 per CPU-hour and $0.021875 per GB-hour, measured on CPU and memory actually used, and states that "warm and cold Sprites are not billed for compute."

A per-second rate is the number vendors put in comparison tables because it is easy to compare. It predicts your invoice only if your sandboxes are busy for the whole time they are alive, and agent sandboxes almost never are.

---

Billing Shape Beats Rate: Two Months, Same Work

The billing shape is what the meter counts, and on an agent workload it moves the bill more than the rate does. To show it, here is one workload priced two ways.

The workload: 50,000 agent sessions a month, each in a 2 vCPU, 4 GiB sandbox. The CPU is busy 10% of the time the sandbox is alive; the rest is the agent waiting on model calls. That 10% figure is the same assumption Vercel uses in its own worked examples. Month A: each sandbox is killed when its 10-minute session ends. Month B: the same sessions, but each sandbox lingers for 60 minutes because nobody set a timeout or the user walked away mid-chat. The CPU work done is identical in both months.

Monthly cost, usage plus plan floor	Month A: 10 min alive	Month B: 60 min alive
E2B Pro	$1,530	$8,430
Daytona	$1,380	$8,280
Modal Sandboxes (Starter)	$1,953	$11,868
Vercel Sandbox Pro	$900	$4,433
Cloudflare Containers (6 GiB, its minimum for 2 vCPU)	$574	$2,824
Fly Sprites, if the Sprite sleeps in the idle tail	about $742	about $742

Cloudflare's custom instance types require at least 3 GiB of memory per vCPU, per its limits page, so its line is priced at 6 GiB. First, in Month A the full-duration vendors cost 1.5x to 3.4x what the active-CPU vendors cost for the same work. Modal is the most expensive line in both months. Second, Month B multiplies every full-duration usage bill by about 6x, while Fly's stays flat if its Sprites actually sleep through the idle tail. The gap between Modal and Fly becomes 16x. Fly's figure assumes all 4 GiB is in use while awake; it bills actual memory, so a lighter sandbox costs less. Third, Month B also breaks E2B's concurrency cap. Average concurrency is about 69 sandboxes, so ordinary peaks blow through Pro's limit of 100 and push you to Pro+ at $650 a month for 600.

The lever is yours on every vendor. E2B's persistence docs let you set the lifecycle so a sandbox pauses instead of dying on timeout, and a paused sandbox "is kept indefinitely" with memory and filesystem intact. The same page does not say whether a paused sandbox accrues compute charges, so get that in writing before you design around it. Modal's idle_timeout terminates a Sandbox after inactivity, per its Sandbox guide. Set it.

Before you pick, take the alive-to-busy ratio from your own traces. At this sandbox size, Vercel beats E2B whenever the CPU is busy less than about a third of the time the sandbox is alive. If your sandboxes compile, test and exit, the flat rate wins and E2B or Daytona is cheaper than Vercel.

Why the Cheapest Line Is Not the Verdict

Cloudflare is the cheapest line in Month A and second only to a sleeping Fly Sprite in Month B, and it still isn't the default recommendation, because the price assumes you work the way its platform does. A Cloudflare sandbox is a container behind a Durable Object and a Worker, so you adopt that programming model to get the rate. The Container class defaults sleepAfter to 10 minutes, per the architecture docs, so unless you stop the container yourself, every session bills memory for 10 minutes after it ends. In Month A that would roughly double the memory line. Disk is ephemeral by default, and a container that sleeps starts next time on a fresh disk unless you use snapshots.

Fly's Sprites have the friendliest meter on the list, but the Sprites page does not name the isolation runtime, which is not enough for a security review. Vercel is a strong pick for a team already on Vercel. For anyone else it means a second platform account to govern just to run sandboxes.

Who should NOT pick Cloudflare: a team that does not already build on Workers. Who should NOT pick Fly Sprites: a team whose security review needs the isolation runtime in writing before purchase.

---

The Floors and Caps Nobody Puts in the Table

The plan floors and concurrency caps decide whether a vendor fits at all, before price comes up.

E2B's pricing page lists the Hobby tier at 20 concurrent sandboxes and a 1-hour session limit, Pro at $150 a month plus usage with 100 concurrent and 24-hour sessions, and Enterprise as custom pricing with a $3,000 monthly minimum. BYOC, where the data plane runs in your cloud account, is Enterprise-only and quoted by sales. The enterprise page adds that committed-use pricing needs a one-year minimum commit, and lists a SOC 2 Type II report and a HIPAA BAA on request.

Modal's pricing puts Starter at $0 with $30 of monthly credit and 100 containers, and Team at $250 a month with $100 of credit and 5,000 containers. Sandboxes default to a 5-minute lifetime and accept a timeout up to 24 hours.

Daytona's pricing page gives $200 of free compute and puts SSO, audit logs and BYOC behind an Enterprise sales conversation, with no published floor. It does not say how stopped sandboxes are billed.

Vercel's quotas are the most generous of the group: 10,000 concurrent sandboxes on Pro, 24-hour sessions, but a cap of 8 vCPUs and 16 GB per sandbox on Pro and 32 vCPUs only on Enterprise.

Who should NOT pick E2B: a team that needs a VPC data plane but cannot commit $36,000 a year, since BYOC sits behind the Enterprise minimum. Who should NOT pick Vercel Sandbox: a team not already on Vercel, or one that needs more than 8 vCPUs per sandbox without an Enterprise contract.

---

Where Egress Is Open by Default, and Where It Is Enforced

Most of these sandboxes can reach the open internet the moment they start, and that default is the setting you change first.

• E2B: "Every sandbox has outbound access to the internet by default," per its internet access docs. You can deny all with allowInternetAccess: false, or set allowOut and denyOut lists by IP, CIDR or domain; allow rules win. Enforcement sits on E2B's side, and the docs warn that "The firewall has to accept the connection first before it can decide whether the destination is allowed," so a blocked TCP connection can look successful from inside. Test your allowlist with a real application-level request, not a port check.
• Modal: "By default, Sandboxes can make outbound connections to any public IP address," per its networking guide. block_network=True drops everything; outbound_cidr_allowlist and a beta outbound_domain_allowlist (TLS on port 443 only) narrow it. Inbound is blocked, and Sandboxes can't reach other Modal resources by default.
• Daytona: the network limits page splits by account tier. On Tiers 1 and 2, "Network access is restricted and cannot be overridden at the sandbox level." On Tiers 3 and 4, "Full internet access is available by default," and networkAllowList, domainAllowList or networkBlockAll replace that default.

Reaching your own VPC is a separate purchase. Modal's networking guide only covers public IPs. E2B's BYOC runs the data plane in your account, where "Sandbox traffic goes from the client to the VPC," and Daytona lists BYOC under Enterprise. Either way, treat private reachability as a firewall change with its own security review.

---

Building It on the Kubernetes You Already Run

Building your own is a real option now, and the cost is a list of operational jobs you take on that the vendors currently do for you.

Google's GKE Agent Sandbox runs on the open-source kubernetes-sigs/agent-sandbox controller. It uses gVisor, keeps a SandboxWarmPool of pre-warmed pods for sub-second claims, integrates Pod snapshots for pause and resume, and starts from a "Default Deny" network posture. It also works with Kata Containers, but Google does not support Kata, so that path is yours to run. E2B offers a middle route: its single-node Embed distribution is Apache-2.0 and "Requires Linux x86-64 with KVM," per the enterprise page.

What you take on:

1. Snapshot hygiene. Firecracker's own guidance on clones warns that every clone "resumes precisely from the previously saved state," including RNG state, and recommends reseeding after each restore and deleting saved seeds before snapshotting. A warm pool restored from one snapshot without that step hands identical randomness to every session.
2. A warm pool keyed by environment. A practitioner writeup on warm sandbox pools makes the point that the useful snapshot holds the repo's installed dependencies, so the pool becomes a cache keyed by lockfile with its own invalidation problem.
3. A reaper that doesn't kill working agents. The same writeup notes that "Naive CPU-based idle timeouts kill sandboxes mid-thought," because an agent waiting on the model looks idle. Suspend first, kill later.
4. Patching the boundary. You own the host kernel, KVM or gVisor upgrades and the CVE response for them.

Build it if you already run a platform team on Kubernetes, you need default-deny egress into a VPC, and you have more than a few hundred concurrent sandboxes. Don't if sandbox infrastructure would be one engineer's side job.

---

What No Sandbox Contains

A sandbox contains the code it runs, and every vendor here leaves the credentials you hand it and the data it sends out to you.

An agent that runs inside a perfect microVM with a broad cloud token can still delete production, because the token works from anywhere. An agent with an open egress default can still post your repo to a paste site. Our coverage of an eval sandbox that gave up its API keys and of OpenAI's DNS-based escape both came down to credentials and egress, and neither needed a hypervisor escape.

So the buying checklist has three items the vendor won't fill in: a token scoped to the one task and expiring with the session, an outbound allowlist you have tested from inside the sandbox, and an audit trail of every command and network connection kept outside the sandbox. If you can't produce all three, a stronger kernel boundary won't fix that.

---

The Decision: What Predicts Regret

Four questions predict whether you will regret this purchase within a year, in this order.

1. Will untrusted input ever shape the code? If yes, require a per-session kernel: E2B, Vercel, Cloudflare, or Daytona's VM class. That rules out Daytona's container class, and makes Modal's gVisor acceptable only if you are already on Modal.
2. What is your alive-to-busy ratio? If the CPU is busy more than about a third of the alive time, E2B and Daytona beat Vercel. Below that, the active-CPU meters win.
3. Do you need a VPC data plane or an exit? E2B has BYOC and an Apache-2.0 self-host build. That is the strongest exit path on the list, and it matters after Baseten bought Blaxel with no end date on its continuity pledge.
4. What is your peak concurrency? E2B Pro stops at 100. Vercel Pro allows 10,000.

What changes the answer: if your agents already run on Modal for GPU inference, keep the sandboxes there and pay the premium for one bill and one security review. If you are on Vercel and your sessions are mostly waiting, Vercel Sandbox is the cheapest Firecracker option you can switch on this week.

This Week:

1. Pull a week of sandbox traces and compute alive time against CPU-busy time per session.
2. Set an explicit timeout and idle timeout on every sandbox you create today. The vendor defaults won't protect your bill.
3. Turn outbound internet off by default and allowlist what each task needs, then test the list with a real request from inside the sandbox.

This Month:

1. Price your own traces on two meters, one full-duration (E2B) and one active-CPU (Vercel or Cloudflare), with the plan floor included.
2. Get written answers from your shortlist on paused-sandbox billing, BYOC pricing and the isolation runtime of the default sandbox class.

Before Q1 Close:

1. Replace any long-lived cloud credential passed into a sandbox with a per-session token, and log every command outside the sandbox.

The Bottom Line

This market repeats the early serverless pricing fight: vendors quote the per-second rate because it is easy to compare, and the bill is decided by how long things sit idle. E2B is the default for an enterprise platform team because the boundary is a real kernel, the egress controls exist, and there is a way out. Modal Sandboxes cost the most per vCPU of the full-duration meters and offer a weaker boundary than a microVM, so pick them only if Modal is already your compute platform.

Price your own traces before you sign anything.

Continue Reading

• OpenAI's Agent Kill Switch Failed for 2.5 Hours After a DNS Escape
• Baseten Buys Blaxel, Whose 'Keeps Running' Pledge Has No End Date
• AWS Agents Run 14 Days. The Session Is the Only Wall.
• An Eval Sandbox Gave Up Its Keys. Your Gateway Holds Yours.
• Cursor Refused. The Next Chat Didn't. Scope the Creds.
• Microsoft's MXC Agent Containers Ship Before Intune Can Manage Them