Cursor Cloud Agents vs. Cloudflare: Diese 2 Lücken bleiben

Am 13. Mai hat Cursor Multi-Repo-Umgebungen für Cursor Cloud Agents veröffentlicht. Laut eigener Produktseite stammen inzwischen mehr als 30% der von Cursor gemergten Pull Requests von autonomen Agenten, die in Cloud-Sandboxes arbeiten.

Was Cursor am 13. Mai tatsächlich veröffentlicht hat

Im Mittelpunkt stehen Multi-Repo-Umgebungen für Cloud Agents. Agenten können nun innerhalb einer einzigen konfigurierten Umgebung über mehrere Repositorys hinweg arbeiten. Die Grundlage dafür bilden die Multi-Root-Workspaces, die Cursor am 24. April eingeführt hat. Da sich die Umgebung sitzungsübergreifend wiederverwenden lässt, entfällt vor jedem Agentenlauf die wiederholte Einrichtung derselben Entwicklungsumgebung.

Konfiguriert wird über ein Dockerfile. Build-Secrets gelten ausschließlich für den Build-Schritt und werden nicht an den laufenden Agenten weitergegeben. Damit entschärft Cursor eine der häufigsten Gefahren in der KI-Agenten-Infrastruktur: Ein versehentlich in einen Build eingebetteter API-Schlüssel landet nicht im Arbeitskontext des Agenten. Cursor kann das Dockerfile außerdem selbst konfigurieren, indem es die Repositorys auf Tools und Abhängigkeiten untersucht. Für Enterprise-Teams befindet sich dieser Ablauf weiterhin in der privaten Beta.

Den größten Leistungssprung liefert das Layer-Caching. Builds mit Cache-Treffer laufen nun 70% schneller, weil nur geänderte Dockerfile-Layer neu gebaut werden. Wenn Agenten in einem Team immer wieder neu starten, wird aus Wartezeit echte Arbeitszeit.

Unterschätzt wird vor allem die betriebliche Ebene. Jede Umgebung besitzt einen Versionsverlauf samt Rollback, wobei Rollbacks auf Administratoren beschränkt sind. Ein Audit-Log erfasst jede Aktion, die Teammitglieder an Umgebungen ausführen. Egress-Allowlisten und Secret-Gültigkeitsbereiche werden pro Umgebung festgelegt: Ein Secret aus Umgebung A ist aus Umgebung B nicht erreichbar. Genau diese unspektakuläre Infrastruktur ist nötig, bevor ein Agent Pull Requests für Produktionscode öffnen darf.

Als Praxisbeleg nennt Cursor Amplitude. Dort überwachen Cursor Automations öffentliche Slack-Kanäle, untersuchen gemeldete Probleme, ermitteln die betroffenen Repositorys und öffnen Pull Requests in den jeweils richtigen Repositorys. Das ist First-Level-Triage durch einen Multi-Repo-Agenten in einem realen Unternehmen und in realer Größenordnung – keine Demo.

Warum die Merge-Zahl der Cursor Cloud Agents zählt

Cursor zufolge werden inzwischen mehr als 30% der gemergten Pull Requests von autonomen Agenten in Cloud-Sandboxes erstellt. Entscheidend ist der Nenner: Gemessen werden gemergte Pull Requests, nicht bloße Agentenversuche. Genau das zeigt, dass der Ablauf Review, Korrekturen und Übergabe vollständig durchlaufen kann, ohne dass ein Mensch jeden Commit selbst pushen muss.

Seit dem 2. September 2026 können Teams mit Cursors Self-Hosted Machines Dateiänderungen, Terminalbefehle, Computer-Use-Tools und die lokale MCP-Ausführung auf selbst verwaltete Worker verlagern. Agentenschleife, Inferenz und Planung verbleiben dabei in Cursors Cloud. Damit ist die Lücke beim privaten Ausführungsort geschlossen, Cursor wird dadurch jedoch nicht zu einer programmierbaren, dauerhaften Laufzeitumgebung.

Es geht also nicht mehr um sitzungsgebunden oder dauerhaft. Cursor speichert den Gesprächszustand im eigenen Backend, sodass sich Läufe später erneut öffnen und fortsetzen lassen; Self-Hosted Team Pools können zudem einen zuvor in den Ruhezustand versetzten Workspace wiederherstellen. Präziser ist die Unterscheidung zwischen anbieterverwaltetem Agentenzustand und programmierbarem Anwendungszustand. Cloudflare stellt pro Agent einen SQLite-Zustand sowie dauerhafte, im Code steuerbare Workflow-Schritte bereit.

Was mein Stack aus Cloudflare Workers und Agents SDK bereits leistet

Ich betreibe sechs Produktionsagenten auf Cloudflare. Als Laufzeit dienen Workers, der Zustand liegt in Durable Objects mit SQLite pro Instanz, und die langfristige Orchestrierung übernimmt Cloudflare Workflows. Das System wurde von einer Person in einem einzigen Konto aufgebaut und ist hier ausführlich aufgeschlüsselt. Im April 2026 kostete der vollständige Cloudflare-Stack $19.14. Das ist eine zeitgebundene Produktionsrechnung, kein Plattformangebot. Cursor weist Enterprise als Custom aus; Team Pools setzen Enterprise voraus, und bei Self-Hosted Machines fallen weiterhin die Kosten für das ausgewählte Modell sowie die eigene Worker-Rechnung an.

In drei Punkten unterscheidet sich dieser Stack von Cursors aktuellem Produkt.

Multi-Repo per Code. Ein Worker kann zur Laufzeit Ressourcen über HTTP abrufen. Browser Run, früher Browser Rendering, steuert einen Headless-Browser, wenn der benötigte Kontext hinter einer Website liegt. Cursor verpackt den Multi-Repo-Zugriff in eine wiederverwendbare Umgebungskonfiguration; bei Cloudflare bleiben Abruf, Authentifizierung und Repository-Logik in der Verantwortung des Entwicklers. Das eine ist nicht besser als das andere – die Steuerung erfolgt nur auf einer anderen Ebene.

Programmierbarer dauerhafter Zustand. Ein Cloudflare Agent speichert seinen Anwendungszustand automatisch in einer eigenen SQLite-Datenbank und lädt ihn nach einem Neustart oder Ruhezustand wieder. Auch Cursor bewahrt den Gesprächszustand und ermöglicht die Fortsetzung von Läufen. Der Unterschied liegt in der Kontrolle: Cursor verwaltet Gesprächsspeicher und Agentenlaufzeit, während Cloudflare den Anwendungszustand samt Schema für den eigenen Code zugänglich macht.

Dauerhafte Schrittgrenzen statt automatisch garantierter Exactly-once-Ausführung. In Workflows kann jeder Schritt einzeln wiederholt werden und Zustand ausgeben, damit die Ausführung nach einem Netzwerk- oder Infrastrukturfehler fortgesetzt werden kann. step.do nimmt eine eigene Wiederholungskonfiguration pro Schritt entgegen, NonRetryableError beendet Wiederholungen bei endgültigen Fehlern, und Instanz-IDs sind innerhalb eines Workflow eindeutig. Ein Schritt kann dennoch mehrfach ausgeführt werden. Cloudflare verlangt deshalb ausdrücklich, Aufrufe mit Seiteneffekten idempotent zu gestalten. Der Vorteil besteht in einer vom Entwickler definierten Dauerhaftigkeit und Wiederholungssteuerung – nicht im automatischen Schutz vor doppelten Pull Requests, E-Mails oder Kosten.

Die zwei Lücken, die Cursor noch nicht geschlossen hat

Lücke 1: kundenseitig kontrollierter, programmierbarer Agentenzustand. Die grundlegende Wiederaufnahme hat Cursor gelöst: Gesprächszustände bleiben standardmäßig unbegrenzt erhalten, verwaltete VM-Snapshots unterliegen einem rollierenden Inaktivitätsfenster von 90 Tagen. Self-Hosted Machines verlagert die Tool-Ausführung, doch Cursor betreibt weiterhin die Agentenschleife und speichert das Gespräch. Ein Cloudflare Agent macht den SQLite-gestützten Zustand innerhalb der Anwendungslaufzeit zugänglich. Das ist relevant, wenn ein Agent Vorfälle überwacht, eine Migration koordiniert oder Geschäftszustand über einen mehrtägigen Onboarding-Ablauf hinweg mitführt.

Damit ist die Lücke enger gefasst als noch im Mai. Cursor kann die Agentenläufe seines Produkts fortsetzen. Es stellt aber keine kundeneigene Zustandsmaschine bereit, die eine Anwendung unabhängig von einem Cursor-Chat abfragen, erweitern und koordinieren kann.

Lücke 2: eine vom Entwickler definierte Oberfläche für dauerhafte Schritte. Die aktuelle Dokumentation zu Cursor Cloud Agent und Self-Hosted Machine beschreibt kein Anwendungsprimitiv, das einem Workflow-Schritt mit gespeichertem Zustand und eigener Wiederholungskonfiguration pro Schritt entspricht. Cloudflare bietet genau das. Relevant wird dieser Unterschied, sobald ein Coding-Agent Abrechnung, E-Mail, Deployment oder einen anderen externen Seiteneffekt auslöst.

Tool-Aufrufe auf die eigene Maschine zu verlagern, schließt diese Lücke nicht: Es ändert den Ausführungsort, nicht den Orchestrierungsvertrag. Auch Cloudflare garantiert Seiteneffekte nicht als Exactly-once-Ausführung; ein wiederholter Schritt muss weiterhin idempotent implementiert sein.

Das ist keine Kritik an Cursor, sondern eine Frage der Kategorie. Cursor ist ein Coding-Produkt mit verwalteter und kundenseitig betriebener Tool-Ausführung. Cloudflare ist eine programmierbare Anwendungslaufzeit. Das September-Release verkleinert die Infrastrukturlücke, doch die Grenze bei Zustand und Orchestrierung bleibt bestehen.

Was Gründer und CTOs diese Woche tun sollten

Drei Profile erfordern drei unterschiedliche Entscheidungen.

Kleine Produktteams, die Produktfunktionen ausliefern, sollten verwaltete Cursor Cloud Agents einsetzen, sofern deren Umgebungs- und Netzwerkregeln den eigenen Build reproduzieren können. Das Umgebungs-Release vom 13. Mai deckt Multi-Repo-Setup, Build-Secrets, Caching und Auditierbarkeit ab. Cursors Angabe von mehr als 30% gemergten Pull Requests liefert dazu den öffentlichen Praxisbeleg. Ohne zwingenden Richtliniengrund sollte keine eigene Worker-Flotte betrieben werden.

Wer bereits auf Cloudflare oder Vercel langfristige Hintergrundprozesse betreibt, sollte dauerhaften Anwendungszustand und Orchestrierung dort belassen. Cursor Self-Hosted Machines kann nun Cloudflare- oder Vercel-Infrastruktur für die Tool-Ausführung nutzen, doch die Agentenschleife bleibt bei Cursor. Eine lesenswerte Parallele auf Anwenderseite zeigt, wie Anthropic ähnliche Bausteine für kleine und mittlere Unternehmen bündelt – die Annäherung der Plattformen an Agenten ist überall zu beobachten.

Bei einer geplanten Enterprise-Einführung sind verwaltete Cloud Agents der Ausgangspunkt, sofern Allowlisten, Tailscale, AWS PrivateLink oder Cloudflare Tunnel die Zugriffsanforderungen erfüllen. Team Pools eignen sich, wenn Checkout, Tool-Ausführung, spezielle Hardware oder Worker-Image unter eigener Kontrolle bleiben müssen. Team Pools setzen Enterprise voraus, dessen Preis als Custom angegeben ist; von Cursor konfigurierte Dockerfiles befinden sich weiterhin in der privaten Beta.

Was sich seit Mai geändert hat

Zwei Signale sind entscheidend.

Erstens dokumentiert Cursor den Gesprächszustand nun getrennt vom Laufzeit-Workspace. Standardmäßig bleibt der Gesprächszustand unbegrenzt gespeichert, sodass sich Läufe erneut aufrufen und fortsetzen lassen. Snapshots verwalteter VMs verfallen nach 90 Tagen Inaktivität, sofern das Zeitfenster nicht durch einen Start oder eine Fortsetzung verlängert wird. Die grundlegende Wiederaufnahme ist damit keine Lücke mehr – Eigentum und Programmierbarkeit sind es weiterhin.

Zweitens ist auch der private Ausführungsort keine Lücke mehr. Self-Hosted Machines löst dieses Problem, während Agentenschleife, Inferenz und Planung in Cursors Cloud verbleiben. Die beiden wesentlichen Unterschiede bleiben der kundenseitig kontrollierte Agentenzustand und eine vom Entwickler definierte Oberfläche für dauerhafte Schritte.

Macht Cursors Release vom 13. Mai selbst gehostete Agenten-Infrastruktur überflüssig?

Nein. Cursor bietet inzwischen einen eigenen Self-Hosting-Pfad: My Machines für persönliche Workflows und Team Pools für Enterprise-Flotten. Dadurch läuft die Tool-Ausführung im eigenen Netzwerk, doch Cursor betreibt weiterhin die Agentenschleife und speichert den Gesprächszustand. Teams, die eine programmierbare Anwendungslaufzeit oder dauerhafte Workflow-Schritte benötigen, brauchen für diese Ebenen weiterhin eigene Infrastruktur.

Wie schnell sind Builds der Cursor Cloud Agents mit Cache jetzt?

Builds mit Cache-Treffer laufen seit dem Layer-Caching-Upgrade vom 13. Mai 70% schneller. Bei einem Cache-Treffer werden nur die geänderten Dockerfile-Layer neu gebaut.

Was sagt Cursors interne Zahl gemergter Pull Requests aus?

Laut Cursors aktueller eigener Produktseite werden mehr als 30% der gemergten Pull Requests von autonomen Agenten in Cloud-Sandboxes erstellt. Das ist ein aussagekräftiger Beleg für den Produktionseinsatz, weil gemergte Pull Requests statt bloßer Aufgabenversuche gezählt werden.

Sind Cursor Cloud Agents bei Code mit Produktions-Secrets sicher?

Das Release vom 13. Mai grenzt Egress und Secrets pro Umgebung ein, trennt Build-Secrets vom laufenden Agenten und stellt Versionsverlauf, Rollback sowie Audit-Logs bereit. Self-Hosted Machines kann den vollständigen Checkout und maschinenlokale Zugangsdaten auf dem eigenen Worker halten. Benötigte Dateiinhalte, Tool-Ausgaben, Diffs, Screenshots und lokale MCP-Ergebnisse können dennoch an Cursor übertragen werden. Sicherheit setzt voraus, beide Grenzen zu akzeptieren.

Lassen sich Cloudflare Workers und Cursor Cloud Agents parallel betreiben?

Ja. Cursor führt Cloudflare als Integration für Self-Hosted Machines auf; die Referenzvorlage nutzt einen Cloudflare Worker als Controller, der pro übernommener Anfrage einen Cloudflare Container startet. Cursor kann die Coding-Agent-Schleife übernehmen, während Workers, Durable Objects und Workflows den dauerhaften Anwendungszustand und die Orchestrierung abbilden. Bei der Tool-Ausführung überschneiden sich die Produkte inzwischen, an der Grenze der Agentenschleife jedoch nicht.