Cloudflare Dynamic Workers: Runtime fuer AI-Agent-Code

25. März 2026

Problem

Wenn ein AI-Agent Code generiert und ausfuehrt -- etwa um mehrere API-Aufrufe in einer einzigen Funktion zu buendeln statt sie sequenziell als Tool-Calls abzuarbeiten -- braucht dieser Code eine sichere Ausfuehrungsumgebung. Ein direktes eval() im eigenen Prozess ist keine Option: ein Angreifer koennte das Modell per Prompt-Injection dazu bringen, schaedlichen Code einzuschleusen. Container loesung dieses Problem, sind aber mit Kosten verbunden: Startzeiten von mehreren hundert Millisekunden, hunderte Megabyte Speicher pro Instanz, und die Versuchung, Container aus Performancegruenden wiederzuverwenden -- was die Sicherheitsisolation aushebelt.

Was Dynamic Workers sind

Cloudflare hat am 24. Maerz 2026 den Dynamic Worker Loader in die offene Beta gebracht (verfuegbar fuer alle zahlenden Workers-Nutzer). Die API erlaubt es, innerhalb eines bestehenden Workers einen neuen Worker mit zur Laufzeit uebergebenem Code zu starten -- vollstaendig isoliert, ohne Deploymentprozess, ohne Konfiguration.

Die technische Grundlage sind V8-Isolates: dieselbe Sandbox-Technologie, auf der die gesamte Workers-Plattform seit acht Jahren laeuft. Ein Isolate ist eine Instanz der V8-JavaScript-Engine (die gleiche wie in Google Chrome), die ohne Betriebssystem-Overhead in wenigen Millisekunden startet und nur wenige Megabyte Speicher benoetigt.

Kennzahlen im Vergleich zu Containern:

	Container	Dynamic Worker
Startzeit	~300–500 ms	~wenige ms
Speicher	~100–500 MB	~wenige MB
Kaltstart-Overhead	hoch	vernachlaessigbar
Parallelitaet	begrenzt	unbegrenzt

Wie es funktioniert

Ein Dynamic Worker wird ueber ein LOADER-Binding instanziiert. Der generierende Worker uebergibt den Code als String und definiert, welche Faehigkeiten die Sandbox erhaelt -- etwa RPC-Stubs fuer erlaubte APIs oder einen globalOutbound-Handler fuer HTTP-Anfragen:

let worker = env.LOADER.load({
  compatibilityDate: "2026-03-01",
  mainModule: "agent.js",
  modules: { "agent.js": agentCode },

  // Nur diese RPC-API ist zugaenglich
  env: { CHAT_ROOM: chatRoomRpcStub },

  // Kein Internetzugang
  globalOutbound: null,
});

await worker.getEntrypoint().myAgent(param);

Der Dynamic Worker laeuft auf demselben Rechner -- oft im selben Thread -- wie der aufrufende Worker. Keine Netzwerkkommunikation, keine Latenz durch geografische Verteilung. Die Plattform skaliert automatisch auf Millionen gleichzeitiger Isolate-Instanzen.

TypeScript als API-Sprache fuer Agents

Statt OpenAPI-Spezifikationen (die viele Token benoetigen) empfiehlt Cloudflare TypeScript-Interfaces zur Beschreibung der API-Faehigkeiten, die dem Agent zur Verfuegung stehen. Die Workers Runtime baut automatisch eine Cap'n Web RPC-Bruecke zwischen dem Sandbox-Code und dem Host-Code auf -- der Agent-Code ruft Methoden auf, ohne zu wissen, dass sie ueber eine Sicherheitsgrenze hinweg ausgefuehrt werden.

Verglichen mit einem aequivalenten OpenAPI-Dokument ist ein TypeScript-Interface wesentlich kuerzer und damit Token-effizienter -- ein relevanter Faktor, da kuerzere API-Beschreibungen direkt in den Context Window eingefuegt werden koennen.

Sicherheitsarchitektur

Cloudflare baut seit acht Jahren auf V8-Isolates als Sandbox. Der Betreiber profitiert automatisch von:

V8-Sicherheitspatches, die laut Cloudflare schneller als Chrome selbst eingespielt werden
Einer zweiten Sandbox-Schicht mit dynamischem Cordoning basierend auf Risikobewertungen
Erweiterungen des V8-Sandboxes durch Hardware-Features (MPK)
Speziellen Abwehrmassnahmen gegen Spectre-Angriffe
Automatischen Code-Scans auf Schadsoftware-Muster

HTTP-Credential-Injection ist ebenfalls moeglich: ueber einen globalOutbound-Hook koennen ausgehende Requests abgefangen und mit Auth-Keys versehen werden -- der Agent-Code bekommt die Credentials nie zu sehen.

Begleitende Bibliotheken

Cloudflare hat drei Pakete veroeffentlicht, die auf Dynamic Workers aufbauen:

@cloudflare/codemode: Vereinfacht das Ausfuehren von LLM-generiertem Code gegen definierte Tool-APIs. Kernfunktion DynamicWorkerExecutor() uebernimmt Code-Normalisierung und den Sandbox-Lifecycle. Integriert sich mit dem Vercel AI SDK ueber generateText.

@cloudflare/worker-bundler: Bundelt Quellcode inklusive npm-Abhaengigkeiten fuer Dynamic Workers vor. Nutzt esbuild, unterstuetzt auch Full-Stack-Apps mit statischen Assets.

@cloudflare/shell: Stellt dem Agent ein virtuelles Dateisystem bereit. Operationen wie Suchen, Ersetzen, Diff und JSON-Manipulation werden als typisierte RPC-Methoden angeboten. Persistenz ueber SQLite und R2, transaktionale Batch-Writes mit automatischem Rollback.

Anwendungsfaelle

Code Mode: Das Muster, bei dem ein Agent anstatt sequentieller Tool-Calls eine einzelne TypeScript-Funktion generiert, die mehrere API-Aufrufe kettet. Diese Funktion laeuft im Dynamic Worker; nur das Endergebnis, nicht jeder Zwischenschritt, landet im Context Window. Laut Cloudflare reduziert dies Token-Verbrauch und Latenz gleichzeitig.

MCP-Server als Code-Tool: codeMcpServer() wrapping erlaubt es, einen bestehenden MCP-Server mit einem einzigen code()-Tool zu ersetzen -- der Client sendet Code, der dann im Sandbox ausgefuehrt wird, statt einzelne Tool-Definitionen abzurufen.

Agenten-Isolation im Consumer-Massstab: Wenn jeder Endnutzer einen eigenen Agent hat, der eigenen Code ausfuehrt, sind Container schlicht zu teuer. Dynamic Workers erlauben es, pro Request eine frische Sandbox zu starten und wegzuwerfen -- ohne Warmhaltekosten.

Vergleich zu anderen Execution-Environments

	Dynamic Workers	Docker/Container	AWS Lambda	E2B / Modal
Startzeit	~ms	~100–500 ms	~100 ms (kalt)	~100–300 ms
Sprachen	JS/TS, Python, Wasm	beliebig	beliebig	beliebig
Isolation	V8-Isolate + 2. Sandbox	Namespace/cgroup	MicroVM	MicroVM / Sandbox
Skalierung	unbegrenzt, automatisch	manuell / Limits	automatisch	Limits
Edge-Standorte	300+ weltweit	nein	regional	nein
Offene Beta	ja (paid Workers)	--	--	kommerziell

Der wesentliche Vorteil liegt in der Startlatenz und der nahtlosen Integration ins Workers-Oekosystem. Der Nachteil: der Agent muss JavaScript schreiben. Fuer Code-generierende LLMs ist das laut Cloudflare kein echtes Hindernis -- Trainingsdaten fuer JavaScript sind immens.

Open Beta: April-Update

InfoQ berichtet am 1. April 2026 ueber den offiziellen Open-Beta-Start von Dynamic Workers. Cloudflare positioniert das Produkt jetzt explizit als Sandbox fuer AI-Agent-Code-Execution -- der primaere Use Case ist klar definiert: ein Agent generiert Code, der isoliert in einem V8-Isolate ausgefuehrt wird, und nur das Ergebnis geht zurueck.

Die Leistungszahlen, die Cloudflare kommuniziert: V8-Isolates starten in Millisekunden und benoetigen Megabytes statt hunderte Megabytes Speicher. Gegenueber Container-Alternativen spricht Cloudflare von "roughly 100x faster and up to 10x less memory". Diese Zahlen decken sich mit den Vergleichswerten aus der urspruenglichen Ankuendigung, werden aber jetzt offensiver als Verkaufsargument fuer den AI-Agent-Markt eingesetzt.

Der strategische Fokus ist eindeutig: Cloudflare will die Standard-Runtime fuer AI-Agent-Code-Execution werden. Nicht Webapps, nicht klassische Serverless-Functions -- sondern der spezifische Fall, dass ein LLM Code generiert, dieser Code sicher und schnell ausgefuehrt werden muss, und das Ergebnis zurueck an den Agenten fliesst.

Quellen

Nach oben