Cloudflare’s 100x Faster AI Agent Sandbox

Cloudflare says a new sandbox for AI-generated code can start in a few milliseconds and use only a few megabytes of memory. That is a very different profile from container-based sandboxes, which often take hundreds of milliseconds and hundreds of megabytes. For agent builders, those numbers decide whether code execution feels instant or painfully slow.

The company’s answer is Dynamic Worker Loader, an open beta feature for Cloudflare Workers. It lets an app create a fresh Worker at runtime, feed it AI-generated JavaScript, and keep it isolated from the host app and the wider internet unless you explicitly allow access.

Why Cloudflare is betting on code, not tool calls

Cloudflare’s post builds on an idea it introduced last September called Code Mode. The basic argument is simple: agents should often write code that calls APIs instead of making one tool call at a time. That matters because code can batch work, filter data locally, and cut token use. Cloudflare says converting an MCP server into a TypeScript API cut token usage by 81%, and another setup exposed the full Cloudflare API with just two tools and under 1,000 tokens.

That is a big deal for agent design. A flat tool list works for simple tasks, but it gets awkward when the agent needs to do real programming against an API. Cloudflare’s take is that the agent should write a small program, run it in a sandbox, and call typed APIs from inside that sandbox.

• Code Mode reduced token usage by 81% in Cloudflare’s example.
• The Cloudflare API exposure used two tools and under 1,000 tokens.
• Dynamic Worker Loader is now in open beta for paid Workers users.

That approach also fits the way modern LLMs behave. They already generate JavaScript well, and JavaScript is the native language of the web. Cloudflare is betting that if the agent is going to write code on demand, JavaScript is the fastest path from prompt to execution.

Why isolates beat containers on speed

The technical heart of the post is Cloudflare’s long-running isolate architecture. An isolate is a V8 execution environment, the same JavaScript engine used by Google Chrome. Cloudflare says an isolate starts in a few milliseconds and uses a few megabytes of memory. Its comparison is blunt: that is around 100x faster and 10x to 100x more memory efficient than a typical container.

That difference changes the economics of agents. If every user request can spin up its own sandbox, run a tiny program, and then disappear, you do not need to keep warm containers around just to hide startup latency. Cloudflare also says Dynamic Workers can run in any of its hundreds of locations around the world, often on the same machine and even the same thread as the Worker that created them.

“An isolate takes a few milliseconds to start and uses a few megabytes of memory. That’s around 100x faster and 10x-100x more memory efficient than a typical container.” — Cloudflare blog post, “Sandboxing AI agents, 100x faster”

That quote matters because it frames the whole product bet. Containers are flexible, but they are heavy. For consumer-scale agents, where many users may each spawn many short-lived tasks, the overhead starts to dominate the experience and the bill.

TypeScript beats OpenAPI when the agent is writing code

Cloudflare also makes a strong case for TypeScript as the interface language for agent-facing APIs. The company contrasts a small TypeScript interface with a much longer OpenAPI document for the same chat room API. The point is not that OpenAPI is bad. The point is that TypeScript is shorter, easier for an LLM to emit, and easier for a human to read when the agent is expected to write actual code.

In the article’s example, a chat room API needs methods for history, subscription, and posting messages. In TypeScript, that fits in a compact interface. In OpenAPI, the same functionality expands into paths, schemas, request bodies, response definitions, and event-stream details. For an agent, every extra token is a tax.

• TypeScript lets Cloudflare describe the chat room API in a few lines.
• The equivalent OpenAPI spec spans many more lines and concepts.
• Cloudflare says the Workers runtime wires the sandbox to the host through Cap’n Web RPC.

There is also a security angle here. If you define your own TypeScript wrapper, you can expose only the methods you want the agent to use. That is cleaner than trying to filter arbitrary HTTP requests, where headers, query parameters, and body fields can all matter. The article argues that a narrow wrapper is easier to reason about and easier to secure.

How the sandbox handles HTTP and secrets

Cloudflare does not limit Dynamic Worker Loader to RPC-style APIs. It also supports HTTP through a globalOutbound hook, which can inspect, rewrite, block, or answer outbound requests. That opens the door to credential injection, where the host adds auth headers on the way out so the agent never sees the secret.

This is the part that should make agent builders pay attention. A useful agent needs access to external systems, but handing the model raw credentials is asking for trouble. Cloudflare’s design keeps secrets outside the generated code while still letting the code reach the service.

• Cloudflare Workers bindings can expose controlled capabilities.
• MCP handles flat tool schemas, while TypeScript covers richer programming APIs.
• HTTP request interception lets the host rewrite or block traffic before it leaves the sandbox.

That design choice also explains why Cloudflare keeps pushing code over tool calls. Once the agent is writing a program, a TypeScript interface is a better fit than a pile of individual HTTP endpoints. The host can still enforce policy at the network boundary, but the agent gets a programming model instead of a menu of buttons.

What this means for agent builders right now

The practical takeaway is that Cloudflare is trying to make short-lived agent execution cheap enough to use per request. If you are building an agent that summarizes messages, transforms data, or calls a few APIs, the combination of isolates, typed APIs, and runtime code loading is attractive. You get lower startup cost, less memory overhead, and a smaller attack surface than a container you keep alive for reuse.

There is still a tradeoff. Dynamic Workers are JavaScript-first, and that will not suit every team. Some developers will still want Python libraries or a full Linux environment. Cloudflare knows that, which is why it also offers containers and a Sandbox SDK. But for the narrow job of running AI-generated glue code, its argument is hard to ignore.

If Cloudflare’s numbers hold in real deployments, the next wave of agents may stop treating sandboxes as a special infrastructure layer and start treating them like a normal runtime primitive. The interesting question is whether other platforms will match the same isolate economics, or whether this becomes a Cloudflare-specific advantage for agent-heavy products.

For now, the actionable move is clear: if your agent only needs a small amount of code, typed API access, and strict isolation, try the runtime that starts in milliseconds before you reach for a container. That may save you more in latency and memory than any prompt tweak ever will.