Cloudflare Computer teilt den Agenten-Computer auf Isolates und Container auf

Cloudflare hat Cloudflare Computer am 3. August 2026 als Open-Source-Preview veröffentlicht und bietet Agenten damit einen persistenten Workspace über drei Ausführungs-Backends hinweg. Der Konflikt liegt in diesem Design. Entwickler können einfache Aufgaben über schlanke Workers-Isolates leiten und Linux-Container für anspruchsvollere Jobs reservieren, doch das Projekt ist ausdrücklich noch nicht produktionsreif.

Diese Unterscheidung ist wichtig, weil sich die Infrastruktur für Agenten in Richtung vollständiger, isolierter Maschinen entwickelt hat. Cloudflare Computer erprobt eine andere Annahme: Ein Agent benötigt die Fähigkeiten eines Computers, aber nicht jede Aktion braucht dieselbe Computerlaufzeit. Seine Dateien können unabhängig von der Umgebung bestehen bleiben, die jeden Befehl ausführt.

Das setzt Anbieter unter Druck, die eine Sandbox, einen Container oder eine MicroVM als Basiseinheit einer Agentensitzung behandeln. Zugleich fordert es Cloudflares bestehendes Sandbox SDK heraus, zu begründen, wann Entwickler einen dedizierten Container benötigen. Die Preview ist weniger ein fertiges Produkt als ein öffentliches Argument dafür, wie Agenten-Computing aufgeteilt werden sollte.

Cloudflare Computer trennt Dateien von der Ausführung

Die zentrale Änderung ist architektonisch: Der Workspace eines Agenten gehört nicht länger zu einem einzigen laufenden Container.

Laut dem Open-Source-Repository des Projekts speichert Cloudflare Computer sein maßgebliches virtuelles Dateisystem in einem Durable Object. Ein Durable Object ist eine zustandsbehaftete Cloudflare-Komponente mit privatem, persistentem Speicher und einem zentralen Koordinationspunkt.

SQLite hält den Zustand dieses Dateisystems. Die Ausführung erfolgt andernorts über eine gemeinsame Schnittstelle namens workspace.runtime. Der Agent kann dieselben Dateien lesen und verändern, auch wenn unterschiedliche Backends seine Befehle ausführen.

In der Preview werden drei Backends ausgeliefert. Das Container-Backend stellt eine vollständige Linux-Userland-Umgebung mit echten Binärdateien, Paketmanagern und Netzwerkzugriff bereit. Ein Worker-Shell-Backend führt shellähnliche Befehle über just-bash in einem Dynamic Worker aus. Das dritte Backend wertet JavaScript-Module in frischen Dynamic Workers aus.

Entwickler können mehr als ein Backend für einen Workspace registrieren. Jedes erhält eine stabile Kennung, während workspace.runtime.exec() zum gemeinsamen Einstiegspunkt wird. Ein Aufrufer kann ein Backend direkt auswählen, oder ein Agenten-Framework entscheidet anhand von Beschreibungen, die der Entwickler bereitstellt.

Diese Anordnung macht das Dateisystem zum stabilen Zentrum der Sitzung. Rechenleistung wird austauschbar. Ein schlanker Befehl kann in einem Isolate laufen, während eine Paketinstallation oder ein nativer Build zu Linux wechseln kann, ohne einen separaten logischen Workspace zu erzeugen.

Cloudflare bezeichnet das Paket als persistentes, SQLite-gestütztes virtuelles Dateisystem mit austauschbarer Ausführung. Die Paketdokumentation beschreibt ein Limit von etwa 10 GB pro Workspace. Der Speicher teilt sich die Limits seines Durable Object.

Das Paket funktioniert auch ohne Ausführungs-Backend. Eine Anwendung kann nur das dauerhafte Dateisystem verwenden und Ausführung erst hinzufügen, wenn ihr Workflow sie erfordert. Damit ist das Speichermodell mehr als nur eine unterstützende Funktion für eine Sandbox.

Die öffentliche API ähnelt bekannten Node.js-Dateisystemoperationen. Sie umfasst Funktionen zum Lesen, Schreiben, Auflisten, Entfernen und Durchsuchen von Dateien. Zeichenketten verwenden standardmäßig UTF-8, während Binärdaten über Byte-Arrays oder Streams übertragen werden können.

Der Containerzugriff benötigt eine zusätzliche Schicht. Ein Daemon namens computerd läuft innerhalb der Sandbox und stellt den persistenten Workspace als FUSE-Mount bereit. FUSE ermöglicht es einem User-Space-Prozess, Dateien über eine normale Dateisystemschnittstelle bereitzustellen.

Der Daemon synchronisiert Änderungen über einen RPC-Kanal mit dem maßgeblichen Durable Object. Dadurch erhalten Linux-Tools ein konventionelles Verzeichnis, während SQLite außerhalb des Containers die Quelle der Wahrheit bleibt.

Die Isolate-Backends nehmen einen kürzeren Weg. Ihre Dateisystemoperationen rufen dasselbe Durable Object über Workers RPC auf, sodass sie keinen zweiten Speicher verwalten müssen. Zudem umgehen sie den Synchronisierungsschritt, der nach der Arbeit im Container erforderlich ist.

Das macht die Ankündigung zu mehr als einem weiteren Dienst zur Codeausführung. Cloudflare Computer zerlegt den vertrauten Computer in persistente Dateien, auswählbare Ausführung, Synchronisierung und Publishing-Hilfen. Der Agent sieht weiterhin einen Workspace, obwohl sich die zugrunde liegende Infrastruktur von Befehl zu Befehl ändern kann.

Warum Agenten nicht länger in eine einzige Laufzeit passen

Agenten-Workloads verbinden kleine Dateioperationen mit gelegentlicher Arbeit auf Systemebene, wodurch eine feste Ausführungsumgebung zu einer ineffizienten Voreinstellung wird.

Ein Coding-Agent erledigt selten eine einheitliche Aufgabe. Er kann eine Konfigurationsdatei prüfen, ein Repository durchsuchen, mehrere Zeilen bearbeiten, Tests ausführen, eine Abhängigkeit installieren, ein Bild erstellen und ein Artefakt veröffentlichen. Diese Aktionen haben unterschiedliche Anforderungen an die Laufzeit.

Das Lesen einer Datei erfordert keinen vollständigen Linux-Container. Dasselbe gilt für das Parsen von Text oder das Auswerten eines kontrollierten JavaScript-Moduls. Native Kompilierung, Paketinstallation und Betriebssystemtools benötigen dies in der Regel schon.

Herkömmliche Remote-Sandboxes bündeln diese Anforderungen. Die Sandbox stellt innerhalb einer Umgebung ein Dateisystem, eine Shell, Prozesse und Netzwerkzugriff bereit. Dieses Modell ist leicht zu verstehen, bindet Persistenz und Ausführung jedoch an denselben Lebenszyklus.

Cloudflares früheres Sandbox SDK folgt weitgehend diesem Modell. Das Unternehmen stellte Sandboxes am 13. April 2026 allgemein bereit, nachdem es sie neun Monate zuvor erstmals als Befehls- und Dateisystemumgebungen vorgestellt hatte.

Mit der allgemeinen Verfügbarkeit war jede Sandbox zu einer Entwicklungsumgebung mit Terminal, Hintergrundprozessen, Dateiüberwachung, Live-Preview-URLs, Egress-Kontrollen und Snapshots geworden. Cloudflare erklärte, Standardkonten könnten 15.000 gleichzeitige Lite-Instanzen, 6.000 Basic-Instanzen und mehr als 1.000 größere Instanzen ausführen.

Das Unternehmen stellte Sandboxes zudem auf die Abrechnung aktiver CPU-Zeit um, sodass Leerlaufzeiten keine kostenpflichtige CPU-Zeit verbrauchen. Diese Änderung adressierte einen Kostenfaktor lang laufender Agentensitzungen. Sie beseitigte jedoch nicht den architektonischen Unterschied zwischen dem Starten eines Containers und der Ausführung von Code in einem schlanken Isolate.

Cloudflare Computer macht aus diesem Unterschied eine Routing-Entscheidung. Backends verbinden sich verzögert, das heißt, sie werden initialisiert, wenn Arbeit sie erstmals erreicht. Ein Workflow kann mit Dateien und einem Isolate beginnen und erst dann auf Linux zugreifen, wenn ein Befehl es tatsächlich benötigt.

Die Strategie spiegelt Cloudflares breitere Position wider, dass Agenten-Workloads mehrere Rechenskalen erfordern. Der Rückblick auf die Agents Week argumentierte, dass manche Agenten vollständige Betriebssysteme benötigen, während die meisten Aufgaben leichtere Umgebungen brauchen, die in Millisekunden starten.

Cloudflare Computer gibt dieser Behauptung ein konkretes Programmiermodell. Entwickler müssen Dateien nicht manuell zwischen unabhängigen Diensten verschieben. Der Workspace sorgt für Kontinuität, während sich die Ausführungsgrenze ändert.

Für Autoren von Frameworks ist diese Kontinuität wichtig. Ein Agent kann Standardtools mit den Namen read, write, edit, ls und exec erhalten. Das Paket bietet Adapter für AI SDK-Anwendungen, während der Entwickler beschreibt, was jedes Backend verarbeiten kann.

Ein Modell kann dann schnelle Textoperationen an ein Isolate und anspruchsvollere Befehle an einen Container senden. Damit wird die Backend-Auswahl Teil der Tool-Policy des Agenten. Sie schafft aber auch einen neuen Fehlermodus, wenn diese Beschreibungen unklar sind oder das Modell schlecht auswählt.

Das Design ist besonders für Agenten relevant, die häufig pausieren. Modellinferenz, menschliche Genehmigung, Netzwerkanfragen und externe API-Aufrufe erzeugen Leerlaufphasen. Eine vollständige Umgebung während jeder dieser Phasen aktiv zu halten, kann bequem sein, ist jedoch nicht die einzige Möglichkeit, die Arbeit des Agenten zu erhalten.

Ein dauerhaftes Dateisystem lässt die Ausführungsschicht verschwinden, ohne den Sitzungszustand zu löschen. Die nächste Aktion kann dieselben Dateien über ein anderes Backend erneut öffnen. Aus Sicht des Agenten ähnelt dies einem Computer, auch wenn keine einzelne Maschine die gesamte Sitzung besitzt.

Diese Abstraktion setzt Container-first-Anbieter unter Druck, beseitigt jedoch nicht ihr stärkstes Argument. Eine vollständige isolierte Umgebung bietet vorhersehbare Tools, vertrautes Debugging und eine konsistente Sicherheitsgrenze. Eine Sitzung auf mehrere Laufzeiten aufzuteilen, bringt Koordinations- und Synchronisierungsprobleme mit sich.

Sie setzt auch Cloudflares Produktgrenzen unter Druck. Entwickler müssen verstehen, ob sie Sandbox SDK, Cloudflare Computer, Dynamic Workers oder eine Kombination benötigen. Ein Preview-Paket kann Überschneidungen untersuchen, doch eine Produktionsplattform braucht letztlich eine einfache Antwort.

Die wahrscheinliche Antwort hängt vom Workload ab. Cloudflare Computer begünstigt Agenten, die viele kleine Operationen ausführen und gelegentlich Linux benötigen. Ein Container bleibt klarer, wenn nahezu jeder Schritt von nativen Tools, umfangreichen lokalen Abhängigkeiten oder Festplattenzugriff mit hohem Durchsatz abhängt.

Das ist die eigentliche Frage, um die es geht. Die Preview fragt, ob Entwickler eine Maschine bereitstellen sollten oder einen Workspace, der sich unterschiedliche Maschinen ausleihen kann.

Wie Cloudflare Computer einen Workspace über drei Backends leitet

Cloudflare Computer gewinnt Flexibilität, indem es die Laufzeitauswahl explizit macht, doch jedes Backend bringt ein anderes Profil für Fähigkeiten und Synchronisierung mit.

Das Worker-Shell-Backend ist der schlankste Weg für vertraute Befehle. Es verwendet just-bash, eine TypeScript-Implementierung einer Bash-ähnlichen Umgebung, die ohne das Starten von Betriebssystemprozessen ausgeführt werden soll.

Dieses Backend kann textorientierte Shell-Arbeit gegen den dauerhaften Workspace erledigen. Es benötigt weder Docker noch einen Cloudflare Container. Dateioperationen gehen an das Durable Object zurück, sodass der maßgebliche Zustand an einem Ort bleibt.

Das Worker-JavaScript-Backend verarbeitet ECMAScript-Module statt Shell-Befehlen. Jede Ausführung läuft in einem frischen Dynamic Worker und kann strukturierte Eingaben annehmen oder strukturierte Ergebnisse zurückgeben. Es unterstützt Workspace-gestützten Dateizugriff und konfigurierte Bibliotheken.

Cloudflare stellt auch vertrauenswürdige Module für Git und Cloudflare Artifacts bereit. Git-Operationen können über einen isomorphic-git-Client direkt gegen das virtuelle Dateisystem ausgeführt werden. Sie benötigen keinen Container oder eine konventionelle Git-Binärdatei.

Das Container-Backend deckt die Aufgaben ab, die Isolates nicht können. Es stellt Linux, native Binärdateien, Node.js, npm, Netzwerke und weitere Betriebssystemfähigkeiten bereit. Der Workspace erscheint darin über den computerd-FUSE-Mount.

Dieses Backend schafft das schwierigste Datenproblem. Cloudflare muss den SQLite-gestützten Zustand in einen Container projizieren, konventionellen Tools erlauben, ihn zu verändern, und diese Änderungen anschließend synchronisieren. Das Paket verwaltet unabhängige Synchronisierungscursor für jedes registrierte Backend.

Wenn ein Befehl erfolgreich ist, aber das Abrufen nach dem Befehl fehlschlägt, kann das Ausführungsergebnis einen ausstehenden Synchronisierungsstatus melden. Anwendungen können Wiederholungen mit begrenztem exponentiellem Backoff konfigurieren. Die Bibliothek übernimmt jedoch nicht die Planung der Alarme des Durable Object.

Dieses Detail zeigt, wie viel Verantwortung weiterhin beim Entwickler liegt. Ein Nutzer sieht einen Workspace, doch die Anwendung muss Backend-Registrierung, Wiederholungsplanung, Ausführungslebenszyklus und ungelöste Synchronisierung handhaben.

Das Design erfordert außerdem einen disziplinierten Umgang mit Ressourcen. Die RPC-Schicht sammelt Remote-Stubs nicht automatisch ein. Lang laufende Sitzungen, die wiederholt Workspace- oder Ausführungshandles beziehen, können sie ansammeln, sofern die Anwendung nicht jedes Handle freigibt.

Cloudflare dokumentiert Unterstützung bei der Fehlersuche, um solche Lecks zu erkennen. Dennoch handelt es sich um Infrastruktur aus der Preview-Phase, nicht um einen unsichtbaren Plattformdienst. Entwickler, die damit experimentieren, müssen die zugrunde liegende Technik verstehen.

Das Veröffentlichen von Dateien führt eine weitere Grenze ein. Das Paket kann eine Workspace-Datei nach R2 hochladen und einen vorab signierten Link zurückgeben. Es kann eine Sitzung auch mit Cloudflare Artifacts verbinden, einem Git-kompatiblen Speicherdienst für Code und Build-Ausgaben.

Ein enthaltenes Tutorial demonstriert die beabsichtigte Aufgabenteilung. Ein Agent erstellt eine Markdown-Rezeptkarte in seinem Workspace und verwendet anschließend pandoc in einem Container, um eine PDF-Datei zu erzeugen. Der Speicher bleibt dauerhaft, während ein Linux-Tool die Formatkonvertierung übernimmt.

Ein weiteres Beispiel sendet die Bildgenerierung an Workers AI, schreibt das Ergebnis in den Workspace und gibt ein teilbares Asset zurück. Eine Vergleichsoberfläche führt dieselbe Aufgabe parallel über Container- und Worker-Runtimes aus.

Diese Beispiele verweisen auf ein breiteres Muster für Agenten. Der Workspace wird zu einer gemeinsamen Werkbank, während unterschiedliche Runtimes wie spezialisierte Werkzeuge agieren. Der Agent muss nicht jedes Backend als separaten Computer behandeln.

Der Mechanismus kann auch wissensintensive Entwicklung unterstützen. Ein Engineering-Team könnte Aufgaben-Dateien, generierte Berichte und Testergebnisse im Workspace ablegen und dauerhafte Resultate anschließend in eine durchsuchbare Wissensdatenbank übertragen. Die Runtime bleibt temporär, während nützliche Arbeit auch über die Agent-Sitzung hinaus zugänglich wird.

Die Abstraktion hat jedoch Grenzen. Das containerseitige Dateisystem wird im Arbeitsspeicher gehalten, und Cloudflare empfiehlt Workspaces in Agent-Größe statt vollständiger Monorepos. Eine Obergrenze von rund 10 GB ist für Dokumente und kleine Projekte erheblich, macht den Dienst jedoch nicht zu einem allgemeinen Ersatz für Entwicklungsdatenträger.

Die Worker-Backends erfordern zudem experimentelle Cloudflare-Funktionen und eine Worker Loader-Bindung. Das Paket selbst benötigt das Kompatibilitäts-Flag nodejs_compat. Diese Anforderungen unterstreichen seinen Preview-Status.

Der wichtigste Punkt in dieser Cloudflare-Computer-Analyse ist nicht, dass Isolates Container ersetzen. Das tun sie nicht. Der Mechanismus ermöglicht einer Anwendung zu entscheiden, wann ein Container seinen Aufwand für Startzeit, Fähigkeiten und Synchronisierung wert ist.

Diese Entscheidung kann auf Anwendungsebene oder über ein Agent-Framework getroffen werden. Das Modell sieht Beschreibungen der Backends und kann ein Ziel auswählen. Entwickler benötigen daher Richtlinienkontrollen, nicht nur Hinweise in natürlicher Sprache.

Ein Produktionssystem würde wahrscheinlich einschränken, auf welche Befehle, Dateien, Netzwerke und Zugangsdaten jedes Backend zugreifen kann. Außerdem wären verlässliche Protokolle nötig, die zeigen, warum ein Befehl eine bestimmte Runtime erreichte. Das aktuelle Repository stellt Observability-Hooks bereit, löst jedoch nicht das gesamte Governance-Problem.

Cloudflare Computer überzeugt am stärksten, wenn sich die Arbeit natürlich aufteilen lässt. Suchen und Bearbeiten in einem Isolate, Kompilieren unter Linux und anschließendes Veröffentlichen über einen Artifact-Service. Der Vorteil wird weniger deutlich, wenn jede Aktion den Container benötigt oder eine Aufgabe wiederholt große Dateien verschiebt.

Preview-Warnungen und Benchmarks erschweren die Argumentation

Das Repository liefert ungewöhnlich direkte Einschränkungen, darunter eine ausdrückliche Produktionswarnung und Benchmarks, die bei großen sequenziellen Dateioperationen erhebliche Nachteile zeigen.

Cloudflare erklärt, dass das Paket für Experimente, Erkundungen und Prototypen geeignet ist. Das Unternehmen weist darauf hin, dass die APIs instabil sind, sich das Design ändern kann und das Paket nicht für den produktiven Einsatz geeignet ist.

Diese Warnung sollte jede Aussage darüber einordnen, was Cloudflare Computer heute ist. Das Repository enthält funktionierende Pakete, Beispiele und Hunderte von Commits, doch Teile seiner Design-Dokumentation sind zukunftsorientiert. Cloudflare fordert Leser auf, diese Spezifikationen als Absicht und nicht als Beschreibung des aktuellen Codes zu verstehen.

Die Leistung ist der deutlichste Kompromiss. Das Unternehmen benchmarkte computerd auf einem Standardcontainer mit einer virtuellen CPU, 6 GiB Arbeitsspeicher und 12 GB Festplattenspeicher. Verglichen wurden der FUSE-Workspace mit einem In-Memory-Dateisystem und dem ext4-Datenträger des Containers.

Die Ergebnisse sprechen bei mehreren metadatenintensiven Operationen für das virtuelle Dateisystem. Das Löschen von 1.000 Dateien dauerte etwa zwei Drittel der ext4-Zeit. Das Erstellen eines verschachtelten Verzeichnisbaums benötigte ungefähr drei Viertel der Zeit. Das Auffinden dieses Baums ebenfalls.

Eine Git-Initialisierung samt Commit mit 100 Dateien dauerte auf computerd 459,2 Millisekunden, verglichen mit 635,4 Millisekunden auf ext4. Ein flacher Clone eines rund 1 MB großen Repositorys benötigte 549,1 Millisekunden, gegenüber 576,2 Millisekunden auf dem Datenträger.

Bei großen sequenziellen Operationen ergab sich das gegenteilige Bild. Das Schreiben einer 64-MiB-Datei dauerte auf computerd 230,6 Millisekunden, gegenüber 16,8 Millisekunden auf ext4. Das Kopieren derselben Datenmenge benötigte 1.037,2 Millisekunden, verglichen mit 39,8 Millisekunden.

Ein reiner 64-MiB-Lesevorgang war etwa 30-mal langsamer als die Datenträger-Basislinie. Ein reiner Kopiervorgang war mehr als 41-mal langsamer. Diese Unterschiede sind für Archive, Abhängigkeitsbäume, Medien, Modelldateien und Datenverarbeitungs-Workloads relevant.

Cloudflares Dateisystem-Benchmarks erklären den Mechanismus hinter der Verlangsamung. Der Schreibpfad hasht 512-KiB-Blöcke in einen inhaltsadressierten Blob-Store. Das unterstützt Deduplizierung und die Synchronisierung nur geänderter Blöcke, erhöht jedoch den Aufwand bei Operationen mit reinem Durchsatz.

Eine vollständige Installation von Cloudflares Sandbox SDK machte die Kosten konkreter. Der Test umfasste 854 Pakete und 36.675 Dateien. Die Installation dauerte 124,7 Sekunden im FUSE-Workspace, 63,9 Sekunden auf ext4 und 34,3 Sekunden im Arbeitsspeicher.

Cloudflare bezeichnet ext4 als realistischere Basislinie für die allgemeine Nutzung. Gegenüber dieser Basislinie dauerte die FUSE-Installation ungefähr doppelt so lange. Entwickler, die JavaScript-Projekte mit vielen Abhängigkeiten bauen, werden diesen Unterschied bemerken.

Die Benchmarks widerlegen das Design nicht. Viele Agent-Aufgaben umfassen Metadaten, kleine Änderungen, Suchen und inkrementelle Anpassungen statt anhaltender sequenzieller I/O. Die Ergebnisse zeigen vielmehr, wo Backend-Routing entscheidend ist.

Ein sinnvoller Workflow könnte Quelldateien im persistenten Workspace halten und wiederholtes Entpacken großer Archive vermeiden. Er könnte Abhängigkeiten an anderer Stelle zwischenspeichern oder Aufgaben wählen, deren Nutzen den Synchronisierungsaufwand überwiegt. Cloudflare hat die besten Muster für den Produktionseinsatz bislang nicht etabliert.

Sicherheit stellt eine zweite Unsicherheit dar. Das Repository beschreibt Ausführungsoberflächen und Speicherverhalten, behauptet jedoch nicht, dass alle drei Backends identische Isolation bieten. Ein JavaScript-Isolate, eine in TypeScript implementierte Shell und ein Linux-Container sind grundlegend unterschiedliche Ausführungsumgebungen.

Die Worker-Shell gewinnt teilweise an Geschwindigkeit, weil sie kein vollständiges Betriebssystem ist. Das begrenzt ihre Kompatibilität, kann aber auch den Umfang möglicher Befehlswirkungen einschränken. Der Container bietet umfassendere Fähigkeiten und erfordert daher stärkere Kontrollen für Netzwerkzugriff, Pakete und Zugangsdaten.

Der Wechsel zwischen diesen Umgebungen kann Richtlinienlücken schaffen. Ein in einem Backend abgelehnter Befehl könnte in einem anderen ausgeführt werden. Ein Agent könnte Linux wählen, weil dessen Beschreibung größere Fähigkeiten verspricht, obwohl die Aufgabe dies nicht erfordert.

Das Paket enthält Observer-Hooks für Workspace-Verbindung, Synchronisierung, Ausführung und Dateisystemoperationen. Diese Hooks können Cloudflare Tracing oder einen anderen Recorder speisen. Sie sind nützliche Grundlagen, doch Produktionsnutzer werden Autorisierungsregeln und eine auditierbare Richtlinie zur Backend-Auswahl benötigen.

Persistenz bringt eigene Sicherheitsfragen mit sich. Dateien überstehen Neustarts von Durable Objects, was Agenten für langlaufende Aufgaben benötigen. Persistente Workspaces können jedoch auch sensible Prompts, Quellcode, generierte Zugangsdaten oder heruntergeladene Daten länger als beabsichtigt speichern.

Anwendungen benötigen Löschrichtlinien und eine Mandantentrennung, die ihrem Risiko entsprechen. Schreibgeschützte R2-Mounts helfen beim Schutz von Referenzdaten, beantworten jedoch nicht jede Frage zu Datenaufbewahrung oder ausgehendem Zugriff.

Die GitHub-Reaktion liefert ein Adoptionssignal, keinen Produktionsnachweis. Das Repository zeigte am 6. August rund 3.100 Stars und 141 Forks. Diese Zahlen belegen Entwicklerinteresse nach der Ankündigung, insbesondere angesichts seiner Position bei GitHub Trending.

Sie belegen keine Zuverlässigkeit, Sicherheit oder nachhaltige Nutzung. Stars können sich bei einer überzeugenden Architektur schnell ansammeln. Eine echte Validierung wird von Workloads kommen, die über Wochen laufen, sich von Teilausfällen erholen und Dateien über Runtime-Wechsel hinweg konsistent bewahren.

Cloudflares Transparenz hilft dabei. Die Veröffentlichung ungünstiger I/O-Zahlen verschafft Entwicklern eine bessere Grundlage für Experimente. Die ausdrückliche Warnung verhindert zudem, dass das Trending-Ranking mit einem General-Availability-Launch verwechselt wird.

Das vorsichtige Fazit ist einfach. Cloudflare Computer bietet einen glaubwürdigen Mechanismus, um Agent-Zustand von der Ausführung zu trennen, doch die Preview hat nicht bewiesen, dass die zusätzliche Koordination in der Produktion einen dedizierten Sandbox-Ansatz übertrifft.

Worauf Entwickler nach dem GitHub-Schub achten sollten

Die nächste Phase hängt von drei Signalen ab: API-Stabilisierung, Evidenz aus realen Workloads und durchsetzbaren Richtlinien für die Backend-Auswahl.

Das erste Signal wäre ein versionierter, produktionsorientierter Release. Cloudflare Computer präsentiert derzeit instabile APIs und experimentelle Backend-Anforderungen. Ein Schritt hin zu einer stabilen Schnittstelle würde zeigen, dass Cloudflare die Zuständigkeitsgrenzen zwischen Computer, Sandbox SDK, Dynamic Workers und Durable Objects geklärt hat.

Dieser Release sollte auch das Wiederherstellungsverhalten präzisieren. Entwickler benötigen vorhersehbare Ergebnisse, wenn ein Container-Befehl abgeschlossen wird, die Synchronisierung jedoch fehlschlägt. Sie benötigen außerdem Garantien für gleichzeitigen Zugriff, Bereinigung, Speichergrenzen und langlaufende RPC-Sitzungen.

Wenn Cloudflare einen stabilen Release mit Migrationshinweisen veröffentlicht, wird das architektonische Argument stärker. Wenn die APIs sich ständig ändern oder das Paket ein Experiment bleibt, werden Teams das Repository weiterhin als Designforschung behandeln.

Das zweite Signal sind Belege aus vollständigen Agent-Workloads. Mikrobenchmarks zeigen bereits, wo FUSE gut funktioniert und wo Schwierigkeiten entstehen. Die schwierigere Frage lautet, ob das Routing von Befehlen über Isolates und Container hinweg die gesamte Aufgabendauer, Zuverlässigkeit oder Ressourcennutzung verbessert.

Nützliche Evaluierungen würden identische Agenten für Coding-, Recherche- und Datenanalyseaufgaben vergleichen. Sie sollten Startverzögerung, Ausführungsdauer, Synchronisierungsfehler, übertragenen Speicher und erfolgreichen Aufgabenabschluss messen. Ein reiner Dateisystem-Benchmark kann diese kombinierten Effekte nicht erfassen.

Die Beispiele im Repository sind ein Anfang, insbesondere die Oberfläche, welche Runtimes bei derselben Aufgabe vergleicht. Unabhängige Tests sollten größere Repositories, wiederholte Paketinstallationen, parallele Agenten und Sitzungen ergänzen, die nach Unterbrechungen fortgesetzt werden.

Wenn Workflows mit gemischten Runtimes zuverlässig abgeschlossen werden und dabei weniger Container aufrufen, gewinnt Cloudflares Mechanismus an Unterstützung. Wenn Synchronisierung und Routing diese Einsparungen aufzehren, bleibt eine persistente Sandbox die einfachere Wahl.

Das dritte Signal ist die Backend-Richtlinie. Heute kann eine Anwendung verfügbare Backends beschreiben und einen Agenten eines auswählen lassen. Produktionskunden werden deterministische Kontrollen erwarten, die regeln, welches Backend auf welche Datei, welches Netzwerk, welches Geheimnis und welchen Befehl zugreifen kann.

Cloudflare verfügt bereits über verwandte Infrastruktur. Seine Sandbox-Plattform umfasst programmierbare Kontrollen für ausgehenden Zugriff, während Durable Objects privaten, persistenten Zustand bereitstellen. Cloudflare Computer muss diese Bausteine zu einem Richtlinienmodell verbinden, das Entwickler nachvollziehen können.

Eine ausgereifte Implementierung sollte Eskalationen sichtbar machen. Wenn ein Agent von einer Worker-Shell zu Linux wechselt, sollte die Anwendung wissen, warum, welche neuen Fähigkeiten verfügbar wurden und welche Daten die Grenze überschritten haben.

Diese Frage reicht über Cloudflare hinaus. LangChain, Daytona, Ona, Modal und andere Plattformen entwickeln Agentenumgebungen mit unterschiedlichen Kombinationen aus MicroVMs, Containern, Persistenz und Entwicklerwerkzeugen. Ihr Wettbewerb dreht sich um die Definition eines Agentencomputers, nicht nur um Ausführungsgeschwindigkeit.

Einige Anbieter argumentieren, dass nicht vertrauenswürdiger Agentencode eine Isolation auf Hardwareebene und eine vollständige Maschinengrenze erfordert. Cloudflare Computer konzentriert sich stattdessen auf Zerlegung und ermöglicht es einem Workspace, leichtere Ausführung zu nutzen, bis Linux benötigt wird. Diese Positionen können nebeneinander bestehen, weil die Anforderungen an Isolation je nach Aufgabe variieren.

Coding-Agenten für Unternehmen könnten weiterhin dedizierte Umgebungen mit reproduzierbaren Toolchains und strikten Mandantengrenzen bevorzugen. Dokumenten-Agenten mit hohem Volumen könnten stärker von dauerhaften Dateien und schlanken Befehlen profitieren. Daten-Agenten, die große Eingaben verarbeiten, könnten die Durchsatzgrenzen des FUSE-Designs offenlegen.

Entwickler sollten daher ihren Aufgabenmix testen, bevor sie das Konzept übernehmen. Zählen Sie, wie viele Schritte tatsächlich native Binärdateien benötigen. Messen Sie, wie viele Daten durch den Workspace bewegt werden. Lösen Sie Synchronisationsfehler gezielt aus und bestätigen Sie die Wiederherstellung.

Sie sollten außerdem eine ansprechende Agentenerfahrung von einem angemessenen Sicherheitsdesign trennen. „Ein Workspace“ ist eine nützliche Oberfläche, bedeutet jedoch nicht, dass jeder Ausführungspfad dieselbe Vertrauensgrenze hat. Die Eskalation der Runtime verdient dieselbe Prüfung wie die Eskalation von Berechtigungen.

Cloudflare Computer ist wichtig, weil es diese Designentscheidung explizit macht. Es fordert Entwickler dazu auf, Dateien als dauerhaften Zustand, Ausführung als wählbaren Dienst und den scheinbaren Computer als für jede Aufgabe zusammengesetzte Abstraktion zu betrachten.

Diese Einordnung wird die Agenteninfrastruktur beeinflussen, selbst wenn sich diese Vorschau erheblich verändert. Sie bietet eine Alternative dazu, einen Container oder eine MicroVM nur deshalb am Leben zu halten, weil der Agent später seine Dateien benötigt.

Der GitHub-Aufschwung bestätigt das Interesse an der Idee. Er entscheidet jedoch nicht darüber, ob Entwickler die betriebliche Einfachheit einer einzelnen Maschine oder die versprochene Effizienz mehrerer Runtimes bevorzugen, die einen Workspace teilen.

Beobachten Sie in den kommenden Monaten eher das Repository als die Anzahl der Sterne. Stabile APIs, End-to-End-Benchmarks und strikte Backend-Richtlinien werden darüber entscheiden, ob Cloudflare Computer zu Produktionsinfrastruktur wird oder eine überzeugende Vorschau bleibt.

Teams, die die Cloudflare-Computer-Vorschau bewerten, sollten mit einer abgegrenzten Arbeitslast beginnen, jeden Runtime-Übergang dokumentieren und die Wiederherstellung testen, bevor sie persistentem Zustand vertrauen. Welche Vorgänge benötigen wirklich Linux, und welche benötigen nur Dateien plus eine kleine Ausführungsoberfläche? Die Beantwortung dieser Frage anhand von Traces und Fehlertests wird zeigen, ob das Hybridmodell zu Ihren Agenten passt. Sie wird auch offenlegen, wo eine herkömmliche Sandbox weiterhin leichter abzusichern und zu betreiben ist. Die übergeordnete Erkenntnis ist bereits nützlich: Der Computer eines Agenten muss keine dauerhaft laufende Maschine sein. Allerdings verlagert die Aufteilung in Dienste die Komplexität auf Routing, Synchronisation und Richtlinien. Behandeln Sie diese Mechanismen als Kerninfrastruktur, nicht als Implementierungsdetails.