100x Faster Than Containers: What Cloudflare's Dynamic Workers Get Right About Sandboxing Agent Code

Every AI agent you ship eventually wants to run code it just wrote. Not a canned tool call — a fresh snippet, generated mid-reasoning, that calls an API, transforms a payload, or chains two services together, then disappears. The question is where that snippet executes. Put it in a container and you pay hundreds of milliseconds of boot plus hundreds of megabytes of memory for a few hundred milliseconds of actual work. Keep a warm pool around to hide the boot cost and you are now reusing sandboxes across tasks, which quietly trades away the isolation you built the sandbox for in the first place.

Cloudflare's answer, Dynamic Workers, entered open beta in March 2026: run the snippet inside a V8 isolate instead of a container. Single-digit-millisecond startup, single-digit megabytes of memory — which Cloudflare summarizes as 100 times faster than traditional containers. The verdict up front, with the evidence and the caveats behind it in the sections below:

The rest of this post decomposes the 100x claim into real numbers, compares all three primitives fairly, prices the thinner isolation boundary honestly, and ends with the two-tier sandbox rule a self-hosted PaaS should steal.

What Dynamic Workers actually are​

The primitive is the Dynamic Worker Loader API: a Cloudflare Worker instantiates a new Worker at runtime, in its own sandbox, with code specified on the fly — including code an LLM just generated. In sketch form:

const agentCode = `
  export default {
    async myAgent(param, env, ctx) {
      // generated mid-reasoning: call APIs, transform data, return
    }
  }
`;
const worker = env.LOADER.load({ code: agentCode });
const result = await worker.myAgent(input, rpcStubs);

Two details matter. First, the sandbox is the same V8-isolate mechanism Workers have run on for eight years — this is not a new isolation technology, it is an existing one newly offered at runtime granularity, so any Worker can now mint sandboxes the way it used to only serve requests. Second, the RPC stubs are the capability model: the generated code can only touch the APIs you hand it, which is what makes executing model-written code sane. No stub, no access — the snippet cannot exfiltrate through a channel it was never given.

The motivation is Code Mode, the pattern Cloudflare has pushed since last September: stop making the model chain dozens of sequential tool calls and instead have it write one function that calls APIs directly. Converting an MCP server into a TypeScript API cut token usage by 81 percent in their demo, and their Cloudflare MCP server exposes an API surface of more than 2,500 endpoints through just two tools and under 1,000 tokens. Code Mode is the demand side — agents that execute code instead of calling tools. Dynamic Workers are the supply side — somewhere cheap and fast enough for that code to run. If every end user gets an agent and every agent writes code per task, per-task containers do not scale economically; per-task isolates might.

Note the scope line Cloudflare itself draws: the company also ships a container runtime and a Sandbox SDK for the heavier cases. Isolates are positioned as the primitive for short-lived generated code, not a replacement for containers. Keep that framing — it becomes the decision rule at the end.

Three primitives, fairly compared​

Here is the head-to-head, built from the vendors' own published figures:

Two honest notes on this table. First, the microVM row has narrowed the gap enormously: Firecracker's sub-125 ms boot means the isolate advantage over microVMs is roughly 20 to 30x on cold start, not 100x — the 100x is Cloudflare's isolate-versus-container figure. Second, the Kubernetes option from March 2026, SIG Apps' Agent Sandbox Sandbox CRD, sits in the container column philosophically: a declarative, single-container environment for singleton stateful agent runtimes, built on ordinary Kubernetes primitives. It standardizes the orchestration of agent sandboxes; it does not change their startup physics.

Where the 100x survives contact with a real tool call​

A cold-start ratio is not an end-to-end speedup, and the skeptical reader is right to ask what a full tool call looks like. So here is illustrative arithmetic built from the published cold-start figures above — not a benchmark anyone ran, just addition applied to a typical snippet. Take a generated function that calls one API and transforms the response: 200 ms of execution once running.

For the short-snippet case the ranking holds end to end: the isolate answers in roughly two-fifths the time of the container. Now the sensitivity the headline does not mention — stretch the execution to 5 seconds (a test-suite run, a build step):

At multi-second executions the cold-start advantage dilutes toward 1x for every primitive. That is Amdahl's law doing its usual work, and it draws the applicability boundary precisely: isolates dominate exactly the workload they were built for — sub-second generated snippets — and the advantage evaporates exactly where isolates cannot run anyway (long, stateful, binary-dependent work). The 100x is real but narrow, which is fine, because the agent-tool-call shape it targets is narrow too.

There is a second, economic half to the comparison that the table hides. Containers are so expensive per instance that operators keep them warm and reuse them across tasks — and reuse across tasks is a security compromise wearing an optimization costume. Isolates are cheap enough to mint one per snippet and throw it away, which means the fastest option is also the one with the cleanest lifecycle: fresh sandbox per untrusted input, no warm-pool cross-contamination to reason about.

The isolation bill, priced honestly​

A thinner boundary is still thinner. Three costs, none disqualifying, all load-bearing for the decision at the end.

Shared-process threat model. Tenants in isolates are separated by the V8 engine inside one process — not by processes, not by VMs. Cloudflare's own security model says this plainly: the platform cannot rely on OS or hypervisor patches the way container and VM platforms do, and must carry its own mitigations. A V8 type-confusion zero-day threatens co-tenants the way a hypervisor zero-day threatens co-guests — with no second boundary behind it.

Spectre is mitigated, not eliminated. In August 2026, researchers demonstrated a Spectre attack leaking a JWT between two co-located Workers at 12 bits per second — no V8 exploit, no sandbox escape, just valid code in one isolate reading another through speculative execution. Cloudflare's defenses (frozen and coarsened timers during CPU execution, no shared memory or multithreading exposed to scripts) slowed the leak to a trickle rather than stopping the channel. Twelve bits per second still exfiltrates a token in minutes. For first-party agent code running your own snippets, this is acceptable background risk. For mutually untrusted tenants sharing a fleet, it is the paragraph that justifies the microVM row.

The self-hosting gap. This one matters most for readers of this blog. The open-source workerd runtime does not include Cloudflare production's defense-in-depth — the V8 memory-protection-key patches, the trust-level cordons, the operational patching cadence. Upstream's own guidance says to wrap hostile code in a real sandbox such as a virtual machine when running outside Cloudflare's fleet. So "just self-host workerd and get isolate economics" does not survive contact with the threat model: the millisecond startup travels, the production isolation posture does not. Anyone offering isolate-based sandboxes to untrusted tenants on owned hardware must either rebuild that defense-in-depth or scope isolates to first-party, capability-stubbed snippets only.

The two-tier rule for a self-hosted PaaS​

The shape that falls out of all of this is two sandbox tiers, split by workload, not by vendor:

• Tier 1 — "run this snippet": short-lived, capability-stubbed, first-party. An agent's individual tool call: call an API, transform data, return. This is the isolate tier. Millisecond minting, megabyte footprint, fresh sandbox per call, RPC stubs as the capability leash. Borrow the Code Mode pattern directly: collapse tool chains into generated functions and execute them in the cheapest fresh sandbox available.
• Tier 2 — "deploy this app": long-running, stateful, untrusted. Builds, shells, servers, anything with arbitrary binaries, persistence, or GPUs. This is the kernel-isolated tier: microVMs in the E2B/Daytona mold, or the Kubernetes Sandbox CRD on your own fleet. Slower to boot, heavier per instance — and the only honest place for code you would not run in your own process.

The decision variable is snippet lifetime plus trust, not fashion. Under a second and capability-stubbed: isolates. Over seconds, stateful, GPU-backed, or mutually untrusted: a separate kernel. The failure mode to avoid is one tier for everything — containers for per-snippet execution (paying the boot tax or the warm-pool reuse compromise) or isolates for untrusted tenant code (inheriting a shared-process threat model without Cloudflare's production defenses).

For a deploy-from-chat platform specifically, the mapping is almost embarrassingly clean: the conversational "run this snippet" tool your agent uses mid-dialogue belongs in tier 1, while the "deploy this app" tool that builds and ships tenant code belongs in tier 2. Same agent, two sandboxes, chosen per call. Cloudflare drew exactly this line by shipping Dynamic Workers alongside — not instead of — its container runtime and Sandbox SDK. Imitate the portfolio, not just the headline primitive.

What to do this week​

If you operate agents on your own fleet: classify your agent's code-execution paths into the two tiers. Anything sub-second, single-language, and RPC-stubbable is a candidate for isolate-style execution — prototype it against workerd for first-party snippets, with the self-hosting caveat above firmly in mind. Everything else stays kernel-isolated, and if you run Kubernetes, the Agent Sandbox CRD is now the standard API to hang that tier on. Measure one real tool call end to end — cold start plus execution, like the arithmetic above — before believing any vendor's ratio, including the 100x in this post's title.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• Sandboxing AI agents, 100x faster (Cloudflare Blog)
• Cloudflare launches Dynamic Workers for AI agent execution (InfoWorld)
• Worker Loader API docs (Cloudflare Developers)
• Security model (Cloudflare Workers docs)
• Cloudflare Workers Spectre attack leaks JWT from co-located worker (The Hacker News, Aug 2026)
• Running Agents on Kubernetes with Agent Sandbox (Kubernetes Blog, Mar 2026)
• The 9 Best Infrastructure Platforms for Running Agentic Workloads in 2026 (Qovery)