E2B Runs 88% of the Fortune 100's Agent Workloads: What 150ms Firecracker Sandboxes Set as the Bar

Eighty-eight percent of the Fortune 100 now run frontier agent workloads through one company's sandboxes. That company, E2B, sells isolated Linux environments that boot in about 150 milliseconds and bill by the second. It raised a USD 21 million Series A in July 2025, counts Perplexity, Hugging Face, Manus, and Groq as customers, and has become the default answer to "where does my AI agent run code?" — to the point that "E2B-style sandboxes" is now a roadmap line item for platforms that have never shipped a sandbox at all.

This post decomposes that line item into something buildable. The table below is the bar, stated as numbers. Everything after it explains what each number costs to reproduce — and where E2B's model assumes a hosted control plane a self-hosted fleet has to run itself.

The bar, stated as numbers​

A reader who only takes one paragraph from this post should take this one: "E2B-style" means Firecracker microVM isolation instead of shared container namespaces, snapshot-resume boot instead of cold boot, per-second metering instead of per-minute, a template system so an agent requests a known-good runtime instead of building one on demand, and a lifecycle API with first-class pause and resume. Miss any one of those five and you have a code runner, not an agent sandbox.

What E2B actually is​

E2B, founded in 2023 in Prague by Vasek Mlejnsky and Tomas Valenta, builds cloud infrastructure for AI agents: sandboxes where agents execute code, browse, and use tools without touching the operator's own machines. The USD 21 million Series A led by Insight Partners in July 2025 brought total funding past USD 32 million, with the company reporting seven-figure revenue and describing its goal, without much modesty, as "the next hyperscaler for AI agents."

The architecture is a textbook two-plane design. The data plane is Firecracker microVMs — the same KVM-based virtualization primitive AWS built Lambda on — each sandbox getting its own Linux kernel, filesystem, and network stack. The control plane is a REST API plus VM orchestration historically built on Nomad and Consul running on GCP, with an in-VM agent, an edge routing layer, and a template-building pipeline. The SDK is open source (Apache 2.0, 11,000+ GitHub stars), and the infrastructure repo is public too, which is more than most sandbox vendors disclose — but "open source" here describes the client and the reference infra, not a turnkey self-hosted product. Enterprise self-hosting exists as BYOC (bring your own cloud), and only on AWS.

The customer list is the adoption proof. Manus runs each agent task in a full E2B sandbox VM containing Chromium, a terminal, a filesystem, and dozens of tools — one sandbox is a complete agent workstation, not a bare Python REPL. E2B's docs explicitly support running coding agents like Claude Code, Codex, and Amp inside sandboxes with full terminal, filesystem, and git access. When the TODO item for this post says 88% of the Fortune 100, that figure comes from E2B's own marketing — treat it as "signed up or running workloads," not audited revenue — but the named-agent-company customer list is independently corroborated by the company's own hiring pages and press.

Decomposing "E2B-style" into buildable components​

Here is the spec, component by component, with what each one concretely requires.

1. Firecracker microVM isolation. Each sandbox is a KVM virtual machine with its own guest kernel — a hardware boundary, not Linux namespaces on a shared kernel. The meaningful comparison is against Docker: a container escape is a kernel exploit away, while a microVM escape has to cross the hypervisor. The cost is overhead: each VM needs its own kernel image and memory allocation (E2B defaults to 1 GB RAM per sandbox), which dominates cost math at high concurrency. The host requirement is also non-negotiable: Firecracker needs /dev/kvm, which means bare metal or nested-virtualization-capable VMs — not every cheap VPS qualifies.

2. Sub-200ms boot via snapshot resume. The ~150ms number is not a from-scratch boot. Raw Firecracker cold boot is roughly a second end to end (host setup plus hypervisor plus Linux boot); the fast path restores from a pre-booted snapshot in about 125ms. So the component to build is not "a fast VM" but a snapshot pipeline: boot template VMs ahead of time, snapshot them copy-on-write, and restore per request. Competitors bracket the number — Daytona claims under 90ms, Modal around 100ms on gVisor, Zeroboot-style CoW snapshots claim single-digit milliseconds — which tells you the ~150ms figure is a snapshot-restore equilibrium, not a physics limit.

3. Per-second metering. E2B bills wall-clock seconds of running sandbox time: about USD 0.0504/vCPU-hr and USD 0.0162/GiB-hr, with a USD 150/month Pro plan under it. The sensitivity that matters here is wall-clock versus active-CPU: a sandbox blocked on I/O still bills the full CPU rate. Vercel's Sandbox, by contrast, bills active CPU only (USD 0.128/vCPU-hr) with millisecond granularity and excludes I/O wait — a cheaper model for I/O-bound agents, a more expensive one for CPU-saturated agents. Any self-hosted clone needs a metering decision here, not just a timer: wall-clock is simpler to implement and easier for tenants to predict, active-CPU is fairer but requires cgroup-level accounting.

4. Templates. An agent requests claude-code or a custom template and gets a known-good runtime — language toolchains, browser, tools — instead of apt-getting its way to a working environment on every run. The component is a template build pipeline (Dockerfile-style definitions compiled to VM snapshots) plus versioning, because template drift between runs is a correctness bug: an agent that tested against one toolchain and executed against another produces unreproducible results.

5. Lifecycle API with pause/resume. Sandbox.create(), commands.run(), file operations, kill() — and crucially pause()/resume(), which captures filesystem, memory, and processes, resumes in about a second, and stops billing while paused. Pause is what makes the 24-hour session limit livable: long agent runs checkpoint instead of racing a timeout. Building this means checkpoint/restore machinery (CRIU-class, or hypervisor snapshots) wired into the billing clock — the pause must provably stop the meter or tenants won't trust it.

The competitive range, honestly stated​

E2B is the reference, not the only option. A self-hosted platform choosing "build, buy, or borrow" should see the range:

Two honest caveats. First, Daytona's self-hosted story comes with a mid-2026 asterisk: its core went closed-source, so "self-host Daytona" now means depending on a vendor's binary, not a community fork. Second, Modal's gVisor isolation is weaker than a microVM boundary but its GPU story is stronger than E2B's — E2B's templates have historically been CPU-only, which matters the moment agent sandboxes want local model inference rather than just code execution.

The hosted-control-plane gap: what self-hosting actually costs​

This is the section the title promises for the self-hosting reader. E2B's model assumes a control plane someone operates: request routing, VM scheduling across hosts, snapshot storage and distribution, per-second metering, template builds, and the edge layer that gets agent traffic into the right sandbox. Running that yourself on owned hardware — say, a Cluster-API-managed Hetzner fleet — means supplying each of those pieces:

• KVM-capable hosts with headroom. Firecracker needs /dev/kvm and roughly 1 GB RAM per warm sandbox plus snapshot cache. On owned machines this is a capacity-planning question, not an API call: how many warm snapshots per host, and what happens to boot latency when the warm pool drains.
• An orchestrator for microVMs. E2B uses Nomad plus Consul; a Kubernetes-native fleet would more likely run each sandbox as a Pod under a Firecracker or Kata RuntimeClass, or adopt something like the open-sandbox-router pattern with a Kubernetes adapter. Either way, "schedule VMs onto hosts with KVM, bin-pack by RAM, drain for maintenance" is a real scheduler, not a shell script.
• Snapshot distribution. Sub-200ms boot anywhere in the fleet requires template snapshots cached near every host. That is a small artifact-distribution system (OCI registries already solve this shape of problem) with a cold-region failure mode: the first request in a region without a warm snapshot pays full boot cost.
• Metering tenants trust. Per-second wall-clock billing needs a tamper-evident runtime clock per sandbox and an invoice pipeline. Simpler than active-CPU accounting, but it still has to survive the adversarial question: "prove my sandbox was actually running for those 4,000 seconds."
• The edge and the SDK surface. Agents talk to sandboxes over the network; proxied terminal, filesystem, and git access through an edge routing layer is part of the product, not garnish. E2B's open-source SDK helps here — the API shape is public — but the routing layer behind it still has to be built and operated.

None of this is exotic. It is, collectively, a multi-quarter infrastructure project orthogonal to most product roadmaps — which is exactly why the common advice is "buy E2B now, self-host later if the bill justifies it." The honest self-host trigger is arithmetic: community estimates put a self-hosted Firecracker platform at roughly USD 20/month on a Hetzner-class bare-metal box versus hundreds per month in managed sandbox spend at moderate volume. Below that crossover, the hosted control plane is the cheaper engineering choice even for a team philosophically committed to owning its machines.

What this sets as the bar​

E2B's numbers are now the acceptance criteria for any agent-sandbox story, hosted or self-built: hardware-boundary isolation, boot in the low hundreds of milliseconds via snapshot restore, per-second metering with pause that stops the clock, templates as versioned artifacts, and a lifecycle API agents can drive without human help. A platform whose roadmap says "E2B-style sandboxes" owes its future self all five — and owes its present self the control-plane checklist above before claiming the self-hosted variant is nearly done.

The deeper shift is what the customer list signals. When Perplexity, Hugging Face, Manus, and Groq all execute agent code in disposable microVMs, the sandbox stops being a security accessory and becomes the compute primitive agents assume — the way containers became the primitive web services assume. Platforms that host agents will either offer that primitive or explain why their agents run somewhere else's.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent sandboxes are on the roadmap; star the repo on GitHub or deploy your first app today.