Cursor hat am 10. September 2026 Projects gestartet. Statt für jede Aufgabe einen frischen Chat zu öffnen, arbeitest du in einem dauerhaften Thread mit einem Coordinator-Agenten, der ein großes Arbeitspaket plant und die eigentliche Programmierung an eine Flotte parallel laufender Subagenten übergibt, größtenteils in der Cloud.
Das Interessante ist nicht „mehr Agenten“. Es ist die Veränderung dessen, was dein Job wird. Du hörst auf, einen einzelnen Agenten zu beaufsichtigen, und steuerst die Arbeit auf höherer Ebene: Du prüfst fertige Ergebnisse, statt beim Tippen des Codes zuzusehen. Cursor nennt das die „dritte Ära der Softwareentwicklung“ und sagt intern, Nutzer, die überwiegend in Projects arbeiten, mergen sechsmal so viele PRs.
Es ist wirklich nützlich für Arbeit, die einen einzelnen Chat überdauert: große Features, lange Migrationen und endlose Wartung. Es ist aber auch eine echte Frage nach Kosten und Kontrolle, denn ein Coordinator, der viele Cloud-Subagenten startet, rechnet zu API-Preisen ab und schiebt mehr Codezeilen zwischen dich und den letzten Menschen, der sie gelesen hat. Ich baue bei eesel beruflich Agentensysteme, deshalb zeige ich unten genau, wie Projects funktioniert, was es kostet, wo die Skeptiker recht haben und wie dieses Modell „du steuerst, Agenten arbeiten“ außerhalb von Code aussieht.
Was Cursor Projects eigentlich ist
Ein Project ist ein Container für einen großen Job. Cursors eigene Beschreibung: Es erlaubt dir, „größere Arbeitspakete wie ein Feature, eine Migration oder eine komplette App anzugehen“. Während ein Chat alles vergisst, sobald du ihn schließt, behält ein Project den Kontext über Monate, kann an viele Agenten delegieren und sogar bei wiederkehrender Arbeit ohne Aufforderung tätig werden.
Du startest eines über die linke Navigation, beschreibst, was gebaut werden soll, und der Coordinator übernimmt von dort. Es ist in der Beta und wird ab dem Startdatum für alle Nutzer ausgerollt.
Wenn du Cursor bisher als Autovervollständigung plus Chat genutzt hast, ist das ein größerer Sprung, als das Changelog klingen lässt. Die Arbeitseinheit wechselt von „einer Nachricht“ zu „einem Project“, und das, was du verwaltest, wechselt vom „Code“ zu den „Agenten“.
Der eigentliche Wandel: vom einzelnen Agenten zum Coordinator
Cursor arbeitet schon eine Weile darauf hin. Bereits im Februar 2026 beschrieb es eine „dritte Ära“, in der „Flotten von Agenten ganze Arbeitspakete übernehmen“ und der Entwickler die Arbeit steuert statt jeden einzelnen Agenten. Projects ist diese Vision in der Praxis.
Hier ist die Entwicklung, weil sie am klarsten zeigt, was sich geändert hat:
In Ära eins hast du den Code geschrieben, und die KI hat die nächste Zeile vorgeschlagen. In Ära zwei (wo die meisten agentischen Coding-Tools noch stehen) promptest du pro Aufgabe einen Agenten und siehst ihm bei der Arbeit zu. Projects ist eine Wette auf Ära drei: Du steuerst einen Coordinator, und der Coordinator führt die Flotte. Der Coordinator schreibt selbst keinen Code; weil er delegiert statt ausführt, „ist er nie blockiert und reagiert stets auf Anweisungen“.
Dieses letzte Detail ist wichtiger, als es aussieht. Ein einzelner Agent fühlt sich frustrierend an, weil er sich in die Arbeit vergräbt und du wartest. Ein Coordinator bleibt frei, um mit dir zu sprechen, während seine Subagenten schuften, und genau das lässt „steuern, nicht beaufsichtigen“ in der Praxis anders anfühlen.
Wie ein Project unter der Haube funktioniert
Hinter dem Marketing ist Projects eine dünne Orchestrierungsschicht über vier Dingen, die Cursor schon hatte: dem Coordinator, Subagenten, Cloud-Ausführung und Automatisierungs-Auslösern. So greifen sie ineinander.
Der Coordinator plant und delegiert
Du überwachst ein Project, indem du mit seinem Coordinator-Agenten chattest. Er „plant die Arbeit, delegiert sie an Agenten, die sie umsetzen, und bringt die fertige Arbeit zur Prüfung zu dir zurück“, erstellt und verwaltet in deinem Auftrag Agenten und führt so viele parallel aus, wie die Arbeit braucht. Darunter arbeitet jeder Subagent in seinem eigenen Kontextfenster, läuft autonom und liefert sein Ergebnis an den übergeordneten Agenten zurück. Seit Cursor 2.5 können Subagenten sogar eigene untergeordnete Subagenten starten, allerdings endet der Baum nach einer Ebene.
Eine ehrliche Einschränkung, die die Doku offen nennt: Parallelität ist kein kostenloses Tempo. Fünf parallel laufende Subagenten verbrauchen etwa fünfmal so viele Tokens wie ein einzelner Agent, und bei einfachen Aufgaben können sie sogar langsamer sein, weil jeder mit sauberem Kontext startet. Der Gewinn liegt in Isolation und Skalierung, nicht in reinem Tempo.
Standardmäßig Cloud, lokal bei Bedarf
Projects laufen auf Cloud Agents (den isolierten Cloud-VMs, früher Background Agents genannt). Ein Project „läuft auf seinem eigenen Computer, sodass das Schließen deines Laptops es nicht stoppt“, wodurch weit mehr Subagenten parallel laufen können, als deine Maschine verkraften würde. Wenn etwas auf deinem Rechner laufen muss, startet der Coordinator dafür einen lokalen Agenten.
Entscheidend ist hier die Umgebung. Wie Cursor es ausdrückt: „Keine Entwicklungsumgebung für deine Cloud-Agenten einzurichten, ist, als würdest du deinen Ingenieuren keinen Computer geben.“ Du definierst sie per agentengeführter Einrichtung, gespeichertem Snapshot oder Dockerfile, und Cloud-Agenten klonen von GitHub, GitLab, Azure DevOps oder Bitbucket und pushen zur Übergabe auf einen Branch. Wenn du die GitHub-Integration von Claude Code oder Ähnliches eingerichtet hast, wird dir das Muster vertraut vorkommen.
Geteilter Kontext, der sich aufbaut
Das ist der Teil, den ich am meisten unterschätzt finde. Cursors Satz lautet: „Du solltest einen Agenten nicht jedes Mal neu einarbeiten müssen, wenn du eine Aufgabe startest.“ Jedes Project führt eine Reihe von Dateien, die über jede Cloud- und lokale Maschine synchronisiert werden, die seine Agenten nutzen, und Agenten schreiben Recherchen, Artefakte und ihr Wissen über deine Codebasis hinein. Das Beispiel: „Wenn ein Agent herausfindet, wie man einen Service testet, kann jeder künftige Agent diese Anweisungen nutzen.“
Das Ergebnis: Der Kontext wächst mit dem Project, und der Coordinator wird mit der Zeit effektiver. Es ist dasselbe Prinzip, einem KI-Support-Agenten eine echte Wissensdatenbank zu geben, statt ihm in jeder Sitzung dein Produkt neu zu erklären, nur eben auf eine Codebasis gerichtet.
Subscriptions laufen ohne Prompt
Der Coordinator kann einen Slack-Kanal beobachten, nach Zeitplan laufen oder allen deinen PRs folgen, CI reparieren und handeln, wenn sie geöffnet oder gemergt werden. Cursor vermarktet das als „Subscriptions“; in der Doku ist es das Automations-System, das Cloud-Agenten nach Zeitplan oder bei Ereignissen aus GitHub, GitLab, Slack, Webhooks, Linear, Sentry und PagerDuty auslöst. Richte es auf einen Fehlermelde-Kanal, und es beginnt zu delegieren, sobald ein Bug eingeht. Das ist die Automatisierungs-Schicht, die Projects von einem Tool, das du öffnest, zu etwas macht, das läuft, dieselbe auslösergesteuerte Idee wie bei einem Slack-KI-Chatbot oder einem KI-Helpdesk-Chatbot, der auf neue Nachrichten reagiert.
Die drei Arten von Arbeit, für die Projects gebaut ist
Cursor ist erfrischend konkret, wo das passt, und es lässt sich auf drei Muster abbilden. Das lohnt sich zu verinnerlichen, denn Projects ist ganz sicher nichts für eine Fünf-Minuten-Korrektur.
- Feature-Arbeit. Agenten erforschen das System und halten ihr Wissen als geteilten Kontext fest, der Coordinator plant, und Subagenten bauen und testen Teile parallel. Nach dem Release kann dasselbe Project Logs überwachen und Bugmeldungen mit dem vollen Kontext hinter den ursprünglichen Entscheidungen bearbeiten.
- Migrationen. Cursors Formulierung für Arbeit, die „leicht zu beginnen und schwer zu beenden“ ist. Du einigst dich mit dem Coordinator auf einen sicheren Ansatz, dann wendet er diesen schrittweise auf die gesamte Codebasis an. Anfangs prüfst du jeden PR genau und lockerst, sobald das Muster trägt.
- Gardening. Arbeit, die nie wirklich endet, etwa Codequalität und Regressionen. Cursors eigenes Beispiel ist ein Design-System-Project, dessen Coordinator jeden neuen PR scannt, Komponenten extrahiert und eine Lint-Regel hinzufügt, sobald er denselben Fehler zweimal sieht, und auf Kurs ist, 20 bis 100 PRs pro Tag zu bearbeiten.
Der gemeinsame Nenner: Es lohnt sich, wenn die Arbeit „einen einzelnen Chat überdauern wird“. Für einen schnellen Bugfix ist ein einfacher Agent schneller und günstiger.
Du bist unsicher, in welche Kategorie deine Arbeit fällt? So prüfst du es schnell, bevor du ein Project startest.
Passt gut. Lass Agenten zuerst recherchieren, den Coordinator planen, dann Teile parallel bauen und testen, und halte das Project am Leben, um später Bugs zu bearbeiten.
Der klassische Projects-Fall: leicht zu beginnen, schwer zu beenden. Lege mit dem Coordinator einen sicheren Ansatz fest, prüfe die ersten PRs genau und lockere, sobald sich das Muster bewährt.
Richte eine Subscription ein, damit der Coordinator jeden neuen PR beobachtet, Muster extrahiert und Lint-Regeln ergänzt. Das ist der Sweet Spot „läuft ohne dich“.
Greife stattdessen zu einem einfachen Cursor-Agenten. Ein einmaliger Fix braucht keinen Coordinator, keinen geteilten Kontext und keine Cloud-VMs, und ein Project würde ohne Nutzen mehr Tokens kosten.
Was Cursor Projects kostet
Für Projects gibt es keinen Listenpreis, und das ist die ehrliche Schlagzeile. Projects laufen auf Cloud Agents, und Cloud Agents werden zum API-Preis des gewählten Modells abgerechnet. Ein kostenpflichtiger Cursor-Tarif ist erforderlich, um überhaupt Cloud-Agenten auszuführen, und ein Admin muss zuerst die Versionsverwaltung verbinden. Hier das Kostenbild in einfachen Worten.
| Was | Wie es funktioniert | Der Haken |
|---|---|---|
| Tarifvoraussetzung | Ein kostenpflichtiger Cursor-Tarif ist nötig, um Cloud-Agenten auszuführen | Der kostenlose Tarif kann Projects nicht in der Cloud ausführen |
| Abrechnungseinheit | Cloud-Agenten rechnen zum API-Preis des gewählten Modells ab | Die Kosten folgen den verbrauchten Tokens, nicht einer monatlichen Pauschale |
| Parallelität | Der Coordinator führt so viele Subagenten aus, wie die Arbeit braucht | Fünf parallele Subagenten ≈ fünfmal so viele Tokens |
| Ausgabenkontrolle | Du legst bei der ersten Nutzung ein Ausgabenlimit fest | Das Limit ist die Leitplanke; standardmäßig gibt es keine feste Obergrenze |
| Automations | Subscriptions werden nach Cloud-Agent-Nutzung abgerechnet und nutzen das maximale Kontextfenster jedes Modells | Kein Kontext-Schalter, daher können Hintergrundläufe token-lastig sein |
Ein durchgerechnetes Beispiel macht es greifbar. Das Design-System-„Gardening“-Project, das Cursor beschreibt, ist auf Kurs, 20 bis 100 PRs pro Tag zu bearbeiten. Jeder dieser Läufe ist ein Cloud-Agent (oft mehrere Subagenten), der zu Modell-API-Preisen abrechnet, den ganzen Tag, ob du zuschaust oder nicht. Das kann im Vergleich zur Arbeitszeit eines Ingenieurs ein fantastischer Deal oder eine überraschende Rechnung sein, je nach Ausgabenlimit und Gesprächigkeit der Modelle. Deshalb zählt das vollständige Bild der Cursor-Preise mit Projects mehr denn je, und deshalb sind Sorgen um nutzungsbasierte Kosten das wiederkehrende Thema in den Community-Reaktionen, womit wir beim interessanten Teil sind.
Ist ein „Cockpit für Agentenflotten“ das, was Entwickler wirklich wollen?
Hier möchte ich fair sein, denn die Reaktion am Starttag war nicht nur Applaus. Der Launch-Post bekam 5.861 Likes, aber die lauteste frühe Antwort war Ermüdung, nicht Staunen:
"can you pls just merge the subscriptions instead of just adding extra features?"
Das ist der Top-Kommentar unter der Ankündigung selbst. Er bringt eine echte Sorge auf den Punkt: Projects stapelt eine weitere kostenpflichtige, cloud-abgerechnete Oberfläche auf ein ohnehin volles Produkt. Und im April 2026 formulierte der Produktautor Aakash Gupta die strategische Wette treffend (er schrieb über Cursors Richtung, nicht über genau diesen Launch):
"Cursor's move is to go vertical on the orchestration layer... 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."
Das ist die ganze Debatte in zwei Sätzen. Manche Entwickler lieben die überprüfbare, strukturierte Oberfläche. Elliot Arledge, der im Juli 2026 schrieb, formulierte das Pro-Argument gut:
"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."
Die Gegen-Sorge, in einer Antwort unter demselben Thread, ist diejenige, die ich am ernstesten nehmen würde: „I really fear losing control over my codebase“ (Ich fürchte wirklich, die Kontrolle über meine Codebasis zu verlieren). Je mehr der Coordinator delegiert, desto weniger Zeilen hat ein einzelner Reviewer tatsächlich gelesen. Das ist kein Grund, Projects zu meiden. Es ist ein Grund, deine Review-Disziplin genau dort zu halten, wo sie am ersten Tag war, besonders wenn das Muster „trägt“ und du versucht bist, nur noch zu überfliegen. Wenn du das gegen andere Tools abwägst, zeigen unsere Übersichten zu Cursor-Alternativen und Cursor vs. Windsurf, wo jedes landet.
Wie das Modell „die Flotte steuern“ jenseits von Code aussieht
Das hat mich beim Bauen von Agentensystemen bei eesel am meisten beeindruckt: Cursor Projects ist eine Coding-spezifische Ausprägung eines Musters, das überall auftaucht. Ein Coordinator, der plant und delegiert, Subagenten, die die Arbeit erledigen, geteilter Kontext, der sich aufbaut, Auslöser, die es ohne Prompt laufen lassen. Ersetze „Codebasis“ durch „Support-Warteschlange“ oder „Content-Pipeline“, und die Architektur ist dieselbe.
Genau so ist eesel aufgebaut, nur auf andere Jobs gerichtet. eesel ist eine Plattform für KI-Teammitglieder, und du stellst einsatzbereite Teammitglieder für eine bestimmte Rolle ein statt eines Allzweck-Bots. Das aktuelle Angebot besteht aus einem KI-Helpdesk-Teammitglied und einem KI-Blog-Autor, die jeweils mit den Fähigkeiten, Integrationen und dem Unternehmenskontext für ihren Job kommen. Das Helpdesk-Teammitglied steigt in deine bestehende Warteschlange ein und entwirft oder löst Tickets; der Blog-Autor recherchiert und schreibt Langtexte so, wie dieser Beitrag entstanden ist. Derselbe Wandel „du steuerst, der Agent arbeitet“, den Cursor verkauft, nur gerichtet auf Kundenservice-Automatisierung und SEO-Content-Teams statt auf Pull Requests.
Und weil es in diesem Beitrag im Kern um agentische, terminalgesteuerte Workflows geht, lohnt sich die CLI-Parallele. Mit Cursor steuerst du Cloud-Subagenten aus dem Editor mit Befehlen wie /in-cloud und /autopilot. eesel bietet für seine Teammitglieder dieselbe Art programmierbarer Oberfläche: Die eesel CLI (@eesel/cli) ist ein echtes npm-Binary, dessen Doku wörtlich sagt: „everything on this site can be done from the terminal.“ Du kannst mit eesel integrations connect verbinden, mit eesel instructions die festen Regeln des Agenten bearbeiten, mit eesel approvals riskante Aktionen absichern und mit eesel activity jeden Lauf, neueste zuerst, verfolgen. Jeder Befehl gibt JSON aus und unterstützt --dry-run, passt also direkt in CI, und jeder Workspace ist außerdem ein MCP-Server, eingebunden wie jede andere MCP-Integration. Das heißt, ein Coding-Agent wie Cursor, Claude Code oder Codex kann dein Support- oder Content-Teammitglied direkt bedienen. Diese Beobachtbarkeitsansicht eesel activity entspricht fast eins zu eins Cursors „bring the finished work back to you to check“.
Eine Stelle, an der ein Support- oder Content-Teammitglied weiter gehen muss als ein Coding-Coordinator: Du kannst nicht „jeden PR prüfen“, wenn der Agent mit einem echten Kunden spricht. Deshalb lässt eesel dich ein Teammitglied gegen deine echten historischen Tickets simulieren, bevor es jemals antwortet, und Aktionen hinter Freigaben halten, bis du ihm vertraust. Es ist dieselbe Lehre, auf die die Cursor-Skeptiker hinweisen, angewandt auf Arbeit, die direkt zu einem Menschen geht.
eesel ausprobieren
Wenn Cursor Projects dich vom Modell „eine Flotte von Agenten steuern, nicht beaufsichtigen“ überzeugt hat und du ein Support- oder Content-Team leitest, ist genau das, was eesel für diese Jobs tut. Du integrierst ein KI-Helpdesk-Teammitglied in Zendesk, Freshdesk, Gorgias oder Slack, es lernt deinen Verlauf und dein Help Center und beginnt, Tickets zu entwerfen und zu lösen. Oder du richtest den KI-Blog-Autor auf deine Content-Pipeline, statt getrennte KI-Schreibtools zusammenzustückeln. Es lässt sich über das Dashboard oder komplett über das Terminal mit der eesel CLI und dem MCP-Server steuern, und du kannst es mit echten Daten simulieren, bevor es live geht. Du kannst es kostenlos ausprobieren.
Häufig gestellte Fragen
Was sind Cursor Projects?
Cursor Projects, gestartet am 10. September 2026, ist eine Möglichkeit, ein großes Arbeitspaket (ein Feature, eine Migration, laufende Wartung) über einen einzigen Cursor-Thread abzuwickeln. Statt für jede Aufgabe einen neuen Chat zu öffnen, sprichst du mit einem Coordinator-Agenten, der die Arbeit plant und an mehrere Agenten delegiert, die parallel laufen.
Was kosten Cursor Projects?
Für Projects gibt es keinen separaten Preis. Sie laufen auf Cursors Cloud Agents, die zum API-Preis des gewählten Modells abgerechnet werden, und du brauchst einen kostenpflichtigen Tarif, um überhaupt Cloud Agents auszuführen. Da ein Coordinator viele Subagenten gleichzeitig starten kann, richten sich die Kosten nach der Nutzung und nicht nach einer Pauschale. Alle Tarifdetails findest du in unserer ausführlichen Übersicht zu den Cursor-Preisen.
Wie unterscheidet sich der Coordinator-Agent von einem normalen Cursor-Chat?
Ein normaler Chat erledigt die Arbeit direkt vor deinen Augen. Der Coordinator schreibt selbst keinen Code; er plant, delegiert an Subagenten und bringt fertige Arbeit zur Prüfung zurück zu dir. Das ist dieselbe Verschiebung hin zu agentischem Coding, die du auch bei Tools wie OpenAI Codex und GitHub Copilot siehst.
Können Cursor Projects laufen, ohne dass ich zuschaue?
Ja. Projects nutzen „Subscriptions“, damit der Coordinator ohne Prompt einen Slack-Kanal beobachten, nach Zeitplan laufen oder deinen PRs folgen und CI reparieren kann. Es ist dieselbe Idee wie bei automatisierten Agenten-Workflows anderswo. Im Support laufen die KI-Kundenservice-Workflows von eesel nach demselben, auslösergesteuerten Modell.
Sind Cursor Projects für eine Produktiv-Codebasis sicher?
Das können sie sein, wenn du einen Menschen im Prozess behältst. Subagenten können auf isolierten Branches oder in eigenen Cloud-VMs arbeiten, und der Coordinator übergibt fertige Arbeit vor dem Merge zur Prüfung. Das eigentliche Risiko ist, dass du weniger prüfst, je mehr du ihm vertraust. Wenn du Agenten für kundennahe Aufgaben einsetzt, kannst du mit einem Tool wie eesel zuerst gegen echte Verlaufsdaten simulieren und Aktionen hinter Freigaben stellen.