Cloudflare Dynamic Workers: schnelle Sandboxes für AI-Agenten

Cloudflare hat kürzlich Dynamic Workers in die offene Beta gebracht - schnelle Sandboxes für AI-Agenten. Das Unternehmen behauptet, sie seien 100-mal schneller als herkömmliche Container bei der Ausführung von AI-generiertem Code. Das ist eine ziemlich starke Aussage. Schauen wir uns an, was dahinter steckt.

Container sind zu schwer für AI-Agenten

Moderne AI-Agenten beantworten nicht nur Fragen, sie können auch Code schreiben und direkt ausführen. Ein Agent kann ein kleines Skript generieren, um eine API aufzurufen, Daten zu verarbeiten oder eine Aufgabe zu erledigen. Dieser Code muss irgendwo ausgeführt werden. Aus Sicherheitsgründen passiert das am besten in einer Sandbox, isoliert vom restlichen System.

Der Standardansatz heute: Für jede Aufgabe einen eigenen Container hochfahren. Container funktionieren, bringen aber einige Probleme mit sich:

• Der Kaltstart (Cold Start) dauert Hunderte von Millisekunden.
• Jeder Container verbraucht sehr viel Speicher.
• Um Verzögerungen zu vermeiden, hält man Container “warm”, aber dann zahlt man auch für sie, wenn sie nichts tun.
• Um zu sparen, verwendet man Container für mehrere Aufgaben wieder, was die Isolation schwächt und Sicherheitsprobleme schafft.

Wenn dein System ein paar Dutzend Nutzer hat, ist das normalerweise kein Problem. Aber wenn du ein Produkt baust, bei dem Millionen gleichzeitiger Anfragen AI-Agenten auslösen, werden Container zum Flaschenhals.

V8 Isolates statt Container

Cloudflare Dynamic Workers kommen komplett ohne Container aus. Stattdessen nutzen sie V8 Isolates. Das ist dieselbe JavaScript-Engine, die Google Chrome und die gesamte Cloudflare Workers-Plattform antreibt (die schon seit acht Jahren auf dieser Technologie läuft).

Ein paar Zahlen zum Vergleich:

Ein Dynamic Worker startet in Millisekunden, führt den Code aus, gibt das Ergebnis zurück und verschwindet. Keine warmen Pools, keine Leerlaufkosten, keine Kompromisse bei der Wiederverwendung.

Eine einfache Analogie, um das Konzept zu verstehen: Einen vollständigen Container für eine schnelle AI-Aufgabe zu starten, ist wie eine Fünf-Zimmer-Wohnung zu mieten, um einen einzigen Anruf zu machen. Ein Dynamic Worker ist die Telefonzelle. Rein, anrufen, raus, fertig.

Wie es funktioniert

Du hast einen Parent Worker (deine Hauptanwendung), der Anfragen entgegennimmt. Wenn er AI-generierten Code ausführen muss, ruft er die Dynamic Worker Loader API auf, die eine isolierte Umgebung spontan erstellt.

Nehmen wir an, du baust einen Kundenservice-Chatbot. Ein Kunde stellt eine komplexe Frage, für deren Beantwortung mehrere APIs abgefragt werden müssen. Das LLM generiert eine kurze TypeScript-Funktion, und der Parent Worker führt sie in einer Sandbox aus:

// Der Parent Worker empfängt die Kundenanfrage
const worker = env.LOADER.load({
  compatibilityDate: "2026-03-01",
  mainModule: "agent.js",
  modules: { "agent.js": llmGeneratedCode },

  // Der Sandbox nur Zugriff auf die Bestell-API geben
  env: { ORDER_API: env.ORDER_SERVICE },

  // Jeden anderen Internetzugang blockieren
  globalOutbound: null,
});

// Ausführen und Ergebnis abrufen
const result = await worker.getEntrypoint().handleQuery(customerId);

Die Sandbox bekommt nur Zugriff auf das, was du ihr explizit übergibst. Kein Internetzugang, keine Datenbank-Zugangsdaten, keine Möglichkeit, irgendetwas außerhalb der definierten Schnittstelle zu erreichen. Selbst wenn jemand das LLM dazu bringt, schädlichen Code zu generieren, begrenzt die Sandbox, was dieser Code tun kann.

Warum überhaupt Code generieren?

Für eine einfache Anfrage wie “Wo ist meine Bestellung?” kann man natürlich im Voraus einen Handler schreiben. Fertiger Code ist schneller, günstiger und viel vorhersehbarer. Wann macht also dynamische Codegenerierung Sinn? Hier ein paar Beispiele:

Unvorhersehbare Anfragen. Ein Kunde fragt: “Ich habe am Dienstag eine blaue Jacke bestellt, dann auf Schwarz geändert und noch einen Schal hinzugefügt. Kannst du prüfen, ob die Änderungen durchgegangen sind und mir sagen, wann alles ankommt?” Kein vorgefertigter Handler deckt diese Kombination ab. Aber ein LLM kann die richtige Reihenfolge der API-Aufrufe ermitteln und sie direkt zusammenbauen.

Große API-Oberflächen. Wenn deine Plattform über 200 Endpoints hat, die Bestellungen, Retouren, Zahlungen, Abonnements und Treueprogramme abdecken, ist es ein enormer Entwicklungsaufwand, für jede mögliche Anfrage einen vorgefertigten Handler zu pflegen. Mit Codegenerierung beschreibst du einfach die typisierte API, und das LLM stellt die nötigen Aufrufe nach Bedarf zusammen.

Multi-Tenant-Logik. Verschiedene Kunden haben verschiedene Regeln. Ein Händler akzeptiert Retouren innerhalb von 30 Tagen, ein anderer 14, ein dritter nur für bestimmte Kategorien. Statt eine komplexe Regel-Engine zu bauen, die alle Varianten abdeckt, generiert das LLM Code, der die richtigen Regeln für den jeweiligen Kontext anwendet.

Wechselnde Integrationen. Du bindest einen neuen Versanddienstleister oder Zahlungsanbieter an. Mit vorgefertigten Handlern heißt das: Code aktualisieren, testen, deployen. Mit Codegenerierung aktualisierst du die TypeScript-API-Definition, und das LLM übernimmt die Änderungen sofort.

In der Praxis würden die meisten Teams beide Ansätze nutzen: Standardanfragen werden mit fertigem Code verarbeitet, während komplexe oder ungewöhnliche Anfragen an das LLM gehen. Du zahlst für Codegenerierung nur dann, wenn du sie wirklich brauchst.

Die “Code Mode”-Idee

Dynamic Workers sind Teil eines umfassenderen Konzepts, das Cloudflare “Code Mode” nennt. Statt das LLM viele sequenzielle Tool Calls machen zu lassen (API A aufrufen, warten, API B aufrufen, warten, API C aufrufen), schreibt der Agent ein einziges Skript, das alles verkettet, in einem Durchlauf ausführt und nur das Endergebnis zurückgibt.

Cloudflare behauptet, dieser Ansatz reduziert den Token-Verbrauch um 81% im Vergleich zu sequenziellen Tool Calls. Ihr eigener MCP-Server funktioniert genau so: Er stellt die gesamte Cloudflare-API über nur zwei Tools (search und execute) in unter 1.000 Tokens bereit. Der Agent schreibt TypeScript gegen eine typisierte API, führt es in einem Dynamic Worker aus, und nur das Ergebnis geht zurück ins Kontextfenster. Zwischenschritte erreichen das LLM nie.

TypeScript statt OpenAPI

Cloudflare nutzt TypeScript-Interfaces statt OpenAPI-Spezifikationen, um die für Agenten verfügbaren APIs zu beschreiben.

Eine Chatroom-API als TypeScript-Interface umfasst etwa 15 Zeilen. Die äquivalente OpenAPI-Spezifikation sind über 60 Zeilen YAML. TypeScript ist kompakter, leichter lesbar für Menschen und LLMs, und verbraucht weniger Tokens pro API-Aufruf. Wenn du Millionen von Agenten-Interaktionen hast, macht sich dieser Unterschied deutlich auf der Rechnung bemerkbar.

Hilfsbibliotheken

Zusammen mit der Runtime hat Cloudflare drei npm-Pakete veröffentlicht:

• @cloudflare/codemode kapselt die Sandbox-Erstellung und MCP-Server-Integration; es kann einen bestehenden MCP-Server nehmen und alle seine Tools auf ein einziges code() Tool reduzieren.

• @cloudflare/worker-bundler löst npm-Abhängigkeiten zur Laufzeit auf, sodass agentengenerierter Code Drittanbieter-Bibliotheken wie Hono oder das Stripe SDK ohne Vorkonfiguration importieren kann.

• @cloudflare/shell stellt ein virtuelles Dateisystem innerhalb eines Dynamic Workers bereit (basierend auf SQLite und R2) mit typisierten Methoden für Dateioperationen. Das Dateisystem unterstützt transaktionale Batch-Schreibvorgänge: Wenn eine Operation im Batch fehlschlägt, wird alles zurückgerollt.

Das Sicherheitsmodell

Cloudflare spricht ziemlich offen darüber, wo Kompromisse nötig waren. Sicherheitslücken in V8 kommen häufiger vor als in Hypervisoren. Deshalb besteht ihre Verteidigungsstrategie aus mehreren Ebenen:

• V8-Sicherheitspatches erreichen die Produktion innerhalb von Stunden (schneller als Chrome selbst).
• Eine maßgeschneiderte zweite Sandbox-Ebene mit dynamischer Tenant-Trennung nach Risikoniveau.
• Hardware-Speicherschutz über MPK (Memory Protection Keys).
• Spectre-Abwehrmaßnahmen, die in Zusammenarbeit mit Forschern entwickelt wurden.
• Automatisches Code-Scanning, das schädliche Muster blockiert.

Auch der kurze Lebenszyklus der Isolates hilft. Da es günstig ist, sie bei jeder Anfrage zu erstellen und zu zerstören, gibt es keine Versuchung, sie zwischen Aufgaben wiederzuverwenden - ein ziemlich verbreitetes Sicherheitsproblem bei warmen Container-Pools.

Einschränkungen

Aktuell funktionieren Dynamic Workers nur effektiv mit JavaScript. Python und WebAssembly werden technisch unterstützt, sind aber für kurze Code-Fragmente deutlich langsamer. Ein großer Teil des AI-Ökosystems lebt in Python, besonders Data Science und ML-Pipelines. Für diese Anwendungsfälle ist das nichts.

Außerdem ist die Code-Ausführungsschicht an Cloudflare gebunden. Deine Datenbanken, APIs und LLM-Anbieter können überall sein, aber die Sandbox läuft nur auf Cloudflares Infrastruktur. Du brauchst also einen kostenpflichtigen Workers-Plan.

Preise

Dynamic Workers kosten $0,002 pro Tag für jeden einzigartigen geladenen Worker, plus Standard-CPU- und Aufrufgebühren. Während der Beta wird die Worker-Gebühr nicht erhoben, du kannst also frei experimentieren. Ich empfehle, mit der Dokumentation und Einführung zu starten.

Für einmalige Codegenerierung sind die Ausführungskosten verschwindend gering im Vergleich zu den Inferenzkosten für die Generierung des Codes selbst. Ein LLM-Aufruf kann ein paar Cent kosten. Die Sandbox-Ausführung kostet Bruchteile eines Cents.

Wer braucht das?

Nicht jeder.

Hochvolumige Verbraucherprodukte sind die Hauptzielgruppe. E-Commerce-Plattformen, Consumer-SaaS, Messaging-Apps, große Marktplätze, Fintech-Apps mit Millionen von Nutzern. Das Muster: viele kleine, unabhängige AI-Aufgaben, die Nutzer gleichzeitig auslösen.

Multi-Tenant-Plattformen sind die zweite mögliche Zielgruppe. Unternehmen, die ihren Kunden ermöglichen, eigene Automatisierungen zu bauen. Auch wenn die Last jedes einzelnen Kunden gering ist, ergibt die Summe aus Tausenden Tenants mit eigenem Code eine erhebliche Belastung. Container werden bei diesem Volumen teuer. Isolates helfen, Ressourcen zu sparen.

Enterprise-AI-Tools mit einer überschaubaren Nutzerzahl? Wahrscheinlich nicht die Zielgruppe. Wenn deine gleichzeitigen Agenten-Ausführungen im Hunderterbereich liegen und nicht im Hunderttausenderbereich, spielt der Unterschied zwischen 5 ms und 500 ms Cold Start keine Rolle. Ein Container, eine Serverless-Funktion oder sogar die direkte Ausführung der Logik in deiner Workflow-Engine funktionieren auch ohne Dynamic Workers bestens.

Das große Bild

Der Markt für AI-Infrastruktur teilt sich entlang der Workload-Typen auf. Einige Anbieter bauen langlebige Agenten-Umgebungen mit persistentem Speicher und Stateful-Ausführung. Cloudflare bewegt sich in die entgegengesetzte Richtung: Einweg-Ausführung, die sofort erscheint und nach der Nutzung verschwindet.

Ich denke, beide Ansätze werden koexistieren, aber Cloudflare setzt gezielt darauf, dass die Zahl der Unternehmen, die Millionen gleichzeitiger, kurzlebiger Agenten-Ausführungen brauchen, weiter wächst. Wenn sie Recht haben, könnten Dynamic Workers still und leise zu einem Standard-Baustein für die nächste Welle von AI-Produkten werden.

Und selbst wenn nicht - es bleibt eine elegante Technologie auf der Suche nach einem größeren Publikum.