Cursor hat Self-Hosted Machines eingeführt und erlaubt es Teams damit, den Werkzeug-Ausführungsteil ihrer Cloud-Coding-Agenten auf selbst verwalteten Rechnern laufen zu lassen. Verlagert wird nur die Ausführungsumgebung: Die Agenten-Schleife, das Reasoning und die Planung bleiben weiterhin in der Cursor-Cloud, und auch das Starten und Einplanen von Aufgaben übernimmt weiterhin Cursor.
Die Verbindung läuft umgekehrt auf: Der Firmenrechner installiert die Cursor-CLI, führt agent worker start aus und baut von dort eine dauerhafte ausgehende HTTPS-Verbindung zur Cursor-Cloud auf. Cursor schreibt ausdrücklich, dass die Plattform niemals von sich aus eine Verbindung in das Unternehmensnetzwerk hinein aufbaut. Für Sicherheitsteams bedeutet das einen reinen Ausgangskanal, für den die Firewall-Regeln keine eingehenden Ports öffnen müssen.
Warum die Ausführung zurückgeholt wird
Cursor nennt drei Szenarien. Erstens, wenn der Agent bei der Arbeit direkten Zugriff auf interne Code-Repositories, interne Dienste und Datenbanken braucht, die eine gehostete virtuelle Maschine nicht erreicht. Zweitens, wenn spezielle Hardware nötig ist – etwa eine GPU für Training oder ein Mac zum Bauen von iOS-Apps. Drittens, wenn das Betriebssystem oder die Build-Pipeline selbst zu schwer ist, um in ein Standard-Cloud-Image zu passen.
Alle drei Fälle betreffen vor allem große Unternehmen. Kleine und mittlere Teams stoßen bei gehosteten Sandboxes kaum auf Hindernisse, während Finanzwesen, Gesundheitswesen und große Fertigungsbetriebe oft Compliance-Vorgaben haben, die es schlicht ausschließen, dass Code auf eine Drittinfrastruktur gelangt. Solche Kunden konnten Agenten bislang gar nicht erst hereinlassen.
Zwei Betriebsformen und eine Reihe von Partnern
Die Konfiguration gibt es in zwei Stufen: My Machines hängt einen einzelnen Laptop oder eine einzelne virtuelle Maschine an ein persönliches Konto. Pools ist eine benannte Warteschlange für Team- und Unternehmensebene, die je nach Anfragevolumen automatisch hoch- und herunterskaliert. Letzteres ist für Szenarien gedacht, in denen Dutzende bis Hunderte Menschen sich einen Pool von Build-Maschinen teilen.
Auf der Sandbox-Seite hat Cursor mit einer Reihe von Anbietern zusammengearbeitet, darunter AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace und Vercel. Diese Namen zusammen zeigen, wie sich Cursor positioniert: Das Unternehmen will keine eigene isolierte Laufzeitumgebung bauen, sondern überlässt diese Schicht denen, die sie bereits betreiben, und konzentriert sich selbst auf Agenten-Scheduling und die Modelle. Namespace bietet dabei etwas Besonderes: Für jede Cloud-Agenten-Session kann ein echter Mac hochgefahren werden.
Linux- und Mac-Worker öffnen zudem die Browser-Steuerung – es genügt, Chrome oder die Chromium-Abhängigkeiten auf dem Rechner zu installieren, damit der Agent selbstständig eine Seite öffnen und Änderungen überprüfen kann.
Eine Zahl, die für sich spricht
Cursor gibt an, dass intern bereits über 60 Prozent der gemergten Pull Requests von Cloud-Agenten erstellt werden. Diese Zahl steht in einem Beitrag über den Unternehmenseinsatz – mit klarer Absicht: erst zeigen, dass man die Technik selbst nutzt, dann Kunden dazu bewegen, eigene Rechner bereitzustellen.
Auf Produktebene bewegt sich Cursor seit einem Jahr konsequent in Richtung Scheduling-Schicht: erst wurden Agenten in die Cloud verlagert, dann wurde die Startgeschwindigkeit gelöst, jetzt geht es um den Ausführungsort. Der Wettbewerb bei Coding-Tools hat sich von der Qualität der Codevervollständigung hin zur Frage verschoben, wem die Laufzeitumgebung gehört. Wer gleichzeitig „gehostetes Nutzererlebnis“ und „Code verlässt das Netzwerk nicht“ bieten kann, bekommt das Budget der Großkunden.
Quellen: offizieller Cursor-Blog, CocoLoop, öffentliche Angaben der einzelnen Sandbox-Anbieter; der Anteil von 60 Prozent an internen Merges, die Verbindungsweise und die Anbieterliste beruhen auf den offiziellen Angaben von Cursor.