Cloud-Agents auf Maschinen ausführen, die du verwaltest
Cursor Cloud-Agents können auf dynamisch geplanten Pools von Maschinen in deinem Netzwerk laufen. Du verwaltest die zugrunde liegende Infrastruktur, während die Agents weiterhin aus Cursor heraus gestartet und verwaltet werden.
So haben Teams mehr Kontrolle darüber, wo Agents laufen und welche Infrastruktur sie nutzen. Agents können direkt neben internen Diensten und der Quellcodeverwaltung arbeiten, auf spezieller Hardware laufen oder Betriebssysteme und Build-Pipelines nutzen, die sich nur schwer als Cloud-Agent-Build verpacken lassen.
Cloud-Agents erstellen inzwischen mehr als 60 % der PRs, die wir intern mergen, und übernehmen bei vielen der größten Unternehmen, mit denen wir zusammenarbeiten, einen wachsenden Anteil der Softwarearbeit. Je größer ihre Rolle wird, desto wichtiger werden auch die Maschinen, auf denen sie laufen. Diese neuen Funktionen machen es für Teams praktikabel, genau diese Infrastruktur in großem Maßstab bereitzustellen und zu verwalten.
Mit Lambda MicroVMs als Compute-Schicht für Cursor Cloud-Agents können Entwickler KI-gestützte Coding-Agents in ihrem eigenen AWS-Konto ausführen. Jede Maschine startet nahezu sofort aus einem Snapshot, wird im Leerlauf angehalten und mit vollständigem Zustand fortgesetzt. Deine Coding-Agents profitieren vom schnellen Start, der starken Isolation und dem wegfallenden Flottenmanagement von Lambda, während Cursor die Arbeit orchestriert.
Steuern, wo Agenten ausgeführt werden
Von Cursor gehostete Umgebungen bleiben der Standard für Cloud-Agenten. Jede Session läuft auf einer dedizierten VM in der Cursor-Cloud – mit installierten Abhängigkeiten und eigenen Netzwerkkontrollen. Isolierung pro Agent, Schwärzen von Secrets, Egress-Kontrollen und signierte Commits erfüllen die Sicherheitsanforderungen der meisten Teams.
Teams setzen Self-Hosted Machine in der Regel dann ein, wenn:
- die Ausführung von Agent-Tools innerhalb ihres Netzwerks stattfinden muss, mit direktem Zugriff auf die Quellcodeverwaltung, interne Dienste und Code-Repositories.
- Agenten spezielle Hardware benötigen, etwa GPUs oder Macs für die iOS-Entwicklung, oder Infrastruktur wie Kubernetes, Sandboxes oder verwaltete VMs.
- sich ihr Betriebssystem oder ihre Build-Pipeline nur schwer als Cloud-Agent-Build paketieren lässt.
Mit Self-Hosted Machine verlagert sich nur die Ausführungsumgebung, während Agent Loop, Inferenz und Planung in der Cursor-Cloud bleiben. Tool-Ausgaben fließen für die Inferenz zurück an Cursor und können Code enthalten; Agent-Transkripte können von Cursor verarbeitet und gespeichert werden. Teams greifen weiterhin über die Desktop-App, cursor.com, Mobilgeräte, Slack, GitHub und Linear auf Cloud-Agenten zu.
Worker verbinden deine Infrastruktur mit dem Cursor Agent Loop
Mit Self-Hosted Machine verlagert sich die Tool-Ausführung von einer bei Cursor gehosteten VM auf eine Maschine in deiner Umgebung. Diese Maschine hält die Arbeitskopie des Repositorys, bearbeitet Dateien und führt Befehle aus. Ein Worker verbindet sie mit dem restlichen Agent-System.
Um eine Maschine zu registrieren, startest du einen Worker: Installiere die Cursor CLI und führe agent worker start aus. Damit wird eine dauerhafte ausgehende HTTPS-Verbindung zur Cursor Cloud aufgebaut. Sobald eine Session beginnt, übernimmt das Agent Harness von Cursor Inferenz und Planung und sendet die Tool-Aufrufe anschließend an einen dedizierten Worker zur Ausführung. Der Worker liefert die Ergebnisse für die nächste Inferenzrunde zurück. Cursor baut niemals selbst eine Verbindung in dein Netzwerk auf.
Worker lassen sich auf zwei Arten konfigurieren.
- My Machines. Diese Konfiguration verbindet einen einzelnen Laptop oder eine einzelne VM mit deinem Account und eignet sich am besten für persönliche Workflows.
- Pools. Ein Pool ist eine benannte Worker-Queue, die ein Team oder ein Unternehmen bedienen kann. Die Kapazität steigt, wenn Anfragen eintreffen, und sinkt wieder, sobald sich Worker abmelden – so skaliert deine bestehende Cloud-Infrastruktur mit dem Bedarf deiner Entwickler.
Entwickler sollten die Freiheit haben, Agents auf der Plattform auszuführen, die ihren Workflow am besten unterstützt, und Unternehmen sollten keine Abstriche bei der Kontrolle darüber machen müssen, wo Agents laufen und worauf sie zugreifen können. Die Zukunft der Entwicklung wird auf leistungsstarken Agents aufbauen, die in sicheren, isolierten Umgebungen laufen.
Cloud-Agent passen sich deiner Infrastruktur an
Worker-Pools können jetzt abhängig von den Requests in der Queue skalieren und Aufgaben aus jedem Repository übernehmen. Außerdem unterstützen wir nun mehrere Sandbox-Provider sowie Computer-Use unter Linux – zusätzlich zu Mac.
Pools skalieren mit der Nachfrage und bedienen jedes Repository
Die Nachfrage nach Cloud-Agents kommt oft schubweise, und Pools von Self-Hosted Machines passen sich diesen Schüben automatisch an. Möglich macht das ein Controller, der die Anfrage-Queue überwacht und mithilfe eines vom Team bereitgestellten Spawn-Skripts bei Bedarf Maschinen startet.
Ist in einem Pool ein Worker verfügbar, übernimmt dieser die Anfrage. Andernfalls wartet die Anfrage, bis wieder Kapazität frei wird – so muss ein Team nicht entscheiden, wie viele Maschinen dauerhaft laufen sollen.
Teams können für jede Worker-Verbindung ein Idle-Timeout festlegen. Läuft es ab, kann die Maschine zurückgesetzt werden und wieder in den Pool zurückkehren. Alternativ lässt sich ihr Workspace erhalten, falls der Agent eine Folgeanfrage erhält.
Mit Self-Hosted Machines haben Teams selbst in der Hand, wo Cursor-Agents laufen, und Vercel Sandbox macht es denkbar einfach. Jede Aufgabe erhält bei Bedarf eine isolierte Sandbox – keine Fleet, die verwaltet werden muss, und nichts, was ungenutzt läuft.
Eine Maschine laufen zu lassen, während ihr Agent untätig ist, kann teuer werden. Wird die Maschine jedoch freigegeben, benötigt der Agent bei einer Folgeanfrage unter Umständen mehrere Minuten, um seinen Workspace wiederherzustellen. Mit Hibernation können Teams eine untätige Maschine stattdessen als Snapshot sichern und stoppen. Trifft innerhalb des Reconnect-Zeitfensters eine Folgeanfrage ein, wird der Snapshot wiederhergestellt und ein Worker startet mit derselben ID. Andernfalls kann die Anfrage auf eine neue Maschine wechseln.
Pools sind nicht an einzelne Repositories gebunden. Eine Anfrage muss lediglich den Pool angeben, und jeder verfügbare Worker kann sie übernehmen. So kann ein einzelner Pool viele Repositories bedienen.
Worker laufen auf unterstützten Sandbox-Providern
Für Self-Hosted Machine müssen Sie keine eigene Sandbox-Schicht von Grund auf erstellen. Wir arbeiten mit AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace und Vercel zusammen, sodass Worker überall dort gestartet und orchestriert werden können, wo die Sandboxes eines Teams bereits laufen.
Cursor Self-Hosted Machines auf Modal gibt jeder Cloud-Agent-Sitzung eine eigene Modal Sandbox – so erhält sie eine Maschine, die genau auf ihre Aufgabe zugeschnitten ist.
Agent steuern Browser unter Linux und Mac
Linux-Worker unterstützen jetzt ebenso wie Macs Computer-Use. Sind die erforderlichen Abhängigkeiten für Computer-Use installiert, einschließlich Chrome oder Chromium, kann ein Agent klicken, Screenshots aufnehmen und den Browser steuern. Du kannst seinen Desktop überwachen oder die Steuerung direkt aus Cursor heraus übernehmen.
Ohne einen Mac lassen sich keine iOS- oder macOS-Apps erstellen. Namespace Devboxes starten für jeden Cursor Cloud-Agent einen echten Mac, der diese Arbeit jetzt auf Apple Silicon erledigen kann.
Cloud-Agents in deine Umgebung holen
Teams haben ihre Infrastruktur über Jahre hinweg darauf zugeschnitten, wie sie Software erstellen. Mit Self-Hosted Machine fügen sich Cloud-Agents nun deutlich natürlicher darin ein – und wir sind gespannt, was Teams daraus machen.
Um eine Maschine zu verbinden oder einen Pool zu konfigurieren, lege in den Docs los.
