E2B Serves 88% of the Fortune 100. What Breaks at That Scale Is Idle Billing and Resume Latency

E2B counts 88% of the Fortune 100 as sandbox users. Perplexity, Hugging Face, Manus, and Groq run agentic workflows on its Firecracker microVMs, and the company raised a $21M Series A on exactly that traction. When nearly nine in ten of the world's largest companies have signed up for your API, your failure modes stop being edge cases — every rare behavior fires daily somewhere, and the complaints that surface describe what the product looks like at true production scale.

Those complaints have a shape, and it is not the one the category spent 2025 arguing about. Boot time was last year's war: E2B's ~150ms starts versus Daytona's sub-90ms warm pool versus Modal's ~100ms. That war is over and the customer won — boots are fast everywhere.

What field reports from 2026 keep circling instead is what happens between the boots: a coding-agent session that holds a sandbox open for thirty minutes, fires forty tool calls, and spends two-thirds of its wall-clock time waiting on the model to think. The sandbox is billed for all thirty minutes. And every time the platform suspends it to stop that idle billing, the next tool call pays a resume toll. Across dozens of operations per session, the toll stacks into real seconds on the interactive path.

Here is that session, costed three ways, before we argue about any of it:

Two things to notice before the details. First, at this session's 33% duty cycle the two metered models nearly tie — the active-CPU rate is ~2.5x higher per vCPU-hour, which eats most of its structural advantage. Second, $0.054 a session sounds like nothing until you multiply: 10,000 sessions a month is ~$545, and 100,000 is ~$5,450 — roughly a dedicated build box a month, every month, for think time. That multiplication is the whole post. The assumptions are stated so you can re-run them; the sensitivity analysis follows.

The session is the bill, not the sandbox​

An agent loop is bursts of tool execution separated by model reasoning. The sandbox runs code for seconds; the model reads the output, plans, and emits the next call for much longer. E2B's meter — per-second of running sandbox at $0.000014/vCPU-second plus $0.0000045/GiB-second — cannot see that distinction. A running sandbox with an idle CPU bills identically to one compiling at full tilt. For the default 2 vCPU / 512 MiB sandbox (~$0.109/hr), our 30-minute session burns $0.054, of which $0.036 pays for a CPU doing nothing.

This is not a rounding error you can tune away with a smaller sandbox. Halve the vCPUs and the idle fraction stays two-thirds; the invoice shrinks but its composition doesn't change. The idle share is a property of the workload shape — reasoning-heavy agents are idle-heavy tenants — not of the instance size. The only variables that move it are the duty cycle and the billing model, so here is the sensitivity across duty cycles, normalized per wall-hour for the same 2 vCPU / 512 MiB sandbox:

• At 33% duty cycle (our coding session): E2B-shape $0.109/hr vs active-CPU-shape ~$0.095/hr. Near tie.
• At 5% duty cycle (a research agent that reads ten pages per tool call): E2B-shape still $0.109/hr vs active-CPU-shape ~$0.023/hr. Nearly a 5x gap.
• The breakeven sits around ~38% duty cycle: below it, metering busy CPU wins despite the higher rate; above it, flat session billing wins.

That breakeven is the honest version of this section. Active-CPU metering is not categorically cheaper — Vercel charges $0.128 per active vCPU-hour against E2B's $0.0504, plus $0.0212/GB-hour of provisioned memory and $0.60 per million sandbox creations, so a busy agent can absolutely cost more under the "fairer" meter. What active-CPU metering does is move with the workload: the invoice tracks what the agent did, not how long it thought about it. Session billing moves with the clock. For agents, the clock is mostly thinking.

The resume tax: ~3 seconds, dozens of times​

Billing stops the moment a sandbox is paused — that part of E2B's design is genuinely good. Pause captures filesystem, memory, and processes; resume takes ~1 second; pausing itself costs on the order of ~4 seconds per GiB of RAM. For our 512 MiB sandbox, a full suspend/resume cycle runs roughly 3 seconds: ~2 to snapshot, ~1 to restore. Three seconds is invisible once. It is not invisible eight times in a thirty-minute chat, and it is felt hard at twenty.

How many cycles does a session actually incur? That is set by one knob: the idle timeout. E2B's 15-minute default auto-pause is, if anything, conservative — field complaints call it too long, because a fifteen-minute tail of full-rate billing after every session end dwarfs the per-session compute. But tighten it and the resume toll arrives. Take our session's twenty think-gaps (twelve ~30s pauses, six ~90s ones, two ~5-minute reads of long outputs):

• 15-minute timeout: zero gaps trigger suspension. Idle billed in full (~$0.036), zero resume latency. The demo configuration.
• 2-minute timeout: the two 5-minute gaps suspend. ~$0.011 of idle unbilled, 2 resumes, ~6 seconds added to the interactive path.
• 60-second timeout: eight gaps suspend. ~$0.020 of idle unbilled, 8 resumes, ~24 seconds of pure resume-wait inside a thirty-minute conversation.

There is no setting of this knob that is free; there is only a choice of who pays — the invoice or the user staring at a spinner.

The knob also interacts badly with concurrency. Independent time-to-interactive benchmarks under load (ComputeSDK, August 2026) put E2B at 1.61s median / 1.81s p99 against Vercel Sandbox's 0.67s / 1.12s and Modal's 0.88s / 1.08s. Resume latency is not a constant; it degrades exactly when the fleet is busiest, which is exactly when the most sessions are deciding whether to suspend. A platform team inheriting this design should budget resume at p99, not at the vendor's ~1s happy path — community reports describe startup behavior degrading from ~100ms toward ~1s at around a hundred concurrent sandboxes.

The timeout dilemma: bill the idle or risk the state​

The aggressive end of the timeout knob has a second cost beyond latency: state. Operator runbooks in the wild document short default timeouts silently killing idle sandboxes between long session steps — an agent that spends six minutes on one hard reasoning step returns to find its filesystem, its installed packages, its half-written test file gone. The failure surfaces as a confusing infra error mid-session rather than a clean signal.

Mitigations exist (heartbeat extensions, per-trial wall-clock caps, explicit reuse-a-warm-sandbox-per-conversation patterns), but notice what they are: every tenant re-implementing session persistence that the platform evaporated to save idle billing.

The conservative end has its own cliff: duration ceilings. Sessions are capped at around 1 hour on E2B's Base tier and 24 hours on Pro. A long-running research agent, a multi-hour migration agent, a session a human leaves open over lunch — each discovers the ceiling by hitting it, and "your sandbox timed out" is the kind of error an end user cannot distinguish from "the agent broke."

Longer ceilings mostly move the idle-billing problem (a 24-hour session at 5% duty cycle is 22.8 hours of billed thinking), which is presumably why the ceilings exist — but from the tenant's side, a platform whose answer to idle cost is killing the session has turned a pricing problem into a correctness problem.

This is the specific failure mode worth naming, because it generalizes beyond any one vendor: session-scoped sandboxes couple the billing unit to the trust boundary's lifetime. The sandbox must stay alive as long as the agent needs its state, but the meter charges for aliveness, not usefulness. Every fix attempted so far — auto-pause, short timeouts, duration ceilings — preserves the coupling and merely chooses which symptom the tenant feels. Breaking the coupling, not tuning it, is the design task.

What else cracks when 88% of the Fortune 100 shows up​

The idle/resume coupling is the structural crack; volume opened several smaller ones worth listing quickly, since a self-hosted roadmap needs the full punch list:

• Single-region gravity. Managed sandbox clouds concentrate capacity; tenants outside that region eat the round trip on every one of those dozens of tool calls. Multi-region agents feel this as a per-call tax no timeout tuning fixes.
• Lifecycle bugs at volume. Hundreds of SDK and workspace-creation issues, Git-clone failures inside fresh sandboxes, tunneling rough edges — each rare per-call, each guaranteed daily at 15 million sessions a month (E2B's March 2025 volume, up 375x year over year). Volume converts flakiness into weather.
• The adoption ratchet. E2B's own site has already moved the claim from 88% to 94% of the Fortune 100. Enterprise vetting — security review, compliance sign-off, integration work — makes switching providers expensive, which means tenants absorb these behaviors rather than leave. A new entrant doesn't need to beat E2B's scale; it needs to not reproduce the behaviors captive tenants complain about.

None of this is an argument that managed sandboxes are bad value. Per-second billing with zero idle infrastructure to operate is genuinely the right trade for spiky, low-volume agent use — the demos feel great because for ten sessions a day, they are great. The argument is that the cost curves inflect with volume, and the inflection arrives earlier than teams expect: idle fractions don't shrink as you scale, they compound.

Designing it differently from day one​

A self-hosted PaaS building E2B-style sandboxes on its own fleet — declarative Kubernetes on owned hardware, the Cluster API shape — gets to break the coupling instead of tuning it. Four choices, all cheaper to make before the first tenant arrives:

1. Meter busy CPU internally, even though the hardware is flat. The fleet node's monthly cost doesn't change with duty cycle, but per-tenant accounting should still use an active-CPU-shaped meter. It tells you which tenants are 5%-duty researchers and which are 90%-duty burners, which is exactly the information needed for placement, limits, and (later) pricing. Copy Vercel's meter semantics; skip its rates.

2. Make suspend cheap enough that the timeout knob stops mattering. The resume toll is dominated by snapshot/restore of full-machine state. Keep sandbox filesystems on snapshots that restore in milliseconds (pre-warmed pools per node, snapshot-restore instead of cold boot — the standard Firecracker trick, ~5–30ms best case), separate ephemeral scratch from state worth preserving, and checkpoint agent-relevant state (files, installed packages) independently of machine memory. If resume costs tens of milliseconds, a 60-second timeout suspends freely and neither the invoice nor the user suffers. The knob disappears because both of its failure modes got cheap.

3. Never evaporate state to save money. Timeouts may freeze a session; they must not delete it without an explicit, tenant-visible lifecycle: freeze → snapshot retained with a stated retention → explicit dispose, each transition observable. The in-house rule should be that no cost optimization is allowed to produce a failure mode the tenant can't distinguish from corruption. Heartbeats and warm-reuse patterns then become optimizations, not survival mechanisms.

4. Isolate with a RuntimeClass, not a parallel fleet. VM-grade isolation doesn't require rebuilding E2B's bespoke Firecracker control plane: Kata Containers as a Kubernetes RuntimeClass puts a hypervisor boundary under ordinary pods on nodes the fleet already manages. Sandboxes schedule, autoscale, and get health-checked like every other workload, and warm-pool management becomes scheduling policy rather than a second platform to operate. (Boot-time decomposition and the Kata setup are covered in depth in this blog's earlier sandbox posts — the point here is that the isolation layer and the billing/lifecycle layer are separable decisions.)

Note what this list doesn't include: beating anyone's cold-start number. Sub-500ms boots are table stakes the whole category already clears. The tenants deciding whether to stay on a managed sandbox bill or move to a self-hosted lane will decide on idle economics and session reliability — the two things the current coupling makes worst.

The invoice is the architecture​

E2B earned its adoption: it productized the Firecracker sandbox years before most teams could have built it, and per-second session billing is simple to understand. But simplicity at the meter created complexity everywhere else — a timeout knob with no free setting, resume latency stacking across every interactive session, duration ceilings that turn pricing into correctness failures. Those aren't implementation bugs to patch; they're the predictable output of charging for aliveness while agents spend most of their lives thinking.

A platform that owns its hardware can charge itself differently: account by busy CPU, suspend so cheaply the timeout barely matters, freeze-never-evaporate, and isolate inside the orchestrator it already runs. The sandbox primitive was never the moat — Firecracker has been open source since 2018. The moat is a lifecycle whose economics match the workload. Build that, and the 88% have somewhere to go when their think-time bill arrives.

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.

Sources​

• E2B pricing and sandbox lifecycle (per-second vCPU/RAM rates, pause/resume semantics, 1h/24h ceilings): e2b.dev/pricing and E2B docs, via community research notes
• Marktechpost, Aug 2026: cold start, per-second pricing, and network policy across E2B, Daytona, Modal, Cloudflare, and Vercel (marktechpost.com)
• ComputeSDK Aug 2026 time-to-interactive benchmarks under concurrent load, via Prompt Smith AI news roundup
• Northflank 2026 sandbox comparison: E2B/Daytona $0.0504/vCPU-hr convergence, Vercel active-CPU rates (northflank.com)
• E2B $21M Series A and 88% Fortune 100 adoption: VCA Online and Unite.AI
• E2B growth 40k to 15M sandbox runs/month: Generative, Inc.
• Beam 2026 sandbox guide: Daytona pricing, warm-pool starts (beam.cloud)