Daniel Kim

Posted on Aug 16

Daytona Closed Its Source in June. The AI Agent Sandbox Market Just Split in Two

#programming #opensource #ai #cloud

If you've shipped an AI coding agent in the last year, you've run into a problem that didn't exist for most of software history: your product now needs to execute code it didn't write, from a model you don't fully trust, on behalf of a user you've never met. That code might be a data-analysis script, a test suite the agent generated to verify its own patch, or a shell command it decided was the fastest way to grep a log file. Wherever it runs, it cannot run in your API process, and it probably shouldn't run in a container that shares a kernel with anything else that matters.

That's the job description for a new infrastructure category that didn't really exist three years ago: the AI agent sandbox. E2B, Daytona, Modal, and Cloudflare all sell some version of "give an untrusted process a machine, let it do its thing, throw the machine away." They disagree, sometimes sharply, on how that machine should be isolated, what it costs, and — as of this year — whether you're even allowed to see the code that isolates it.

That last point is the reason to write this comparison now rather than six months ago. In June 2026, Daytona moved its production codebase to closed source. The original open-source repository is still sitting on GitHub, but it's no longer where the product actually lives — it's an artifact, not a moving target you can fork and trust to stay current. For a category whose entire pitch to security-conscious teams has been "you can inspect the isolation boundary yourself," that's not a cosmetic change. It's a fork in the road, literally: the sandbox market as of mid-2026 splits into vendors you can still audit and self-host, and vendors you now have to trust on their word.

The four contenders, briefly

E2B is the closest thing this category has to an incumbent. It started as an open-source SDK for spinning up short-lived, code-execution sandboxes for LLM agents, and it's the default a lot of agent frameworks (LangChain, CrewAI, various open-source coding-agent projects) reach for first. The core SDK and much of the underlying sandbox infrastructure remain open source, and E2B publishes a self-hosting path for teams that don't want to run untrusted code on someone else's multi-tenant fleet.

Daytona started life as an open-source developer-environment manager — the kind of tool you'd use to spin up a reproducible dev container for a human engineer. It pivoted hard toward AI agent sandboxes, leaning on sub-second startup times as its main differentiator, and until this year that pitch came with an open-source codebase to back it up.

Modal isn't primarily a sandbox company at all — it's a general-purpose serverless compute platform, originally built for data and ML teams who wanted to run Python functions on remote GPUs without managing infrastructure. Sandboxes are a primitive Modal added on top of that existing platform, which matters because it means Modal's sandboxes inherit a mature, production-hardened compute layer rather than being the whole product.

Cloudflare's Sandbox SDK is the newest serious entrant, reaching general availability in April 2026. It's built on Cloudflare Containers and ships as a primitive inside the Workers ecosystem — meaning it's less a standalone product than a feature of a platform you're probably already using for something else if you're a Cloudflare customer.

Two others are worth a passing mention even though they don't make the head-to-head: Vercel Sandbox, which exists mostly to let Vercel-hosted agent products run code without leaving Vercel's infrastructure, and a long tail of thinner wrappers (Blaxel and others) that resell or front one of the four platforms above with a friendlier API. If you're evaluating this space, start with the four that actually own their compute layer.

How each one is actually built

The architectural decisions here aren't academic — they're the difference between "an attacker who breaks out of the sandboxed process can read your host's environment variables" and "an attacker who breaks out of the sandboxed process is still stuck inside a virtual machine with its own kernel."

E2B runs on Firecracker, the microVM technology AWS built for Lambda and open-sourced in 2018. Each E2B sandbox gets its own Linux kernel, running under KVM, isolated at the hardware-virtualization layer rather than merely at the process or namespace layer. This is the isolation model security teams tend to prefer for genuinely untrusted code, because a kernel exploit inside one microVM does not automatically give an attacker a path to the host or to a neighboring tenant's sandbox — the boundary that has to hold is the same one that has to hold for any other public cloud VM.

Daytona, prior to and during its closed-source transition, has been container-based by default — standard Linux namespaces and cgroups, the same isolation primitive Docker uses — with Kata Containers or Sysbox available as an opt-in for teams that want microVM-grade separation. Containers sharing a host kernel are cheaper to start and lighter to run, but the security model is different in kind, not just degree: every sandbox on a host is one kernel vulnerability away from every other sandbox on that host, unless you've paid the isolation tax of layering Kata or Sysbox on top.

Modal isolates sandboxes with gVisor, Google's user-space kernel that intercepts syscalls and reimplements them rather than passing them straight through to the host kernel. It's a middle position between containers and full virtualization — narrower attack surface than a bare container, less overhead than a full microVM — and it's also, notably, the only one of the four where a sandbox can hold a GPU. If your agent needs to run inference or do image/video processing inside the same isolated execution as its code, Modal is presently the only one of these four with a straightforward answer.

Cloudflare's Sandbox SDK rides on Cloudflare Containers, which themselves run on Firecracker microVMs under the hood — so architecturally it's closer to E2B's isolation story than Daytona's default. The catch is that you can't get that isolation without also buying into the rest of the Workers ecosystem: the SDK requires a Workers Paid plan, and the sandbox is meant to be orchestrated from a Worker, not called as a freestanding API the way you'd call E2B or Modal from any backend.

What actually changed this year

Three things moved in 2026 that make this a live decision rather than a settled one:

Daytona went closed source in June. The company kept the old open-source repository public, but stopped maintaining it — the code you can audit today is not the code running in production. For any team that picked Daytona specifically because they could self-host or fork it, that rationale is gone.
Cloudflare's Sandbox SDK reached general availability in April, positioning itself as the default compute primitive for what Cloudflare is explicitly calling its "agentic cloud" strategy — bundled alongside browser rendering, AI Gateway, and MCP tooling, all inside the same Workers billing relationship.
Modal leaned further into GPU-attached sandboxes, which didn't exist as a mainstream option a year ago and now gives Modal a use case none of the other three can match without bolting on a separate inference provider.

Put together, the market didn't just add a new entrant (Cloudflare) — it lost a degree of freedom (Daytona's openness) at the same time. That's the actual news here, more than any single benchmark number.

It's also worth asking, bluntly, which of these four you'd bet on still existing in roughly its current form two years from now — because "will my sandbox vendor still be here" is a real operational risk for a category this young. E2B has the advantage of being narrowly focused: sandboxing is the whole business, which means the whole company is aligned around making it work, but it also means E2B has less to fall back on if agent adoption plateaus. Modal is the inverse case — sandboxes are a feature of a broader, already-revenue-generating ML compute platform, which makes Modal's sandbox offering the least likely of the four to get orphaned, precisely because it isn't the thing investors are betting the company on. Cloudflare is effectively too big to be a platform-risk concern in the way a startup is, but that cuts both ways: Cloudflare has also killed or deprioritized developer products before when they didn't hit adoption targets, and a sandbox feature buried inside Workers is easier to quietly deprioritize than a flagship product would be. Daytona is the one where the risk calculus changed this year — going closed source is often a move companies make when they need tighter control over monetization, which isn't inherently a bad sign, but it's exactly the kind of strategic pivot that should make you ask what pivot comes next.

Why this should matter to you, specifically

Cost. All four bill by compute time, but the shape of that bill differs. E2B and Daytona both price close to public-cloud vCPU rates on a per-second basis, which is legible if you're used to reading a cloud bill. Modal's pricing is dominated by whether your workload touches a GPU — CPU-only sandboxes are competitive, GPU-attached ones carry a real premium, roughly on the order of what you'd pay for equivalent GPU time anywhere else, which is fair but easy to underestimate if you're prototyping on CPU and scaling to GPU later. Cloudflare's pricing is the most unusual of the four: it's metered in GiB-seconds, vCPU-seconds, and GB-seconds against a Workers Paid plan with a monthly included allowance, which is cheap at low volume and requires you to actually model your usage curve to know what it costs at scale.

Latency. Cold start is the number every vendor wants to lead with, and it's also the number you should trust least without reproducing it yourself. Daytona has marketed cold starts as low as double-digit milliseconds in optimized configurations; E2B's Firecracker-based starts are typically cited in the low hundreds of milliseconds. Modal's gVisor sandboxes and Cloudflare's container-backed sandboxes both land in similar territory, with Cloudflare benefiting from proximity to its edge network for the initial request but not necessarily for the sandbox boot itself. Treat every one of these numbers as a starting point for your own benchmark, not a spec you can build an SLA on — see the "what marketing omits" section below.

Developer experience. E2B has the most mature SDK ecosystem specifically for agent use cases — it shows up as the default backend in a large share of open-source agent frameworks, which means more existing code to copy from and fewer integration surprises. Modal's SDK is excellent if your team already thinks in Python and is comfortable with Modal's function-decorator programming model, less so if you need a lightweight sandbox called from a non-Python service. Daytona's SDK is still solid post-pivot, but you're now adopting the DX of a company that just changed its fundamental trust posture. Cloudflare's SDK is the most opinionated of the four: it assumes you're building the whole agent inside a Worker, which is a gift if you are and friction if you're not.

Lock-in. This is where Daytona's closed-source move actually bites. Before June, "worst case, we fork it and run it ourselves" was a real answer to a procurement question. It no longer is, in practice, for new adopters — you'd be forking a codebase the vendor has already abandoned. E2B remains the one platform in this group where self-hosting is a live, documented option today, not a historical footnote. Modal and Cloudflare were never pitched as self-hostable and aren't being reassessed here on that basis — but it's worth naming plainly that picking either one is picking a fully proprietary dependency, same as it always was.

Security. The isolation technology write-up above isn't decoration — it's the actual answer to "what happens when the sandbox breaks." Firecracker-based isolation (E2B, and Cloudflare underneath its Workers packaging) gives you a hardware-virtualization boundary. gVisor (Modal) gives you a narrowed syscall surface without full virtualization overhead. Default-container Daytona gives you the isolation model most teams already run in production for non-adversarial workloads — fine for code you trust, a materially different bet for code an LLM generated from a prompt injection you haven't seen yet.

Maintainability. The honest answer is that none of these four sandboxes is a "set and forget" dependency. All four are young enough that their SDKs, pricing models, and even ownership structure (see: Daytona) are still moving. Budget for revisiting this choice on a 12-month cycle, not a five-year one.

Practical use cases, per option

E2B fits teams building or extending an open-source-adjacent coding agent, teams who need a documented self-hosting path for compliance reasons, and anyone who wants the broadest existing base of agent-framework integrations to build on top of.
Daytona still fits teams for whom raw cold-start latency is the dominant cost — high-frequency, short-lived executions where shaving 50-100ms per invocation compounds across millions of calls — provided they've made peace with adopting a now-closed-source dependency.
Modal fits any agent workload that needs to touch a GPU inside the same isolated execution: agents that run their own model inference, do image or video processing, or need to benchmark GPU code the agent just wrote. It also fits teams already running ML pipelines on Modal who want one vendor relationship instead of three.
Cloudflare Sandbox SDK fits teams already built on Workers, Durable Objects, and R2 who want agent code execution without adding a fifth vendor to their stack, and who are comfortable with the Workers billing and deployment model as the cost of that convenience.

Zoom in on a single concrete scenario and the tradeoffs get sharper. Say you're building a coding agent that, after generating a patch, wants to run the project's real test suite to check its own work before showing the diff to a user. That's exactly the kind of untrusted, potentially long-running, occasionally resource-hungry execution this category exists for. On E2B, you get a fresh microVM per test run with strong isolation guarantees and an SDK that plenty of existing open-source coding-agent scaffolding already knows how to call — the integration cost is close to zero. On Daytona, you'd get a faster cold start on each of those runs, which matters if your agent runs the suite dozens of times per session while iterating, but you're now depending on a vendor whose source you can no longer inspect if that isolation boundary is ever the difference between "safe" and "an incident." On Modal, the same test run works fine, and if that project's test suite happens to include a GPU-dependent integration test — increasingly common for anything touching ML — Modal is the only one of the four where that test doesn't need a second execution environment. On Cloudflare, the same pattern works well if the coding agent itself is already deployed as a Worker, and becomes an awkward second network hop if it isn't.

What the marketing pages don't tell you

A few things surfaced in researching this piece that don't show up prominently on any vendor's landing page:

Most of the cross-vendor benchmark numbers circulating right now are not independently reproduced. A striking number of "2026 comparison" articles for this exact category cite the same handful of cold-start figures, phrased almost identically, which is the signature of numbers copied from vendor marketing rather than measured firsthand. Treat any specific millisecond figure you read — including some of the ones summarized above — as a claim to verify against your own workload, not a settled fact.
Daytona's public messaging around the closed-source move has been muted. The change is a matter of public record in the repository's own history, but it's not something the company is foregrounding in its own marketing copy, which is worth noticing given how central "open source" was to its original pitch.
"Self-hostable" and "open source" are not the same claim, and vendors blur them. E2B's self-hosting path exists and is documented, but running your own fleet of Firecracker microVMs at production scale is a genuine infrastructure undertaking, not a docker-compose file. Budget for it accordingly if you're choosing E2B specifically to avoid vendor lock-in.
GPU-in-sandbox is a narrower feature than it sounds. Modal's GPU sandboxes are a real differentiator, but they inherit all the usual GPU-availability and quota constraints of any GPU cloud — "Modal supports GPU sandboxes" does not mean "Modal has unlimited GPU sandboxes on demand" during periods of high demand.
Cloudflare's included-usage allowances are easy to blow past accidentally. The Workers Paid plan's included compute is generous for light agent workloads and gets consumed fast by anything running long-lived or memory-heavy sandboxes, at which point you're paying Cloudflare's metered container rates on top of the base subscription — model this before committing, not after the first invoice.

Comparison table

Dimension	E2B	Daytona	Modal	Cloudflare Sandbox SDK
Isolation model	Firecracker microVM	Containers by default; Kata/Sysbox optional	gVisor user-space kernel	Firecracker microVM via Cloudflare Containers
Open source	Yes — SDK and infra, self-hostable	No, as of June 2026 (old repo public but unmaintained)	No	No
GPU-in-sandbox	No	No	Yes	No
Cold start (vendor-cited, unverified)	~150ms range	Vendor claims sub-100ms, down to ~27ms optimized	Sub-second, gVisor overhead	Comparable to container cold starts on Workers
Pricing model	Per-second vCPU/RAM	Per-second vCPU/RAM, near price parity with E2B	Per-second compute; GPU carries a real premium	Metered GiB-sec / vCPU-sec / GB-sec on top of Workers Paid ($5/mo base)
Best fit	Broadest agent-framework support, compliance-driven self-hosting	Latency-critical, high-frequency short executions	GPU-touching agent workloads	Teams already deep in the Workers ecosystem
Primary risk	Self-hosting at scale is real infra work	Vendor lock-in now that the source is closed	Proprietary platform dependency	Coupled to Workers billing and deployment model
GA / major milestone this year	Continued framework adoption	Closed-sourced production codebase, June 2026	Expanded GPU sandbox support	General availability, April 2026

An independent read

None of these four is wrong, and none of them is obviously right either — this category is still young enough that "best" depends entirely on which constraint binds hardest for your team. But two things are worth saying plainly, because vendor pages won't say them for you.

First, Daytona's closed-source transition is a bigger deal than the coverage of it suggests. Open source was never just a licensing detail for a sandbox vendor — it was the actual answer to "how do I trust the isolation boundary my untrusted code runs inside." Removing that answer doesn't make Daytona a bad product; its latency story may still be the best of the four for the right workload. But teams evaluating it today should be doing so with eyes open that they're buying a proprietary dependency with an open-source-shaped reputation, not a self-hostable one.

Second, the fact that Modal and Cloudflare both entered this race from adjacent platforms — general compute and edge Workers, respectively — rather than starting as sandbox-first companies is probably the more durable trend than any individual pricing or latency number. It suggests the sandbox layer is heading toward being a feature bundled into broader platforms rather than remaining a standalone category, which is exactly the dynamic that made E2B and Daytona possible as independent companies in the first place. If that's right, the interesting question in another year isn't "which sandbox vendor wins" but "which of the big platforms — Cloudflare, Vercel, AWS, Modal's ML-infra peers — folds sandboxing in as a checkbox feature and starves the standalone players of the volume they need."

Which reader should pick which option

If you're building an open-source or compliance-sensitive agent product and need to be able to point at the code that isolates your users' execution, E2B is the only one of the four that currently gives you that option in practice.

If your agent's workload is dominated by short, high-frequency executions where every millisecond of cold start compounds at scale, and you can accept a proprietary dependency, Daytona's latency story may still justify it — just go in knowing what changed in June.

If your agent needs to run inference or heavy compute inside the sandboxed execution itself, Modal is the only one of the four with a real answer, and it's worth the platform lock-in if GPU access is genuinely part of your product, not a nice-to-have.

If you're already running your product on Cloudflare's stack and the idea of a fifth infrastructure vendor for one feature makes you tired, Cloudflare's Sandbox SDK is the path of least resistance — just model your included-usage allowance honestly before you ship.

What none of these four options gives you, yet, is a boring, commoditized choice the way "which object storage provider" has become. That's either the most interesting thing about this category or the biggest red flag in it, depending on how much risk your team is willing to carry on infrastructure this young.

Discussion: if you're running AI agents that execute arbitrary code in production today, has your team actually load-tested the isolation boundary of whichever sandbox you picked — tried to break out, tried a known kernel CVE against the underlying runtime — or are you trusting the vendor's isolation claims the same way you'd trust an uptime SLA?

Sources:

DEV Community