Skip to main content
bex.co
419
Blog

E2B Joined the OpenAI Agents SDK. The Real Story Is How Many Times It's Had To.

9 min readDora NodaDora Noda
Self-Hosting
PaaS
AI agents
Model Context Protocol
Infrastructure
Share

On April 15, 2026, E2B announced it had shipped a native sandbox provider integration into the OpenAI Agents SDK. Read the announcement on its own and it sounds like validation: the Firecracker-microVM sandbox startup, now claiming 1 billion-plus sandboxes started and 94% of the Fortune 100 as customers, landed a first-class slot inside OpenAI's own agent framework. But the OpenAI integration isn't E2B's first, its fifth, or even its most strategically important. It's the tenth distinct, publicly documented integration guide E2B maintains for a named agent product — and counting the list is more revealing than the announcement itself.

Ten Integrations, Two Very Different Games​

E2B's own documentation currently ships dedicated integration guides for ten separately branded agent products: Amp, Claude Code, Claude Managed Agents, Codex, Crabbox, Devin, Grok Build, the OpenAI Agents SDK, OpenClaw, and OpenCode. That's not a rounding error or a marketing exaggeration — it's the literal count of /docs/agents/* pages on E2B's site as of this writing.

But the ten aren't the same kind of work, and lumping them together would flatter the "racing to be everywhere" narrative more than the facts support. They split cleanly into two categories:

Cooperative provider slots — a framework vendor builds a plugin interface and lists E2B as one of several first-party options. This is the OpenAI Agents SDK pattern, and Anthropic's Claude Managed Agents self-hosted runtime works the same way. There are exactly two of these in E2B's list.

Unilateral sandbox templates — E2B pre-builds a container image with a given coding agent (Amp, Claude Code as a CLI tool, Codex, Crabbox, Devin, Grok Build, OpenClaw, OpenCode) already installed, and publishes a guide showing how to run that agent inside an E2B sandbox. Nothing on the other side has to agree to anything; E2B just does the packaging work. That's eight of the ten.

The distinction matters because the two categories carry completely different competitive weight. A unilateral template is marketing content — the kind of thing any sandbox vendor can publish about any popular coding agent in an afternoon, with or without that agent's cooperation. A cooperative provider slot is different: it means a competing framework's maintainers evaluated E2B against alternatives and wrote first-party code to support it. That's the scarcer, more valuable outcome, and E2B has landed exactly two of them.

The OpenAI Agents SDK slot is also, by design, not exclusive. OpenAI's own SDK documentation lists seven sandbox providers supported out of the box: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. E2B didn't win a category — it won one of seven equally-weighted rows in a dropdown. The real shape of the market isn't "one vendor embeds everywhere." It's an N-sandboxes × M-frameworks matrix that gets more expensive to maintain, for every vendor in it, with every new framework that ships.

Why E2B Is Running This Race at All​

The volume behind E2B's push is real. Independent tracking of Firecracker-based sandbox adoption put E2B's usage at roughly 40,000 sandboxes started per month in March 2024, growing to about 15 million per month by March 2025 — a 375x increase in twelve months. By mid-2026, E2B's own site states 7 million-plus monthly SDK downloads and more than 1 billion sandboxes started cumulatively, on the back of a $21 million Series A led by Insight Partners.

That growth is happening in a market where the underlying technology is no longer a differentiator. Firecracker microVM isolation — the core security primitive E2B is built on — is available to any competitor willing to operate it:

  • Modal offers the same class of isolation with GPU-native tooling layered on top for ML-heavy agent workloads.
  • Daytona pivoted from a developer-environment manager into a compliance-first sandbox platform, closing a $24 million Series A in February 2026 on the strength of HIPAA and SOC 2 certification for regulated-industry customers.
  • Fly Machines exposes the raw Firecracker primitive directly, trading integration convenience for maximum control.

None of these companies compete on "can we isolate untrusted code" — they all can. They compete on integration surface area, compliance posture, and developer experience wrapped around the same microVM core.

Given that, publishing ten integration guides — even eight unilateral ones — isn't wasted effort. It's the cheapest lever E2B has to look present everywhere a developer might be starting an agent project, in a market where the technical moat has already flattened.

E2B's Own Hedge: Betting on MCP Too​

The part of E2B's strategy that the "racing to embed everywhere" framing misses is that E2B is simultaneously investing in the opposite approach. In partnership with Docker, E2B built an MCP gateway that runs inside every sandbox, giving agents type-safe access to more than 200 tools from Docker's MCP Catalog — GitHub, Stripe, Notion, Browserbase, and others — through one protocol-level interface instead of one bespoke integration per tool. E2B didn't have to write a custom adapter for each of those 200+ tools. It wrote one MCP gateway, once, and inherited compatibility with all of them.

That's a meaningfully different bet than the ten framework-specific guides, and it's happening against a backdrop of real institutional consolidation around MCP as a standard. In December 2025, Anthropic donated the Model Context Protocol to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg signed on as supporting members. Handing protocol governance to a neutral, multi-vendor foundation — rather than keeping it under one company's control — is precisely the kind of signal that makes betting on a protocol instead of an SDK integration less risky than it looked a year earlier.

So even the vendor most visibly playing the per-framework integration game is hedging with a protocol-first move on the tool-access side. That split is the actual lesson for anyone building sandbox infrastructure, not the OpenAI announcement by itself.

The Decision a Self-Hosted Sandbox Platform Actually Faces​

For a self-hosted PaaS offering AI-agent sandboxes as a platform primitive — the position bex is in — the E2B pattern isn't something to imitate wholesale. It's a build-versus-bet decision with a defensible default.

Option A: build the same per-framework SDK adapters E2B is building. This means writing and maintaining bespoke integration code for OpenAI's Agents SDK, Claude Managed Agents, and whichever cooperative provider slots open up next — plus, if you want E2B's full visibility, matching the unilateral templates too. The cost isn't the first integration; it's the ongoing tax. Every quarter a new coding agent or agent framework ships, the list grows, and each existing integration has to be kept in sync with upstream SDK changes. This is a maintenance commitment with no natural end state — the target keeps moving, permanently.

Option B: ship one MCP server that exposes sandbox lifecycle as tools — create, exec, read/write file, kill, snapshot — and let any MCP-speaking client talk to it without a custom adapter. Concretely, that means five or six tool definitions (sandbox.create, sandbox.exec, sandbox.read_file, sandbox.write_file, sandbox.snapshot, sandbox.kill), each with a typed JSON schema, registered once against the MCP spec. Any agent framework that already speaks MCP — which by 2026 is most of them, for tool-calling generally — gets sandbox control for free, without bex writing a line of framework-specific glue. This is the E2B-Docker gateway pattern, applied to the sandbox's own control surface instead of just the tools inside it. Because MCP adoption is now spreading through frameworks that also ship native provider slots (the same OpenAI Agents SDK that lists seven built-in sandbox providers also consumes MCP tools), a well-built MCP server buys compatibility with most of the ecosystem in one implementation, not ten.

The honest limit of Option B is real and worth stating plainly: a generic MCP tool call can't replicate everything a deep, framework-specific integration can. The OpenAI Agents SDK's native E2B provider exposes live-preview URLs and artifact-review flows wired directly into the agent's own execution loop — conveniences that a framework's maintainers built because they control both sides of that interface. An MCP server, by design, can't reach into a framework's UI layer the way a first-party provider slot can.

The resolution isn't "always pick one." It's sequencing. Ship the MCP server first, because it's a single implementation that inherits compatibility broadly and doesn't accrue a linear maintenance cost as new frameworks appear. Treat a cooperative provider slot — the two-per-year kind, not the eight unilateral templates — as a distribution decision to revisit only when a specific framework's dropdown demonstrably drives traffic worth the dedicated maintenance commitment. Skip the unilateral coding-agent templates entirely; they're marketing surface for whichever vendor publishes them fastest, not integration work a competitor is structurally required to match one-for-one.

That's the actual takeaway from watching E2B's tenth integration guide ship: not "match this pace," but "match the two moves that compound, and skip the eight that don't."

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-operable infrastructure exposed over MCP instead of a bespoke SDK for every framework. Star the repo on GitHub or deploy your first app today.

Sources​

Related articles

Give your agents a chain backend

Autonomous agents hit RPC endpoints very differently than people do. See what bex router handles on their behalf.

Read the agents guide
Back to all posts