SYSTEM Cited by 3 sources
Dynamic Workers¶
Dynamic Workers is Cloudflare's per-request isolate-spawning variant of Workers: a fresh V8 isolate minted at runtime, in milliseconds, with a few megabytes of memory, used once, and thrown away. Cloudflare's canonical substrate for running LLM-generated code safely. Introduced in the Dynamic Workers blog post and productised in the 2026-04-15 Project Think launch as Tier 1 of the execution ladder.
Properties¶
| Dimension | Container | Dynamic Worker |
|---|---|---|
| Startup | seconds | milliseconds |
| Memory | hundreds of MB min | a few MB |
| Lifecycle | managed by user | one-shot per request |
| Ambient authority | full network / FS by default | globalOutbound: null; none |
"That's roughly 100× faster and up to 100× more memory-efficient than a container. You can start a new one for every single request, run a snippet of code, and throw it away." (Source: Project Think.)
Capability model — no ambient authority¶
The load-bearing design choice:
"Dynamic Workers begin with almost no ambient authority (
globalOutbound: null, no network access) and the developer grants capabilities explicitly, resource by resource, through bindings. We go from asking 'how do we stop this thing from doing too much?' to 'what exactly do we want this thing to be able to do?'"
This is concepts/capability-based-sandbox in a serverless isolate — capabilities are the default-deny baseline; the developer adds them resource by resource (a specific R2 bucket, a specific fetch origin, a specific DO namespace) rather than configuring a deny-list on a general-purpose machine.
Role in Project Think's execution ladder¶
Dynamic Workers occupy Tier 1 of Project Think's five-tier execution ladder:
| Tier | Capability | Substrate |
|---|---|---|
| 0 | Durable virtual filesystem | DO SQLite + R2 |
| 1 | LLM-generated JavaScript, no network | Dynamic Workers |
| 2 | + npm at runtime |
Dynamic Workers + @cloudflare/worker-bundler |
| 3 | + headless browser | Dynamic Workers + Browser Rendering |
| 4 | + full OS sandbox | Cloudflare Sandbox |
Tiers 2 and 3 are still Dynamic Workers with additional
capabilities granted — an npm binding and a Browser Rendering
binding, respectively. Tier 4 transitions to the container-based
Sandbox for full toolchains (git, cargo, test runners).
Role in Code Mode¶
systems/code-mode is the consumption-side pattern; Dynamic
Workers are the execution-side substrate. When a model writes
TypeScript against a typed MCP API, the code is dispatched to a
Dynamic Worker for execution — one isolate per code-run, discarded
after returning the result. Cloudflare's API MCP server
demonstrates this at scale: two tools (search() /
execute()) covering ~3,000 operations in ~1,000 tokens vs
~1.17M for the naive schema-per-endpoint baseline (99.9%
reduction).
Role in self-authored extensions¶
When a Project Think agent writes its own tool at runtime, the
generated TypeScript runs in a Dynamic Worker bundled by
@cloudflare/worker-bundler.
The extension manifest declares permissions
({network: ["api.github.com"], workspace: "read-write"}) — the
Dynamic Worker's capability-model posture is what makes the
manifest enforceable rather than advisory. See
concepts/self-authored-extension.
Contrast with Cloudflare Containers / Sandbox SDK¶
- Workers: long-lived isolate per script; the Worker's lifetime spans many requests; warm- isolate routing.
- Dynamic Workers: one isolate per run; torn down after.
- Containers + Sandbox SDK: full Linux container lifecycle with filesystem + long-running processes + full toolchains.
The three compose: Think's Tier 0 filesystem uses DO+R2; Tiers
1-3 use Dynamic Workers; Tier 4 uses Sandbox containers — the
agent escalates only as needed.
Relationship to Facets¶
Facets is Cloudflare's primitive for child DOs that can host Dynamic Workers; Project Think's sub-agent abstraction is built on top (each sub-agent is a co-located child DO with its own SQLite and a function-call-latency RPC surface). Facets is the hybrid — DO + Dynamic Worker — that makes "agent writes + runs its own tool" one substrate move rather than two orchestrations.
Seen in¶
- sources/2026-04-15-cloudflare-project-think-building-the-next-generation-of-ai-agents
— canonical wiki instance. Tier 1 of the Project Think execution
ladder; the 100×-faster / 100×-more-memory-efficient-than-a-
container claim;
globalOutbound: nullcapability-model posture; substrate for Code Mode execution and self-authored extensions. - sources/2026-04-20-cloudflare-internal-ai-engineering-stack — referenced as one of the secure code-execution substrates Cloudflare's internal agents use.
- sources/2026-04-01-cloudflare-emdash-wordpress-spiritual-successor — plugin-hosting deployment. EmDash runs each CMS plugin as a Dynamic Worker with a capability manifest; canonical wiki instance of Dynamic Workers as a third-party-plugin runtime (vs. Project Think's LLM-generated-code runtime). Same capability-sandbox posture applied to a new surface: patterns/capability-manifest-plugin-isolation + patterns/per-request-isolate-per-plugin. Extends the Dynamic Workers use-case catalogue from "LLM agents" to "CMS extensions".
Related¶
- systems/cloudflare-workers — the long-lived-isolate parent tier Dynamic Workers descends from.
- systems/v8-javascript-engine — the isolate runtime.
- systems/project-think — the SDK that wires Dynamic Workers into Tier 1 of the execution ladder.
- systems/code-mode — consumption pattern whose execution substrate is Dynamic Workers.
- systems/cloudflare-sandbox-sdk — Tier 4 alternative when the workload requires full OS semantics.
- systems/cloudflare-containers — the container substrate under Sandbox SDK.
- concepts/capability-based-sandbox — the no-ambient-authority posture Dynamic Workers enforce.
- concepts/execution-ladder — the five-tier escalation this primitive sits inside.
- concepts/micro-vm-isolation — sibling isolation mechanism at the VM tier.
- patterns/code-generation-over-tool-calls — the pattern whose safe execution relies on Dynamic Workers' per-request-isolate property.
- patterns/capability-manifest-plugin-isolation — the composed primitive pattern EmDash uses; per-plugin Dynamic Worker + capability manifest.
- patterns/per-request-isolate-per-plugin — the Dynamic-Workers-specialised plugin-hosting pattern.
- systems/workerd — the open-source runtime that implements the Dynamic Workers isolate model.
- systems/emdash — CMS that hosts plugins as Dynamic Workers.
- concepts/capability-manifest — the declarative install-time contract Dynamic-Worker-hosted plugins use.
- companies/cloudflare — operator.