E2B Is Now Native in OpenAI's Agents SDK: The Bar a Self-Hosted Agent Sandbox Has to Clear

Roughly 200 milliseconds. That is how long E2B claims it takes to hand an AI agent a fresh, isolated computer — a Firecracker microVM with its own kernel, filesystem, and network namespace — from a cold start. Since April 2026, that computer can be declared directly inside OpenAI's Agents SDK configuration instead of glued in by hand, and in September the new Agents API doubled down with hosted sandboxes of its own. For anyone running agent infrastructure on machines they own, this pair of moves quietly settled an open question: the sandbox primitive is no longer "a container somewhere," it is a fast-booting microVM behind an SDK-level declaration — and any self-hosted alternative now has a concrete bar to clear.

That bar is the subject of this post. Not the hype ("foundation-model vendor endorses a sandbox"), but the checklist: the exact primitives a from-scratch self-hosted sandbox must match — cold-start latency, template story, pause and resume, MCP sandboxing, API shape — to be a credible alternative rather than a slower DIY version of the same idea. And a scorecard of the four self-hosted paths that could get there, with each one's honest gap.

The news in one paragraph, and why E2B is the bar​

In April 2026, OpenAI updated the Agents SDK with first-class sandbox support: developers can bring their own sandbox or pick built-in clients for Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. The SDK also introduced a Manifest abstraction — a portable description of the agent's workspace, inputs, and outputs — so the same environment definition runs across providers. In September 2026, the launch of the managed Agents API extended the pattern again: OpenAI-hosted sandboxes plus first-class integrations with nine providers (adding DigitalOcean and Oracle Cloud to the list).

Two clarifications matter before anything else. First, E2B is one provider among several, not an exclusive endorsement — any telling of this story that says OpenAI "picked" E2B is wrong, and the September launch's own hosted sandboxes show the vendor wants optionality, not a single dependency. Second, the durable signal is nevertheless E2B-shaped, for three concrete reasons: Firecracker microVMs are the strongest isolation tier among the built-in options; the E2B API shape (create a sandbox from a template, run code, pause and resume it) is what emerging self-hosted gateways are cloning for drop-in compatibility; and E2B's numbers are the published reference values everyone else gets measured against. Think of the bar as the Manifest's vendor-neutral shape plus E2B's reference values — that combination is what a self-hosted platform builds toward.

What "native" concretely means​

Before April, wiring a sandbox into an agent meant hand-rolled glue: provision a VM or container out of band, inject credentials and workspace contents yourself, stream stdout back through your own harness, and tear everything down when the run ended. Every team invented this layer slightly differently, and every invention was a snowflake the next hire had to learn.

"Native" replaces the glue with a declaration. In the Python SDK, E2B arrives as E2BSandboxClient behind the openai-agents[e2b] install extra; in the JavaScript SDK it is @openai/agents-extensions/sandbox/e2b with the e2b package as a peer dependency. The agent configuration names the sandbox client the way it names the model — the SDK owns provisioning, workspace staging via the Manifest, execution, and teardown. A sketch of the shape (not a runnable snippet, since client APIs keep evolving) looks like this:

from openai_agents import Agent
from openai_agents.sandbox import E2BSandboxClient
 
agent = Agent(
    name="researcher",
    sandbox=E2BSandboxClient(template="code-interpreter"),
)

The Manifest is the subtler half of the story. By standardizing how a workspace is described — mounts, writable paths, dependencies, expected artifacts — the SDK makes the sandbox interchangeable: the same agent definition can run against E2B today, a self-hosted backend tomorrow, or an OpenAI-hosted sandbox when that fits. That portability is precisely what turns "E2B is convenient" into "the E2B-compatible interface is the target" — a self-hosted backend that accepts the same declarations inherits the whole ecosystem of agents written against that interface.

The checklist E2B sets​

Strip away the marketing and E2B's offering decomposes into six primitives. Each row below is a requirement a credible self-hosted rival must satisfy, with E2B's reference value:

Two rows deserve emphasis because they are where DIY efforts most often quietly fail. Cold start is not vanity latency: agents routinely fan out dozens of sandboxes per task, so a 30-second container pull-and-boot multiplied across a fan-out is the difference between an interactive agent and a batch job. And pause/resume with memory state is what makes long-horizon agents affordable — without it, every idle agent either burns a running VM or loses its in-memory progress, and neither scales past a demo.

The self-hosted scorecard​

Four paths can plausibly reach the bar from infrastructure you own. Scored honestly against the checklist above:

1. Raw Firecracker DIY. Firecracker itself boots a microVM in roughly 125ms, so the raw material beats E2B's headline number. But Firecracker is a process-per-VM binary, not a platform: no API server, no template builds, no pause/resume orchestration, no multi-tenant network policy, no SDK. Everything above the hypervisor — the other five checklist rows — is yours to build. Verdict: fastest primitive, largest build burden; credible only as the foundation of one of the paths below.

2. Daytona, self-hosted. Daytona is open source and self-hostable, offers persistent workspaces, MCP support, and is itself one of the SDK's built-in providers — the declaration story works out of the box. The gap is isolation tier and lifecycle depth: workspaces are Docker containers on a shared host kernel, and snapshots cover the filesystem, not memory. For trusted-tenant internal agents that is often fine; for untrusted third-party code it is a categorically weaker boundary than a microVM, and no SKU of "self-hosted" changes which kernel a container escape lands in. Verdict: closest on API compatibility, weakest on isolation.

3. AgentENV (E2B-compatible Firecracker). The Kimi team's AgentENV project runs self-hosted Firecracker microVMs behind a natively E2B-compatible API — point the official E2B SDK at the gateway URL and existing code runs unmodified, with snapshot-backed sub-second starts. This is the "clone the interface" strategy made concrete: microVM isolation plus the E2B declaration surface on your own metal. The gap is maturity and breadth: a young project with a narrower template ecosystem, no published equivalent of E2B's layered egress pipeline, and a bus factor no platform team should ignore. Verdict: best shape match, youngest project.

4. kubernetes-sigs/agent-sandbox. The Kubernetes-native path: a Sandbox CRD plus SandboxTemplate and SandboxClaim extension APIs (graduated from SIG Apps in March 2026, API group agents.x-k8s.io) that make sandboxes declarative cluster resources with lifecycle management — pause, resume, expire — and warm pools for fast starts. Isolation comes from the RuntimeClass (Kata Containers or gVisor), and an open proposal would add an E2B-compatible HTTP gateway so existing E2B SDK code migrates with only a URL change. GKE already ships a managed flavor, and the EKS ecosystem packages it for AWS. The gap is operational surface: it needs a Kubernetes cluster, its cold starts depend on warm-pool tuning rather than Firecracker snapshots, and the E2B gateway is a proposal, not a release. Verdict: best fit for a Cluster-API fleet, most machinery to operate.

No path scores full marks today. That is the honest state of the market: E2B's moat is not any single feature but all six rows at once, and every self-hosted option concedes at least one.

What "credible alternative" actually requires​

If you are building (or buying-then-hardening) a self-hosted sandbox, the checklist orders itself by what breaks first in production:

1. Sub-second cold start via snapshots or warm pools. Raw boot speed is table stakes; the mechanism is snapshot restore (Firecracker snapshots, Kata pre-warmed pods) or a maintained warm pool. Measure p99 under fan-out, not a single warm-path demo — agents burst.
2. An SDK-level declaration surface. Accept the E2B API shape, the agent-sandbox CRDs, or both. An agent framework should target your backend by changing a URL or client name, not by rewriting its execution layer. This is the single highest-leverage compatibility decision.
3. A template build pipeline. Templates-from-Dockerfile (or OCI images into sandbox roots) with versioning and caching. Without it, every sandbox boots generic and slow-installs its toolchain at runtime, which quietly eats the cold-start budget from step 1.
4. Pause, resume, and expiry as first-class lifecycle. Memory-preserving pause for long-horizon agents, TTL-based expiry so abandoned sandboxes cannot accumulate into a cost or security incident. Filesystem-only snapshots are a half measure — say so in your docs if that is what you ship.
5. Egress policy before you need it. Per-sandbox network policy, domain allowlists, and audit logging. Untrusted generated code with open egress is a credential-exfiltration incident waiting for its first prompt injection; this row is the one teams postpone and then implement during an incident.

Note what is deliberately absent: matching E2B's exact 200ms number. "Sub-second under fan-out" is the requirement that matters — an agent orchestrator cannot tell 180ms from 600ms, but it absolutely tells either from 30 seconds. Build to the sensitivity that counts.

Build toward the interface, not the vendor​

Step back and the pattern is familiar from every infrastructure cycle: a vendor (E2B) defines the ergonomic interface, a framework (the Agents SDK Manifest) makes it portable, and then the open ecosystem clones the interface so the value accrues to whoever runs it cheapest on their own metal. We have seen the E2B-compatible gateway proposals, the Kubernetes-native CRDs, and the self-hosted Firecracker platforms all converge on the same API shape within months of each other. That convergence is the real endorsement — stronger than any single SDK integration, because it survives any one vendor's roadmap.

For a self-hosted PaaS, the implication is refreshingly concrete: you do not need to out-feature E2B, you need to speak its language. Implement the declaration surface agents already target, clear sub-second cold starts on hardware you own, and treat the remaining rows as a sequenced roadmap rather than a launch blocker. The teams that do that get agents that run anywhere — including on machines nobody else can bill them for.

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, and the interface-first approach above is how we plan to build them. Star the repo on GitHub or deploy your first app today.