Cloudflare opened its Dynamic Worker Loader to all paid Workers users on March 24, putting isolate-based sandboxing in direct competition with the container-based approach that dominates AI agent infrastructure. The pitch is blunt: V8 isolates start in single-digit milliseconds, use a few megabytes of RAM, and can be created and destroyed per-request without warm pools or concurrency caps. Cloudflare claims that's roughly 100x faster and up to 100x more memory-efficient than a typical container.
Those numbers come from Cloudflare's own comparisons, and the company isn't naming specific competitors. But the targets are obvious. E2B, Modal, Fly.io Sprites, Daytona: the entire sandbox market that has coalesced around Firecracker microVMs and Docker-based isolation over the past two years. Every one of them measures cold starts in hundreds of milliseconds. Cloudflare is saying it can do the same job in single digits.
The actual product
Dynamic Worker Loader is an API that lets one Cloudflare Worker instantiate another Worker at runtime, with code provided on the fly. The new Worker runs in its own V8 isolate, inheriting the same sandboxing that Cloudflare has used to run its entire edge platform since Workers launched in 2017. In most cases, the dynamic Worker runs on the same machine (same thread, even) as the Worker that created it. There's no scheduler hunting for a warm sandbox somewhere across the network.
You can pass in JavaScript code as a string, give the sandbox access to specific RPC bindings, and block or intercept all outbound network requests. That last part matters. The sandbox can call your typed APIs but can't phone home to some random endpoint, which is exactly the isolation model you'd want when running LLM-generated code.
Pricing lands at $0.002 per unique Worker loaded per day, on top of standard CPU and invocation charges. During the beta period that fee is waived. For one-off code generation use cases, where every Worker is essentially disposable, Cloudflare argues the execution cost is negligible next to the inference cost of generating the code in the first place. That framing is clever, and probably accurate for most workloads.
Why JavaScript?
Here's where Cloudflare makes its most interesting (and most debatable) argument. Dynamic Workers only run JavaScript. Python and WebAssembly are technically supported in Workers, but for small, on-the-fly code snippets, Cloudflare says JavaScript loads and runs faster. And then they say something that's hard to argue with: the agent doesn't care what language it writes.
LLMs have enormous JavaScript training data. TypeScript type definitions are more token-efficient than OpenAPI specs for describing APIs. The blog post includes a side-by-side comparison: a ChatRoom API described in TypeScript takes maybe 15 lines, the equivalent OpenAPI spec sprawls past 60. For an agent that needs to understand an API surface before writing code against it, fewer tokens means lower cost and (probably) better output.
But JavaScript-only is still a real constraint. A huge chunk of the AI agent ecosystem lives in Python. Data science workflows, ML pipelines, scientific computing: none of that runs in V8. Cloudflare is betting that the "agent writes disposable code" use case is fundamentally different from "developer builds a persistent application," and for that specific use case, JavaScript wins on startup speed and sandboxing.
I'm not sure they're wrong. But I'm not sure the market agrees yet.
The security question nobody's asking loudly enough
Isolate-based sandboxing has a complicated security history. V8 is arguably the most attacked JavaScript engine on earth, and security bugs in it are more common than in traditional hypervisors. Cloudflare acknowledges this directly in the blog post, which is refreshing. Their security model relies on multiple layers: V8 isolates as the first boundary, a custom second-layer sandbox using Linux namespaces and seccomp, dynamic cordoning that separates tenants by risk level, hardware memory protection keys (MPK) for isolate-to-isolate separation, and custom Spectre mitigations.
They also claim to deploy V8 patches to production within hours of release, faster than Chrome itself. That's a strong claim and, if true, genuinely impressive given Chrome's own patch cadence. The company has been running multi-tenant V8 workloads since 2017, so there's real operational history here. Still, running arbitrary LLM-generated code is a different threat model than running developer-authored Workers. The attack surface isn't just V8 bugs; it's prompt injection leading to code that probes sandbox boundaries in creative ways.
Code Mode and the bigger play
Dynamic Workers don't exist in isolation (pun intended). They're the execution layer for Cloudflare's "Code Mode" strategy, which the company has been pushing since a September blog post argued that agents perform better when they write code against typed APIs rather than making sequential MCP tool calls. Cloudflare claims converting an MCP server into a TypeScript API cuts token usage by 81%.
Their own Cloudflare MCP server is built this way: the entire Cloudflare API exposed through just two tools, search and execute, in under 1,000 tokens. The agent writes TypeScript against a typed API, runs it in a Dynamic Worker, and returns only the final result to the context window. Intermediate steps never hit the LLM.
That 81% figure, by the way, deserves some scrutiny. It presumably compares a naive sequential tool-calling approach against an optimized code-mode approach on a specific workload. Your mileage will vary. But the directional argument, that writing code is more token-efficient than chaining tool calls, has been gaining traction across the industry. Anthropic, OpenAI, and others have been moving toward similar patterns.
The helper libraries
Cloudflare shipped three companion packages alongside the beta. @cloudflare/codemode wraps the sandbox creation logic and provides MCP server integration. @cloudflare/worker-bundler resolves npm dependencies and bundles code at runtime using esbuild. And @cloudflare/shell gives agents a virtual filesystem backed by SQLite and R2, with transactional batch writes that roll back on failure.
That last one is the most interesting. A virtual filesystem with atomic writes means an agent can modify multiple files as a single operation. If any write fails, everything rolls back. It's the kind of feature that sounds minor until you imagine an agent refactoring code across a dozen files and crashing halfway through.
Who's actually using this?
Cloudflare highlights Zite, an app platform where users build CRUD apps through a chat interface. The LLM writes TypeScript behind the scenes, each automation runs in its own Dynamic Worker, and the user never sees code. Zite's CTO, Antony Toron, says they're handling millions of execution requests daily.
That's one customer. One. For an open beta announcement, I'd want to see more evidence of production adoption. The use cases Cloudflare describes (code mode, custom automations, AI-generated applications) are compelling in theory but still early. The container-based sandbox market has years of production deployments behind it.
What's missing
No GPU support. No Python. No persistent compute that survives across requests without external state management. No support for workloads that need more than what a V8 isolate can provide. If your agent needs to run pandas, train a model, or execute a shell command, Dynamic Workers can't help.
Cloudflare would say those aren't the workloads they're targeting, and they'd be right. But the "agent sandbox" market doesn't split cleanly into isolate-shaped and container-shaped problems. Real agent workflows often need both: fast, disposable code execution for some steps, and heavier compute for others. Developers choosing Dynamic Workers will still need a container-based solution for the other half of their stack.
The FTC requires a specific date to evaluate this, and here it is: the $0.002 per Worker per day pricing takes effect after beta ends, though Cloudflare hasn't announced when that will be. If you're evaluating this for production, check the current pricing docs rather than relying on the blog post numbers.
