Cloudflare’s new Dynamic Workers ditch containers to run AI agent code 100x faster

Web infrastructure giant Cloudlflare is seeking to transform the way enterprises deploy AI agents with the open beta release of Dynamic Workers, a new lightweight, isolate-based sandboxing system that it says starts in milliseconds, uses only a few megabytes of memory, and can run on the same machine — even the same thread — as the request that created it.

Compared with traditional Linux containers, the company says that makes Dynamic Workers roughly 100x faster to start and between 10x and 100x more memory efficient.

Cloudflare has spent months pushing what it calls “Code Mode,” the idea that large language models often perform better when they are given an API and asked to write code against it, rather than being forced into one tool call after another.

The company says converting an MCP server into a TypeScript API can cut token usage by 81%, and it is now positioning Dynamic Workers as the secure execution layer that makes that approach practical at scale.

For enterprise technical decision makers, that is the bigger story. Cloudflare is trying to turn sandboxing itself into a strategic layer in the AI stack. If agents increasingly generate small pieces of code on the fly to retrieve data, transform files, call services or automate workflows, then the economics and safety of the runtime matter almost as much as the capabilities of the model. Cloudflare’s pitch is that containers and microVMs remain useful, but they are too heavy for a future where millions of users may each have one or more agents writing and executing code constantly.

The history of modern isolated runtime environments

To understand why Cloudflare is doing this, it helps to look at the longer arc of secure code execution. Modern sandboxing has evolved through three main models, each trying to build a better digital box: smaller, faster and more specialized than the one before it.

The first model is the isolate. Google introduced the v8::Isolate API in 2011 so the V8 JavaScript engine could run many separate execution contexts efficiently inside the same process. In effect, a single running program could spin up many small, tightly separated compartments, each with its own code and variables.

In 2017, Cloudflare adapted that browser-born idea for the cloud with Workers, betting that the traditional cloud stack was too slow for instant, globally distributed web tasks. The result was a runtime that could start code in milliseconds and pack many environments onto a single machine. The trade-off is that isolates are not full computers. They are strongest with JavaScript, TypeScript and WebAssembly, and less natural for workloads that expect a traditional machine environment.

The second model is the container. Containers had been technically possible for years through Linux kernel features, but the company Docker turned them into the default software packaging model when it popularized them in 2013.

Containers solved a huge portability problem by letting developers package code, libraries and settings into a predictable unit that could run consistently across systems. That made them foundational to modern cloud infrastructure. But they are relatively heavy for the sort of short-lived tasks Cloudflare is talking about here. The company says containers generally take hundreds of milliseconds to boot and hundreds of megabytes of memory to run, which becomes costly and slow when an AI-generated task only needs to execute for a moment.

The third model is the microVM. Popularized by AWS Firecracker in 2018, microVMs were designed to offer stronger machine-like isolation than containers without the full bulk of a traditional virtual machine. They are attractive for running untrusted code, which is why they have started to show up in newer AI-agent systems such as Docker Sandboxes. But they still sit between the other two models: stronger isolation and more flexibility than an isolate, but slower and heavier as well.

That is the backdrop for Cloudflare’s pitch. The company is not claiming containers disappear, or that microVMs stop mattering. It is claiming that for a growing class of web-scale, short-lived AI-agent workloads, the default box has been too heavy, and the isolate may now be the better fit.

Cloudflare’s case against the container bottleneck

Cloudflare’s argument is blunt: for “consumer-scale” agents, containers are too slow and too expensive. In the company’s framing, a container is fine when a workload persists, but it is a bad fit when an agent needs to run one small computation, return a result and disappear. Developers either keep containers warm, which costs money, or tolerate cold-start delay, which hurts responsiveness. They may also be tempted to reuse a live sandbox across multiple tasks, which weakens isolation.

Dynamic Worker Loader is Cloudflare’s answer. The API allows one Worker to instantiate another Worker at runtime with code provided on the fly, usually by a language model. Because these dynamic Workers are built on isolates, Cloudflare says they can be created on demand, run one snippet of code, and then be thrown away immediately afterward. In many cases, they run on the same machine and even the same thread as the Worker that created them, which removes the need to hunt for a warm sandbox somewhere else on the network.

The company is also pushing hard on scale. It says many container-based sandbox providers limit concurrent sandboxes or the rate at which they can be created, while Dynamic Workers inherit the same platform characteristics that already let Workers scale to millions of requests per second. In Cloudflare’s telling, that makes it possible to imagine a world where every user-facing AI request gets its own fresh, isolated execution environment without collapsing under startup overhead.

Security remains the hardest part

Cloudflare does not pretend this is easy to secure. In fact, the company explicitly says hardening an isolate-based sandbox is trickier than relying on hardware virtual machines, and notes that security bugs in V8 are more common than those in typical hypervisors. That is an important admission, because the entire thesis depends on convincing developers that an ultra-fast software sandbox can also be safe enough for AI-generated code.

Cloudflare’s response is that it has nearly a decade of experience doing exactly that. The company points to automatic rollout of V8 security patches within hours, a custom second-layer sandbox, dynamic cordoning of tenants based on risk, extensions to the V8 sandbox using hardware features like MPK, and research into defenses against Spectre-style side-channel attacks. It also says it scans code for malicious patterns and can block or further sandbox suspicious workloads automatically. Dynamic Workers inherit that broader Workers security model.

That matters because without the security story, the speed story sounds risky. With it, Cloudflare is effectively arguing that it has already spent years making isolate-based multi-tenancy safe enough for the public web, and can now reuse that work for the age of AI agents.

Code Mode: from tool orchestration to generated logic

The release makes the most sense in the context of Cloudflare’s larger Code Mode strategy. The idea is simple: instead of giving an agent a long list of tools and asking it to call them one by one, give it a programming surface and let it write a short TypeScript function that performs the logic itself. That means the model can chain calls together, filter data, manipulate files and return only the final result, rather than filling the context window with every intermediate step. Cloudflare says that cuts both latency and token usage, and improves outcomes especially when the tool surface is large.

The company points to its own Cloudflare MCP server as proof of concept. Rather than exposing the full Cloudflare API as hundreds of individual tools, it says the server exposes the entire API through two tools — search and execute — in under 1,000 tokens because the model writes code against a typed API instead of navigating a long tool catalog.

That is a meaningful architectural shift. It moves the center of gravity from tool orchestration toward code execution. And it makes the execution layer itself far more important.

Why Cloudflare thinks TypeScript beats HTTP for agents

One of the more interesting parts of the launch is that Cloudflare is also arguing for a different interface layer. MCP, the company says, defines schemas for flat tool calls but not for programming APIs. OpenAPI can describe REST APIs, but it is verbose both in schema and in usage. TypeScript, by contrast, is concise, widely represented in model training data, and can communicate an API’s shape in far fewer tokens.

Cloudflare says the Workers runtime can automatically establish a Cap’n Web RPC bridge between the sandbox and the harness code, so a dynamic Worker can call those typed interfaces across the security boundary as if it were using a local library. That lets developers expose only the exact capabilities they want an agent to have, without forcing the model to reason through a sprawling HTTP interface.

The company is not banning HTTP. In fact, it says Dynamic Workers fully support HTTP APIs. But it clearly sees TypeScript RPC as the cleaner long-term interface for machine-generated code, both because it is cheaper in tokens and because it gives developers a narrower, more intentional security surface.

Credential injection and tighter control over outbound access

One of the more practical enterprise features in the release is globalOutbound, which lets developers intercept every outbound HTTP request from a Dynamic Worker. They can inspect it, rewrite it, inject credentials, respond to it directly, or block it entirely. That makes it possible to let an agent reach outside services while never exposing raw secrets to the generated code itself.

Cloudflare positions that as a safer way to connect agents to third-party services requiring authentication. Instead of trusting the model not to mishandle credentials, the developer can add them on the way out and keep them outside the agent’s visible environment. In enterprise settings, that kind of blast-radius control may matter as much as the performance gains.

More than a runtime: the helper libraries matter too

Another reason the announcement lands as more than a low-level runtime primitive is that Cloudflare is shipping a toolkit around it. The @cloudflare/codemode package is designed to simplify running model-generated code against AI tools using Dynamic Workers. At its core is DynamicWorkerExecutor(), which sets up a purpose-built sandbox with code normalization and direct control over outbound fetch behavior. The package also includes utility functions to wrap an MCP server into a single code() tool or generate MCP tooling from an OpenAPI spec.

The @cloudflare/worker-bundler package handles the fact that Dynamic Workers expect pre-bundled modules. It can resolve npm dependencies, bundle them with esbuild, and return the module map the Worker Loader expects. The @cloudflare/shell package adds a virtual filesystem backed by a durable Workspace using SQLite and R2, with higher-level operations like read, write, search, replace, diff and JSON update, plus transactional batch writes.

Taken together, those packages make the launch feel much more complete. Cloudflare is not just exposing a fast sandbox API. It is building the surrounding path from model-generated logic to packaged execution to persistent file manipulation.

Isolates versus microVMs: two different homes for agents

Cloudflare’s launch also highlights a growing split in the AI-agent market. One side emphasizes fast, disposable, web-scale execution. The other emphasizes deeper, more persistent environments with stronger machine-like boundaries.

Docker Sandboxes is a useful contrast. Rather than using standard containers alone, it uses lightweight microVMs to give each agent its own private Docker daemon, allowing the agent to install packages, run commands and modify files without directly exposing the host system. That is a better fit for persistent, local or developer-style environments. Cloudflare is optimizing for something different: short-lived, high-volume execution on the global web.

So the trade-off is not simply security versus speed. It is depth versus velocity. MicroVMs offer a sturdier private fortress and broader flexibility. Isolates offer startup speed, density and lower cost at internet scale. That distinction may become one of the main dividing lines in agent infrastructure over the next year.

Community reaction: hype, rivalry and the JavaScript catch

The release also drew immediate attention from developers on X, with reactions that captured both excitement and skepticism.

Brandon Strittmatter, a Cloudflare product lead and founder of Outerbase, called the move “classic Cloudflare,” praising the company for “changing the current paradigm on containers/sandboxes by reinventing them to be lightweight, less expensive, and ridiculously fast.”

Zephyr Cloud CEO Zack Chapple called the release “worth shouting from the mountain tops.”

But the strongest caveat surfaced quickly too: this system works best when the agent writes JavaScript. Cloudflare says Workers can technically run Python and WebAssembly, but that for small, on-demand snippets, “JavaScript will load and run much faster.”

That prompted criticism from YouTuber and ThursdAI podcast host Alex Volkov, who wrote that he “got excited… until I got here,” reacting to the language constraint.

Cloudflare’s defense is pragmatic and a little provocative. Humans have language loyalties, the company argues, but agents do not. In Cloudflare’s words, “AI will write any language you want it to,” and JavaScript is simply well suited to sandboxed execution on the web. That may be true in the narrow sense the company intends, but it also means the platform is most naturally aligned with teams already comfortable in the JavaScript and TypeScript ecosystem.

The announcement also triggered immediate competitive positioning. Nathan Flurry of Rivet used the moment to contrast his Secure Exec product as an open-source alternative that supports a broader range of platforms including Vercel, Railway and Kubernetes rather than being tied closely to Cloudflare’s own stack.

That reaction is worth noting because it shows how quickly the sandboxing market around agents is already splitting between vertically integrated platforms and more portable approaches.

Early use cases: AI apps, automations and generated platforms

Cloudflare is pitching Dynamic Workers for much more than quick code snippets. The company highlights Code Mode, AI-generated applications, fast development previews, custom automations and user platforms where customers upload or generate code that must run in a secure sandbox.

One example it spotlights is Zite, which Cloudflare says is building an app platform where users interact through chat while the model writes TypeScript behind the scenes to build CRUD apps, connect to services like Stripe, Airtable and Google Calendar, and run backend logic. Cloudflare quotes Zite CTO and co-founder Antony Toron saying Dynamic Workers “hit the mark” on speed, isolation and security, and that the company now handles “millions of execution requests daily” using the system.

Even allowing for vendor framing, that example gets at the company’s ambition. Cloudflare is not just trying to make agents a bit more efficient. It is trying to make AI-generated execution environments cheap and fast enough to sit underneath full products.

Pricing and availability

Dynamic Worker Loader is now in open beta and available to all users on the Workers Paid plan. Cloudflare says dynamically loaded Workers are priced at $0.002 per unique Worker loaded per day, in addition to standard CPU and invocation charges, though that per-Worker fee is waived during the beta period. For one-off code generation use cases, the company says that cost is typically negligible compared with the inference cost of generating the code itself.

That pricing model reinforces the larger thesis behind the product: that execution should become a small, routine part of the agent loop rather than a costly special case.

The bigger picture

Cloudflare’s launch lands at a moment when AI infrastructure is becoming more opinionated. Some vendors are leaning toward long-lived agent environments, persistent memory and machine-like execution. Cloudflare is taking the opposite angle. For many workloads, it argues, the right agent runtime is not a persistent container or a tiny VM, but a fast, disposable isolate that appears instantly, executes one generated program, and vanishes.

That does not mean containers or microVMs go away. It means the market is starting to split by workload. Some enterprises will want deeper, more persistent environments. Others — especially those building high-volume, web-facing AI systems — may want an execution layer that is as ephemeral as the requests it serves.

Cloudflare is betting that this second category gets very large, very quickly. And if that happens, Dynamic Workers may prove to be more than just another Workers feature. They may be Cloudflare’s attempt to define what the default execution layer for internet-scale AI agents looks like.