KI-Agenten selbst hosten: Was Cursor ins eigene Netz verlagert

Mit der Änderung vom 2. September 2026 verlagert Cursor die Sicherheitsgrenze und die Infrastrukturkosten zugleich: Teams können die Tool-Ausführung ihrer KI-Agenten selbst hosten, übernehmen damit aber auch den Betrieb dieser Worker. Modell, Planung und Agentenschleife laufen weiterhin in der Cursor-Cloud.

KI-Agenten selbst hosten: So funktioniert die geteilte Laufzeit

Ein Cursor Cloud Agent besteht aus zwei Hälften. Die Agentenschleife entscheidet über den nächsten Schritt und ruft das Modell auf. Zur Tool-Ausführung gehören Dateiänderungen, Terminalbefehle, Browserzugriffe, die Kommunikation mit einem lokalen MCP-Server und der Zugriff auf interne Dienste.

Mit Cursor Self-Hosted Machines werden diese beiden Hälften getrennt. Agentenschleife, Inferenz, Planung, Oberfläche und Sitzungsorchestrierung verbleiben bei Cursor. Ein selbst verwalteter Worker führt die Tools aus.

Dieser Worker kann ein Laptop, eine VM, ein Mac, ein Kubernetes-Pod oder die Sandbox eines Integrationspartners sein. Er baut eine ausgehende HTTPS-Verbindung zu Cursor auf, empfängt Tool-Aufrufe, führt sie lokal aus und sendet die Ergebnisse zurück. Cursor benötigt am Worker weder einen eingehenden Port noch eine öffentliche IP-Adresse.

So verteilt sich der Betrieb.

Cursor bietet zwei Worker-Varianten an. My Machines bindet einen Rechner an das Konto einer einzelnen Person und eignet sich für eine Devbox oder einen eng begrenzten persönlichen Workflow. Team Pools sind benannte Warteschlangen für Enterprise-Teams. Eine Anfrage wartet im Pool, bis ein verfügbarer Worker sie übernimmt; jeder Pool-Worker bearbeitet jeweils eine Cloud-Agent-Sitzung.

Das ist kein On-Premises-Modell von Cursor, sondern eine geteilte Laufzeit mit einer kundeneigenen Ausführungshälfte. Ob das Feature die eigene Richtlinie erfüllt, entscheidet genau dieser Unterschied.

Was im eigenen Netzwerk bleibt – und was es weiterhin verlässt

Der vollständige Checkout, der Build-Cache und maschinenlokale Zugangsdaten bleiben auf dem eigenen Worker. Auch Befehle, Repository-Operationen, Builds und Aufrufe interner Dienste finden dort statt. Damit muss ein komplettes Repository möglicherweise nicht mehr in eine vom Anbieter verwaltete Ausführungs-VM kopiert werden.

Für seine Entscheidungen benötigt der Agent weiterhin Kontext. Während eines Laufs übermittelt der Worker an Cursor die benötigten Dateiinhalte, Terminalausgaben, Diffs, Screenshots, Ergebnisse lokaler MCP-Aufrufe und Routing-Metadaten. Auch Screenshots, Videos und Log-Verweise können in einen von Cursor verwalteten Artefaktspeicher hochgeladen werden, damit sie in Pull Requests und im Dashboard erscheinen.

Der Artefakt-Host lässt sich blockieren, ohne den Agenten anzuhalten; die Artefakte fehlen dann allerdings im Pull Request und im Dashboard. Auch der Privacy Mode greift: Code, den der Worker sendet, wird weder von Cursor noch von dessen Modellanbietern zum Training verwendet. Offline wird die Sitzung dadurch nicht.

Daraus folgt die erste geschäftliche Konsequenz: Die Sicherheitsprüfung kann den Ausführungsort nun getrennt von der Modellverarbeitung genehmigen, muss aber weiterhin beides freigeben.

Wer davon profitiert – und was sich im Betrieb ändert

Ein Enterprise-Backend-Team mit internen Diensten

Ein Backend-Team benötigt möglicherweise eine private Paket-Registry, eine Staging-Datenbank und Service-Endpunkte, die aus einer verwalteten VM nicht erreichbar sind. Ein Team Pool kann im selben kontrollierten Netzwerk laufen und den Build ausführen, ohne dafür eine eingehende Route für Cursor öffnen zu müssen.

Der Gewinn liegt in der Zugriffskontrolle, nicht automatisch im Datenschutz. Das Plattformteam kann seine bestehenden Netzwerkrichtlinien und den vorhandenen Secret Store nutzen; das Sicherheitsteam prüft gezielt, welche Ergebnisse die ausgehende Verbindung passieren.

Ein an Macs gebundenes iOS-Team

Von Cursor verwaltete Cloud Agents laufen auf Ubuntu-VMs. Benötigt ein Team für die iOS-Entwicklung Mac-Hardware, kann es Macs als Worker registrieren, die erforderlichen Berechtigungen zur Rechnersteuerung hinzufügen und einen Agenten auf diesem Rechner klicken, tippen, Screenshots erstellen oder den Browser bedienen lassen.

Der Vorteil: Der Remote-Agent arbeitet auf derselben Hardwareklasse wie der Build. Die Kehrseite kennt jedes Team mit einer Mac-Build-Flotte: uneinheitliche Images, Berechtigungen, Verfügbarkeit, Bereinigung und Austausch bleiben in eigener Verantwortung.

Ein Plattformteam mit stark schwankender Agentennachfrage

Ein Plattformteam kann Cloudflare Containers hinter einem Team Pool betreiben. Die Referenzvorlage startet für jede übernommene Sitzung einen isolierten Container, lässt ihn von einem Durable Object verwalten und kann Repository-Snapshots in R2 zwischenspeichern.

Der Pool bleibt bestehen, auch wenn keine Worker verbunden sind; die Kapazität kann daher auf null skalieren. Sobald neue Arbeit eintrifft, übernimmt der Controller die Anfrage und startet einen Container. So folgt die Rechenleistung der tatsächlichen Nutzung, statt dauerhaft eine warme Flotte vorzuhalten.

Ein Entwickler mit einer persistenten Devbox

My Machines passt zu Entwicklern, deren Projekt auf lokale Tools oder einen nur mit Aufwand reproduzierbaren Zustand angewiesen ist. Mehrere Agenten können denselben Rechner gemeinsam nutzen – für eine persönliche Devbox bequem, bei sensiblen Aufgaben jedoch ein Warnsignal.

Der Vorteil liegt in der schnellen Einrichtung. Das Risiko sind Zustandsreste zwischen den Läufen, denn Cursor löscht den Laptop nicht nach jeder Sitzung und setzt ihn auch nicht neu auf. Arbeitsverzeichnis, Zugangsdaten, Prozessbereinigung und Rechnerzustand liegen in eigener Verantwortung.

Eine lauffähige Cloudflare-Konfiguration

Die Cloudflare-Variante macht die neue Verantwortungsgrenze besonders anschaulich. Erforderlich sind Cursor Enterprise, ein Service-Account-Schlüssel des Teams mit Agent-Berechtigung, ein Cloudflare-Workers-Konto im Paid-Tarif mit Containers und R2, Node.js 20 oder neuer sowie Docker.

1. 1

   Einen Team Pool registrieren

   Zuerst die Cursor CLI installieren und prüfen, ob sie läuft. Anschließend kurzzeitig einen lokalen Worker verbinden, damit der Pool in Cursor erscheint.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Sobald der Pool sichtbar ist, den Worker mit Ctrl+C stoppen und danach unset CURSOR_API_KEY ausführen. Während des Cloudflare-Tests muss der lokale Worker gestoppt bleiben, damit er die Anfrage nicht zuerst übernimmt.

2. 2

   Die Referenzvorlage von Cursor deployen

   Die Vorlage klonen, Abhängigkeiten installieren, bei Cloudflare anmelden und den optionalen Bucket für Snapshots anlegen.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Zugangsdaten als Secrets speichern

   Den Cursor-Service-Account-Schlüssel in den Worker Secrets hinterlegen. Git-Zugangsdaten sind nur nötig, wenn die Container auf private Repositorys zugreifen sollen.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   Ein persönlicher Cursor-API-Schlüssel funktioniert für einen Team Pool nicht. Dieser Einrichtungsfehler wirkt besonders leicht wie ein Infrastrukturproblem, weil der Controller 401 zurückgibt.

4. 4

   Pool und Kapazität festlegen

   In wrangler.jsonc den Wert von CURSOR_POOL auf cloudflare-test ändern. containers[].max_instances wird auf die Höchstzahl gleichzeitig laufender Sitzungen gesetzt, die tatsächlich bereitgestellt werden soll – nicht auf die Zahl der Entwickler im Team.

   In der Referenzdatei steht max_instances standardmäßig auf 10; vorgesehen ist ein standard-1-Container mit 0.5 vCPU, 4 GiB Arbeitsspeicher und 8 GB Festplatte. Reale Builds können eine größere Variante erfordern.

5. 5

   Deployen und den ersten Lauf beobachten

   Nach dem Deployment die Ansichten für Controller und Container geöffnet lassen, während ein Cloud Agent gestartet und der selbst gehostete Pool ausgewählt wird.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   Bis der erste geplante Controller-Lauf beginnt, können bis zu fünf Minuten vergehen. Wird eine übernommene Sitzung nicht gestartet, liegt die Ursache meist bei der Containerkapazität, beim Klonen des Repositorys oder bei den Git-Zugangsdaten.

Die Kosten werden verlagert, nicht beseitigt

Bei von Cursor verwalteten Cloud Agents ist die Ausführungsinfrastruktur enthalten. Bei Self-Hosted Machines wird das gewählte Modell weiterhin zu den Cursor-Preisen abgerechnet; hinzu kommt die eigene Worker-Rechnung. Team Pools setzen außerdem einen Enterprise-Vertrag mit individuell vereinbartem Preis voraus.

Cloudflare zeigt, wie sich diese zusätzliche Kostenposition zusammensetzt. Das Containers-Produkt ist Teil des Workers-Paid-Tarifs für $5 pro Monat. Enthalten sind 25 GiB-Stunden Arbeitsspeicher, 375 vCPU-Minuten und 200 GB-Stunden Festplatte. Darüber hinaus kostet Arbeitsspeicher $0.0000025 pro GiB-Sekunde, aktive CPU-Zeit $0.000020 pro vCPU-Sekunde und bereitgestellter Speicherplatz $0.00000007 pro GB-Sekunde.

Für ein Rechenbeispiel dient die standard-1-Konfiguration der Referenzvorlage: 100 Sitzungen arbeiten jeweils eine Stunde lang unter voller Auslastung der verfügbaren CPU und durchlaufen anschließend das fünfminütige Leerlauffenster der Vorlage. Nach Abzug der Inklusivnutzung ergeben sich Containerkosten von rund $12 für den Monat:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

Das ist lediglich ein Infrastrukturbeispiel, nicht die gesamte Cursor-Rechnung. Nicht enthalten sind die Nutzung von Workers und Durable Objects, Logs, Egress, R2, der Enterprise-Vertrag, die Modellnutzung und das Personal für den Flottenbetrieb. Außerdem setzt die Rechnung voraus, dass die kleinste Vorlagenkonfiguration genügt. Ein Repository mit rechenintensiven Kompiliervorgängen kann einen größeren Container erzwingen.

Die teure Entscheidung betrifft häufig nicht den Sekundenpreis, sondern die Strategie für vorgehaltene Kapazität. Der generische Pool-Worker von Cursor verwendet standardmäßig ein Wiederverbindungsfenster von 3,600 Sekunden; die Cloudflare-Vorlage verkürzt es auf 300 Sekunden. Ein längeres Fenster beschleunigt Folge-Prompts, hält aber die Abrechnung von bereitgestelltem Arbeitsspeicher und Festplattenplatz aktiv. Ein kürzeres Fenster senkt die Leerlaufkosten und führt zu mehr Kaltstarts.

Auch die Kapazität liegt in eigener Hand. Die Vorlage ist für 10 gleichzeitig laufende Container ausgelegt. Ist die gewählte Kapazität, das Kontolimit oder der zugrunde liegende Host nicht verfügbar, wartet die nächste Anfrage oder startet nicht. Cursor kann Arbeit an einen Pool weiterleiten, aber keine nicht bereitgestellte Kapazität erzeugen.

Für die Isolation gilt dasselbe Prinzip. Die Cloudflare-Vorlage stellt jeder Sitzung einen eigenen Container bereit. Auf einem persönlichen Rechner können mehrere Agenten denselben Host nutzen. Verlangt eine Richtlinie nach einer frischen VM, einer gelöschten Festplatte, Mandantentrennung oder einer sauberen Secret-Grenze nach jedem Lauf, muss dieses Verhalten selbst umgesetzt und überprüft werden.

Für Patches braucht es nun einen eigenen Betriebsrhythmus. Das Team verantwortet Basis-Image, Cursor CLI, Build-Tools, Zertifikate, Abhängigkeiten und Rollout. Bei Cloudflare stoppt das Deployment eines neuen Container-Images laufende Container. Ein Update muss daher aktive Sitzungen abwarten oder deren Unterbrechung in Kauf nehmen.

Was jetzt zu tun ist

Zeitnahes Handeln lohnt sich, wenn ein Cloud Agent spezielle Hardware, ein individuelles Image oder Tool-Zugriff benötigt, den verwaltete Netzwerkanbindungen nicht bereitstellen können. Sinnvoll ist ein kleiner Pool mit einem risikoarmen Repository. Modellverarbeitung und zurückgesendete Tool-Daten gehören weiterhin in die Sicherheitsprüfung, denn der neue Ausführungsort beseitigt keinen dieser beiden Prüfpunkte.

Abwarten ist sinnvoll, wenn lediglich der Zugriff auf ein privates Quellcode-Repository oder einen internen Dienst fehlt. Cursor empfiehlt, zunächst verwaltete Umgebungen, Netzwerkregeln, Tailscale, AWS PrivateLink oder Cloudflare Tunnel zu erproben, bevor eine eigene Worker-Flotte aufgebaut wird. Bei diesen Wegen bleiben Host-Lebenszyklus und Isolation in der Verantwortung von Cursor.

Keine Änderung ist nötig, wenn verwaltete Cloud Agents die Richtlinien bereits erfüllen und den Build reproduzieren. Self-Hosting erweitert die Fähigkeiten des Modells nicht. Es verändert den Ausführungsort und die betriebliche Verantwortung.

Der konkrete Schritt für Montag: Ein repräsentatives Repository auswählen, festhalten, welche Codebestandteile, Secrets, Tool-Ausgaben und Artefakte die Grenze passieren dürfen, und denselben Build anschließend auf einem verwalteten Agenten sowie in einem streng begrenzten Self-Hosted Pool ausführen. Wartezeit in der Queue, Containerstunden, akzeptierte Änderungen, fehlgeschlagene Bereinigungen und den Aufwand für die Image-Pflege dokumentieren. Die Flotte sollte nur genehmigt werden, wenn der Kontrollgewinn die zweite Rechnung rechtfertigt.

Den nächsten praxisnahen Leitfaden für KI-Workflows per Newsletter erhalten.