Cursor Projects im Test: der Coordinator-Agent erklärt und ausprobiert (2026)

TL;DR

Cursor Projects, das am 10. September 2026 gestartet ist, ist Cursors Antwort auf ein echtes Problem: Ein normaler KI-Chat vergisst alles, sobald du ihn schließt. Ein Project hält einen Coordinator-Agenten über Wochen am Laufen, und dieser Coordinator schreibt selbst keinen Code. Er plant die Arbeit, delegiert sie an eine Flotte von Cloud-Subagents und bringt Pull Requests zur Prüfung zurück. Er kann auch selbstständig laufen und einen Slack-Kanal oder deine offenen PRs beobachten.

Ich baue beruflich KI-Agenten, die echte Arbeit erledigen, und mein ehrliches Fazit: Das Coordinator-Modell ist die richtige Idee, und der „wachsende geteilte Kontext" ist der Teil, der wirklich zählt. Der Haken ist das Kostenmodell. Du zahlst für jeden Subagent API-Preise, und ein Coordinator, der viele davon parallel startet, ist eine Frage der Abrechnung, keine kostenlose Produktivität. Am besten für Migrationen und langfristige Wartung, übertrieben für einen schnellen Fix.

Eine Einordnung, die du vor dem Weiterlesen im Kopf behalten solltest: Cursor ist Infrastruktur zum Bauen von Software, kein Teammate, der einen Job erledigt. Wenn du eine KI willst, die eine Rolle sofort übernimmt (Support, Content), ist das eine andere Kategorie, und ich komme darauf zurück, wo sich beide treffen.

Was Cursor Projects eigentlich ist

Wenn du Cursor kennst, kennst du den Ablauf einer Session: Du öffnest einen Chat, beschreibst eine Aufgabe, der Agent bearbeitet Dateien, du prüfst, du machst weiter. Schließt du den Tab, ist der Kontext weg. Bei einem 20-Minuten-Fix ist das in Ordnung. Bei einer dreiwöchigen Migration erklärst du einem frischen Agenten immer wieder deine Codebasis.

Projects ist für den zweiten Fall gebaut. Cursor beschreibt es als Weg, „größere Arbeitspakete wie ein Feature, eine Migration oder eine komplette App" anzugehen, wobei das Project „den Kontext über Monate der Arbeit hinweg behält" und „wiederkehrende Arbeit ohne Aufforderung erledigt". Es ist das konkrete Produkt hinter der Vision der „dritten Ära der Softwareentwicklung", die Cursor im Februar skizziert hat: Du steuerst eine Flotte von Agenten, statt einen einzelnen Chat zu betreuen.

Cursor sagt, Projects laufe intern seit Monaten, darunter Migrationen mit mehreren hundert PRs, und Projects selbst sei damit ausgeliefert worden. Die Kernzahl: Neue Nutzer mergen 30 % mehr PRs, und intensive Projects-Nutzer mergen sechsmal so viele. Das ist eine interne, selbst berichtete Zahl, behandle sie also wie jede Produktivitätsstatistik eines Anbieters. Sie zeigt aber, wofür das Produkt optimiert ist: Durchsatz an gemergter Arbeit, nicht getippte Zeilen.

Das Ganze ist in der Beta und wird seit dem Starttag für alle Nutzer ausgerollt. Du startest ein Project in der linken Navigation, beschreibst, was gebaut werden soll, und der Coordinator übernimmt.

Der Coordinator-Agent: der eigentliche Wandel

Das ist der Teil, den ich unterstreichen würde. Wenn du ein Project öffnest, sprichst du nicht mit einem Coding-Agenten. Du sprichst mit einem Coordinator, und laut Cursors Changelog „schreibt der Coordinator-Agent in einem Project selbst keinen Code; er plant die Arbeit, delegiert sie an Agenten, die sie umsetzen, und bringt die fertige Arbeit zur Prüfung zu dir zurück."

Das klingt nach einer kleinen Unterscheidung. Ist es nicht. Weil der Coordinator delegiert, statt selbst auszuführen, ist er laut Cursor "nie blockiert und reagiert immer auf Anweisungen." Wer einen einzelnen Agenten an einer langen Aufgabe arbeiten gesehen hat, kennt die Frustration: Du willst umlenken, aber er steckt mitten in einer Änderung und ist nicht erreichbar. Ein Coordinator umgeht das, weil er nie derjenige ist, der selbst im Code arbeitet. Er erstellt und verwaltet Agenten in deinem Auftrag, so viele parallel, wie die Arbeit braucht, und Cursor beschreibt die Obergrenze als das Steuern von „Tausenden von Agenten über einen Coordinator".

Darunter läuft Cursors bestehendes Subagents-System, das man verstehen sollte, weil es sowohl die Stärke als auch die Kosten erklärt. Jeder Subagent „arbeitet in seinem eigenen Kontextfenster", startet bei null, arbeitet autonom und „gibt sein Ergebnis an den übergeordneten Agenten zurück". Sie können parallel laufen, und seit Cursor 2.5 kann ein Subagent sogar eigene Kind-Subagents starten, wobei der Baum dort endet: Ein Kind-Subagent kann keine weiteren starten. Mit Isolation bekommt jeder einen eigenen Git-Worktree oder eine eigene Cloud-VM mit eigenem Klon des Repos, damit sich parallele Agenten nicht gegenseitig überschreiben. Änderungen bleiben auf getrennten Branches, bis der übergeordnete Agent mergt.

Der ehrliche Kompromiss, direkt aus Cursors eigener Dokumentation: Fünf parallele Subagents verbrauchen etwa fünfmal so viele Tokens wie ein einzelner Agent, und bei einfachen Aufgaben können sie langsamer sein, weil jeder bei null beginnt. Du kaufst Kontext-Isolation, keine Geschwindigkeit. Es ist fair, dass Cursor das offen sagt, und es ist der Satz, an den ich einen Ausgabenalarm hängen würde.

Standardmäßig in der Cloud: wo die Arbeit tatsächlich läuft

Ein Project läuft in der Cloud, nicht auf deinem Laptop. Cursors Formulierung: „standardmäßig Cloud, lokal bei Bedarf." Ein Project „läuft auf einem eigenen Computer, das Zuklappen deines Laptops stoppt es also nicht", wodurch es „mehr Subagents parallel ausführen kann, als dein Laptop tragen würde". Wenn etwas wirklich deinen Rechner braucht, startet der Coordinator einen lokalen Agenten, der es dort ausführt.

Das basiert auf Cloud Agents, der Infrastruktur, die Cursor früher Background Agents nannte: isolierte VMs mit vollständigen Entwicklungsumgebungen, die dein Repo von GitHub, GitLab, Azure DevOps oder Bitbucket klonen, auf einem Branch arbeiten und merge-fertige PRs mit Artefakten wie Screenshots und Logs zurückschieben. Du kannst sogar den Remote-Desktop eines Agenten steuern, um die geänderte Software auszuprobieren, ohne den Branch lokal auszuchecken.

Der Schritt, den viele unterschätzen, ist die Umgebung. Cursor sagt es deutlich: „Keine Entwicklungsumgebung für deine Cloud-Agenten einzurichten ist, als würdest du deinen Entwicklern keinen Computer geben." Du konfigurierst sie mit einem Dockerfile oder einem gespeicherten Snapshot, und wenn du das überspringst, arbeiten deine Agenten blind. Wer schon einmal einen neuen Mitarbeiter eingearbeitet und gesehen hat, wie er einen Tag an einem kaputten lokalen Setup verliert, weiß, warum das wichtig ist. Es ist dieselbe Steuer, einmal pro Project gezahlt.

Geteilter Kontext: der Teil, der sich aufsummiert

Das ist das Feature, das ich für wirklich unterschätzt halte, und es macht Projects zu mehr als „Background Agents mit schönerem Namen".

Cursors Aussage: „Du solltest nicht jedes Mal einen Agenten einarbeiten müssen, wenn du eine Aufgabe startest." Deshalb pflegt jedes Project eine Reihe von Dateien, die synchronisiert werden, und zwar über jede Cloud- und lokale Maschine, die seine Agenten nutzen. Agenten schreiben Recherche, Artefakte und „was sie über die Codebasis lernen und wie du Arbeit am liebsten erledigt haben willst" in diesen geteilten Kontext. Cursors Beispiel: Wenn ein Agent herausfindet, wie man einen Service testet, können alle künftigen Agenten diese Anleitung nutzen.

Das ist der Zinseszins-Effekt. Der Kontext „wächst mit dem Project und macht den Coordinator mit der Zeit effektiver". Es ist der Unterschied zwischen einem Auftragnehmer, der deine Codebasis jeden Morgen vergisst, und einem, der seit einem Monat im Team ist. Ich habe Systeme gebaut, bei denen es vor allem darum geht, einem Agenten vorab den richtigen Unternehmenskontext zu geben, und die zweite Variante ist deutlich mehr wert, als es auf einer Launch-Folie aussieht. Es ist außerdem das unspektakulärste Feature der Ankündigung, was meist ein Zeichen dafür ist, dass es das eigentliche ist.

Subscriptions: Cursor Projects im Autopilot

Die andere Schlagzeile ist, dass ein Project ohne dich handeln kann. Cursor nennt das Subscriptions, und der Coordinator kann „einen Slack-Kanal beobachten, nach Zeitplan laufen oder allen deinen PRs folgen, CI reparieren und reagieren, wenn sie geöffnet oder gemergt werden." Das konkrete Beispiel aus dem Changelog: Slack verbinden, auf einen Bugreport-Kanal richten, und der Coordinator delegiert jedes Mal einen Fix, wenn ein Bug eintrifft.

Darunter steckt Cursors Automations-System, und es kann mehr, als der Projects-Blog verrät. Trigger können nach Cron-Zeitplan, bei Source-Control-Ereignissen (PR geöffnet, gepusht, gemergt, CI abgeschlossen), bei Slack-Nachrichten oder Emoji-Reaktionen, bei einem Webhook, an den du postest, oder bei Ereignissen aus Linear, Sentry und PagerDuty auslösen. Eine Automation kann dann PRs öffnen, kommentieren, Reviewer anfragen, in Slack posten, MCP-Server nutzen und in einer MEMORIES.md-Datei über mehrere Läufe hinweg persistente Notizen führen.

Zwei Grenzen, die du kennen solltest, bevor du dich darauf verlässt: Nur öffentliche Slack-Kanäle sind für Slack-Trigger derzeit sichtbar, und PR-Trigger laufen nicht bei PRs aus Forks (außer dem Merged-Trigger). Beides ist kein Ausschlusskriterium, aber du willst es vorher herausfinden, nicht erst, nachdem du einen Workflow darum gebaut hast.

Die drei Aufgaben, für die Cursor Projects gebaut ist

Cursor ist erfrischend konkret darin, wo das passt, und es deckt sich mit dem, wofür ich es tatsächlich einsetzen würde.

• Feature-Arbeit. Ein Project beginnt damit, dass Agenten das System erforschen und festhalten, was sie lernen. Dann plant der Coordinator und schickt Agenten, Teile parallel zu bauen und zu testen. Nach dem Release kann dasselbe Project Logs überwachen und Bugreports bearbeiten „mit dem vollen Kontext hinter den ursprünglichen Entscheidungen". Dieser letzte Punkt ist der Gewinn aus dem geteilten Kontext.
• Migrationen. Cursor nennt sie "leicht zu beginnen und schwer zu beenden", und das stimmt genau. Du legst mit dem Coordinator einen sicheren Ansatz fest, und er wendet ihn schrittweise auf die Codebasis an. Anfangs prüfst du jeden PR genau, dann lockerst du, wenn die Fixes halten.
• Gardening. Arbeit, die nie endet: Codequalität, Regressionen im Blick behalten. Cursors reales Beispiel ist ein Design-System-Project, in dem der Coordinator „jeden neuen PR scannt, Komponenten herauslöst, die ins Design-System gehören, und eine Lint-Regel hinzufügt, sobald er denselben Fehler zweimal sieht" und auf dem Weg ist, 20 bis 100 PRs pro Tag anzufassen.

Wenn deine Arbeit nicht wie eines dieser drei aussieht, ist ein Project wahrscheinlich das falsche Werkzeug. Hier ist der schnelle Check, den ich vor dem Öffnen eines Projects machen würde.

Was Cursor Projects kostet

Hier würde ich langsamer werden. Es gibt keinen Listenpreis für Projects, und das ist kein Versteckspiel von Cursor, sondern tatsächlich nutzungsbasiert. Projects laufen auf Cloud Agents, und die Abrechnung folgt daraus.

Was du verinnerlichen solltest: Ein Coordinator, der viele Subagents parallel startet, ist ein Kostenmultiplikator, kein Gratis-Mittagessen. In einem ausgelasteten Project sind „Tausende Agenten" eine Marketing-Obergrenze, aber schon eine Handvoll paralleler Cloud-Agenten zu Preisen von Spitzenmodellen summiert sich schnell. Genau diese Sorge tauchte in den Community-Reaktionen auf, und sie ist berechtigt. Wenn du ohnehin deine KI-Agent-Kosten pro Lösung im Blick hast, brauchst du hier dieselbe Disziplin: Setze Ausgabenlimits und behandle automatisierte Subscriptions wie einen laufenden Zähler.

Was die Leute sagen

Der Launch-Tweet lief gut, 5.861 Likes am ersten Tag. Aber die aufschlussreichste Reaktion war die Top-Antwort, elf Minuten später gepostet:

"can you pls just merge the subscriptions instead of just adding extra features?"

Gokul Bala, X

Das ist die Spannung des Starttags in einer Zeile. Cursor stapelt Funktionen, und einige seiner engagiertesten Nutzer würden lieber sehen, dass es vereinfacht, was schon da ist, statt eine weitere kostenpflichtige Oberfläche auszuliefern. Es ist weniger Kritik am Feature als ein Signal, dass das Paket aus Coordinator, Cloud und Subscriptions auf einmal sehr viel neue Fläche ist.

Die schärfere strategische Frage stellte der Produktmanager Aakash Gupta, der im April 2026 über Cursors Richtung der Agentenflotten schrieb:

"They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."

Aakash Gupta, X

Ich glaube, das ist die eigentliche Wette von Projects. Die Modelle werden zunehmend austauschbar, also wettet Cursor darauf, dass die Orchestrierungsebene, also Coordinator, geteilter Kontext und Trigger, der Ort ist, an dem es Nutzer binden kann. Ob du ein Cockpit oder eine Kommandozeile willst, ist wirklich Geschmackssache, und vernünftige Entwickler landen auf beiden Seiten. Wenn du diese Entscheidung abwägst, decken unsere Übersicht der Cursor-Alternativen und der Vergleich Cursor vs Windsurf das Spektrum „Cockpit vs. Terminal" ab, ebenso wie der Vergleich mit OpenAI Codex oder der Claude Code CLI.

Wo Projects passt und wo nicht

Mein Fazit nach dem Durcharbeiten der Doku: Cursor Projects ist die stimmigste Version von „eine Flotte von Agenten verwalten", die ich bisher habe erscheinen sehen, und das Design des geteilten Kontexts ist der Grund. Das Coordinator-Modell löst ein echtes Ärgernis, die Cloud-Ausführung ist sinnvoll, und die Ehrlichkeit der Doku bei Token-Kosten und langsamen Subagents schafft Vertrauen.

Wo ich auf die Bremse treten würde: Es ist Beta, das Kostenmodell belohnt Zurückhaltung, und das Ganze setzt voraus, dass deine Arbeit groß und langlebig ist. Für einen Solo-Entwickler mit schnellen Änderungen ist das mehr Maschinerie, als der Job braucht, und ein einfacher Chat ist das bessere Werkzeug. Es verschärft auch eine echte Sorge, die eine Antwort im Launch-Thread gut auf den Punkt brachte: Je mehr ein Coordinator delegiert, desto weniger Zeilen Code wurden von einem Menschen geschrieben, der sie geprüft hat. Projects verlässt sich stark darauf, dass du die zurückgegebenen PRs diszipliniert prüfst. Das ist ein Feature, kein Fehler, aber es liegt bei dir.

Und es gibt einen Kategoriepunkt, den es wert ist anzusprechen, weil ich beim Lesen der Ankündigung ständig daran denken musste.

Cursor ist Infrastruktur; ein Teammate ist etwas anderes

Cursor Projects ist Infrastruktur für agentisches Coding. Es baut deine Software. Es ist kein Teammate, der auftaucht und einen klar definierten Job für dich erledigt, und es versucht auch nicht, einer zu sein. Das ist ein echter Unterschied, keine Kritik.

So denke ich über das, was wir bei eesel bauen. eesel ist eine KI-Teammate-Plattform, auf der du einsatzbereite Teammates für bestimmte Jobs einstellst: einen KI-Helpdesk-Teammate, der deiner Support-Warteschlange beitritt, und einen KI-Blogautor. Jeder kommt mit den Fähigkeiten, Integrationen und dem Unternehmenskontext für seine Rolle und arbeitet ab Tag null. Wo Cursor dir ein Cockpit zum Bauen von Software gibt, gibt dir eesel einen Kollegen, der die Arbeit schon macht.

Interessant ist, wo sich beide treffen. Denn Cursor Projects liebt eine CLI und einen Trigger, und eesel auch. Die eesel CLI ist ein agentenfreundlicher Weg, denselben eesel-Teammate und Workspace zu bedienen, den du aus dem Dashboard nutzt: Eine Person kann sie im Terminal ausführen, Skripte können sie automatisieren, und Coding-Agenten wie Cursor, Claude Code und Codex können sie steuern. So kann ein Cursor Project, das deine App repariert, in einem Atemzug die eesel CLI bitten, die Anweisungen deines Support-Teammates zu prüfen, eine begrenzte Änderung vorzuschlagen und die Testantworten zu sichten, bevor ein Mensch sie freigibt. Derselbe Instinkt des geteilten Kontexts, angewandt auf den Teammate, der deine Kunden beantwortet, statt auf den Code, der sie bedient.

Wenn dich Projects über Agenten nachdenken lässt, die echte Arbeit erledigen, während du schläfst, ist das der richtige Instinkt. Für die Support- und Content-Seite dieser Arbeit füllt eesel diese Lücke, und es ist kostenlos testbar.

Teste eesel für die Arbeit, die ein Coding-Agent nicht übernimmt

Cursor Projects baut gern deinen Abrechnungsablauf um. Es beantwortet aber nicht die 400 „Wo bleibt meine Erstattung?"-Tickets, die solche Entscheidungen auslösen. Dafür wird ein eesel KI-Helpdesk-Teammate eingestellt: Er verbindet sich in Minuten mit Zendesk (und Freshdesk, Gorgias, Slack und mehr), lernt aus deinen früheren Tickets und deinem Help Center und beginnt vom ersten Tag an, Antworten zu entwerfen oder Tickets zu lösen. Es ist ein KI-Agent, der für die Warteschlange eingestellt wird und zu einem festen Preis pro Ticket statt pro Platz abgerechnet wird.

Und wenn du im Terminal lebst, musst du es nicht verlassen. Mit der eesel CLI kann dein Coding-Agent denselben eesel-Teammate prüfen und anpassen, den auch das Dashboard nutzt, sodass die KI, die deinen Code ausliefert, auch helfen kann, die KI zu justieren, die deine Kunden unterstützt. Du kannst eesel kostenlos testen, ohne Kreditkarte, und es gegen deine echten historischen Tickets simulieren, bevor es je ein Live-Gespräch berührt.