Cloudflare Dynamic Workers beta: spawn Workers at runtime, Code Mode saves 80% inference tokens, virtual filesystem for AI agents. Full developer guide.
What Dynamic Workers Change for AI Agents
Cloudflare Dynamic Workers (beta) let you spawn Workers at runtime instead of shipping every possible code path as a pre-deployed function. For AI agents that generate or adapt code on the fly, that matters: the model can decide what to run, create an isolated execution context, and tear it down when the task ends. You no longer need a fixed catalog of endpoints that try to anticipate every tool call or transformation.
The headline claim—AI code execution up to 100x faster—is less about raw language speed and more about removing cold paths that dominate agent loops. Static deployments, long-lived containers, and round-trips through general-purpose runtimes all add latency between “model decided” and “result available.” Spawning a Worker when you need it keeps that path short and scoped to one unit of work.
Code Mode: Fewer Tokens, Same Intent
Code Mode is the companion idea for the inference side of the loop. Instead of stuffing large tool schemas, intermediate state, and prose instructions into every model call, you push more of the work into executable code the agent writes and runs. The model reasons about structure and control flow; the runtime does the bulk of the data handling. That design is why Code Mode can save around 80% of inference tokens on agent-style workloads: tokens spent describing steps become tokens spent only when the model must choose or branch.
In practice, treat the model as a planner and code author, not a calculator. Prefer short prompts that ask for a function or script, run that code in a Dynamic Worker, then feed back only the result (or a tight error summary). Retry on failure with the error payload, not a full re-explanation of the original task.
Virtual Filesystem for Agent State
A virtual filesystem gives agents a familiar place to read, write, and stage artifacts without wiring a custom object store for every session. Scripts can drop intermediate JSON, partial transforms, or generated modules into paths that subsequent steps can open. That matches how developers already think about multi-step jobs and reduces pressure to re-serialize everything through the chat transcript.
- Scope the VFS per agent session or task so files cannot leak across tenants.
- Write small, named intermediates; avoid dumping huge blobs into model context.
- Clean up or expire paths when the Worker completes so storage does not grow unbounded.
- Pass paths and checksums back to the model instead of full file contents when possible.
A Practical Integration Pattern
Start with a thin orchestrator: accept a user goal, call the model in Code Mode for a single bounded script, spawn a Dynamic Worker to run it against the virtual filesystem, then decide whether another generation step is needed. Keep each Worker single-purpose—one transform, one fetch-and-normalize, one validation pass. Parallel spawns work well when steps are independent; serialize when later code depends on earlier files.
Guardrails stay the same as any untrusted-code path: timeouts, CPU and memory limits, no ambient credentials in the sandbox, and explicit allowlists for outbound network access. Log spawn reason, code hash, duration, and exit status so you can debug agent loops without reconstructing them from free-form chat. Measure token use and end-to-end latency per step; if Code Mode savings are real but wall-clock is still high, the bottleneck is usually over-serialized steps or oversized files forced back into the model context rather than left on the virtual filesystem.