Cursor 3: Eine neue Ära des KI-Codings mit parallelen Agents

Was ist neu in Cursor 3?

Das 3.0-Release setzt stärker auf Infrastruktur als auf UI-Polish. Das hat sich tatsächlich geändert.

Vereinheitlichter Agent-Workspace

Alle Agent-Aktivitäten leben jetzt in einer Oberfläche. Die Sidebar zeigt jeden Agent, der auf deiner Maschine oder in der Cloud läuft – auch solche, die du aus Slack, GitHub, Linear, mobil oder dem Web gestartet hast. Ein Blick, alles drin.

Der Workspace ist von Haus aus multi-repo. Ein Agent kann Frontend-Komponenten aktualisieren, während ein anderer eine Backend-Bibliothek patched. Vor Cursor 3 brauchte das getrennte IDE-Fenster und ständigen Kontextwechsel.

Zwei nennenswerte Ergänzungen: Agent-Tabs lassen dich mehrere Agent-Chats nebeneinander oder im Grid anzeigen. Agent-Chats sind außerdem normale Editor-Tabs, sodass Split-View und Tastenkürzel wie gewohnt funktionieren. Kein Umlernen. Der Design Mode hat weiter unten einen eigenen Abschnitt.

Mehrere Agents parallel ausführen

Der Befehl /best-of-n läuft im Agent-Chat innerhalb der IDE, nicht im Agents Window. So nutzt du ihn: Öffne ein Git-Repository, öffne Agent Chat im klassischen Editor-Layout und führe /best-of-n aus, gefolgt von einer kommagetrennten Liste von Modellen und deiner Aufgabe. Zum Beispiel: /best-of-n sonnet, gpt, composer fix the flaky logout test.

Cursor erstellt für jedes Modell eine eigene Git-Worktree, sodass sich die Runs nicht gegenseitig stören. Nach Abschluss prüfst du die Outputs, commitest und pushst aus der ausgewählten Worktree oder führst /apply-worktree aus, um die Änderungen in deine Hauptarbeitskopie zurückzubringen. Du kannst die Worktree-Einrichtung pro Projekt über .cursor/worktrees.json anpassen.

Cursor leitet mehrmodellige Parallel-Runs jetzt über /best-of-n im IDE-Agent-Chat, während der ältere Auswahl-Flow nicht mehr empfohlen ist.

Der Befehl /worktree folgt demselben Weg: IDE-Agent-Chat, Git-Repo erforderlich, isolierte Worktree pro Agent.

Die "beste" Auswahl spiegelt Cursors Bewertungsheuristiken wider, nicht zwingend deine. Lies die Outputs selbst.

Ein praktischer Hinweis: Jeder Modell-Run wird separat zu seinem normalen Tokenpreis abgerechnet – ohne Bündelrabatt. Drei Modelle bedeuten drei getrennte Gebühren. Mehr dazu später im Abschnitt zu Credits.

Handoff zwischen lokalen und Cloud-Agents

Cloud-Agents laufen auf isolierten Ubuntu-VMs. Der Handoff funktioniert in beide Richtungen.

Vom Cloud- in den lokalen Modus zu wechseln, verschafft dir Zugriff auf dein Dateisystem, den lokalen Dev-Server und Desktop-Testing-Tools. Eine Session in die Cloud zu pushen erlaubt lang laufenden Tasks, weiterzulaufen, nachdem du den Laptop geschlossen hast. Ist der Agent fertig, warten die Ergebnisse im Agents Window. Cloud-Agents erzeugen außerdem Demos und Screenshots ihrer Arbeit, die du prüfen kannst, bevor du etwas lokal zurückholst.

Agent-Sessions wandern bidirektional zwischen lokal und Cloud. Bild: Autor.

Für Enterprise-Teams sind selbstgehostete Cloud-Agents seit dem 25. März 2026 verfügbar. Code, Tool-Ausführung und Build-Artefakte bleiben in deiner eigenen Infrastruktur. Ein Worker-Prozess verbindet sich ausgehend über HTTPS mit Cursors Cloud – ohne eingehende Ports oder VPN. Selbstgehostete Agents gibt es im Enterprise-Plan; Standard-Cloud-Agents sind in Pro und höher enthalten.

Du definierst die Cloud-Umgebung mit einer .cursor/environment.json am Repo-Root. Secrets speicherst du in den Cursor Settings unter Secrets statt in dieser Datei.

Vom Commit zur Pull-Request in einem Flow

Die neue Diff-Oberfläche zeigt Wort-Änderungen, lässt dich Commits stagen und eine Pull-Request öffnen – ohne das Agents Window zu verlassen. Rendering großer Diffs ist in 3.0 schneller und speicherschonender.

Wenn du /worktree im klassischen Editor benutzt, arbeitet jeder Agent in einer eigenen isolierten Worktree, sodass Diffs bei der Review bereits sauber sind. Kein Entwirren überlappender Änderungen.

Cursor hat zudem am 18. Dezember 2025 eine endgültige Vereinbarung zur Übernahme von Graphite, einem Tool für Pull-Request-Management, bekanntgegeben. Ich hätte es fast weggelassen, da die Integration offen ist, aber diese Übernahme könnte den Workflow nach Closing spürbar verändern.

Design Mode und integrierter Browser

Eine UI-Änderung in Text zu beschreiben ist langsamer, als sie zu zeigen. Der Design Mode behebt das.

Drücke Cmd+Shift+D, um ein Auswahlwerkzeug über dem integrierten Browser zu aktivieren. Nutze Shift+drag, um einen Bereich zu markieren, Cmd+L, um ein gewähltes Element in den Agent-Chat zu injizieren, oder Option+click, um es zum Eingabefeld hinzuzufügen. Der Agent erhält HTML, angewandtes CSS und die Bounding Box. Statt einen Absatz zum Layoutproblem zu schreiben, wählst du das Element und sagst: "Mach das enger."

Der Browser enthält außerdem die Chrome DevTools. Agents können einen lokalen Dev-Server starten, Buttons klicken, Konsolen-Logs lesen und prüfen, ob ihre Änderungen wirklich wirken.

Composer 2: Cursors eigenes Coding-Modell

Composer 2 startete am 19. März 2026, zwei Wochen vor Cursor 3. Es ist das Modell, das die Agents im neuen Workspace antreibt.

Es basiert auf Kimi K2.5 von Moonshot AI, mit weiterem Pretraining und einem RL-Run im 4x-Maßstab obendrauf. Cursor nannte das Basismodell beim Launch nicht. Ein Nutzer fand es tags darauf in API-Headern. Co-Founder Aman Sanger räumte das Versäumnis ein: "Es war ein Fehler, die Kimi-Basis im Blog nicht von Anfang an zu erwähnen. Das korrigieren wir beim nächsten Modell."

Wenn Benchmarks nicht dein Ding sind, die Kurzfassung: Composer 2 ist schneller und günstiger als viele Drittmodelle. Spring zur Preistabelle unten.

Auf Cursors eigenem CursorBench erzielt Composer 2 61,3 gegenüber 44,2 für Composer 1.5 – rund 39% Plus. Es läuft mit über 200 Tokens pro Sekunde, teils dank eigener GPU-Kernel statt ausschließlich Drittanbieter-Inferenz-Stacks. CursorBench ist nicht unabhängig auditiert, das im Hinterkopf behalten. GPT-5.4 schlägt es bei härteren Aufgaben, aber auf CursorBench-Work (im Schnitt 352 Zeilen über acht Dateien) übertrifft Composer 2 Claude Opus 4.6 bei rund 90% niedrigeren Kosten pro Token. Diese Kostendifferenz ist der spannendere Wert.

Hier die Preisaufschlüsselung:

In individuellen bezahlten Plänen hat Composer 2 einen eigenen Nutzungspool, getrennt von Credits für manuell gewählte Frontier-Modelle. Abgerechnet wird nutzungsbasiert, nicht pro Request. Die vollständige Credit-Aufschlüsselung steht im Preisabschnitt unten. Das Modell hat ein Kontextfenster mit 200.000 Tokens und Self-Summarization: Wenn der Kontext voll ist, komprimiert es auf etwa 1.000 Tokens und macht weiter.

Composer 2 ist speziell für agentisches Coding gebaut. Für anderes ist es nicht gedacht.

Cursor 3 als Agent-First-Entwicklungsumgebung

Cursor-CEO Michael Truell beschreibt drei Epochen der KI-Softwareentwicklung. Zuerst Tab-Autocomplete, das repetitive Codezeilen ergänzt. Dann synchrone Agents, die das Modell Schritt für Schritt steuern. Jetzt laufen Cloud-Agents autonom über längere Zeiträume, und Entwickler agieren mehr als Regisseure denn als Autoren.

Die Nutzungsdaten spiegeln diesen Wandel. Wie oben erwähnt, kippte das Verhältnis Agent zu Tab zwischen Anfang 2025 und Anfang 2026.

Truells Einordnung: "Bei Cursor geht es nicht mehr primär ums Code-Schreiben. Es geht darum, Entwickler dabei zu unterstützen, die Fabrik zu bauen, die ihre Software erzeugt." Das ist ein Zielbild, keine Produktbeschreibung. Die meisten Entwickler, die Cursor 3 heute nutzen, prüfen und korrigieren Agent-Output weiterhin laufend. Ich habe noch keinen Codebestand gesehen, in dem die Fabrik von allein läuft. Aber die Oberfläche ist darauf ausgelegt, dass dieses Szenario näher ist, als es klingt.

Zentrale Funktionen, die bleiben – und besser werden

Die Kernfunktionen früherer Versionen sind weiterhin da und größtenteils unverändert.

Dateien und Code-Verständnis

Vollständiger Language Server Protocol (LSP)-Support bleibt erhalten. Go-to-Definition, Symbolsuche, Hover-Dokumentation und Dateinavigation funktionieren wie in VS Code. Kontext-Referenzen wie @Files, @Folders und @Docs werden unterstützt. Das Agents Window entfernt keinen Dateizugriff; es legt eine Ebene darüber.

Cursor Marketplace und Plugins

Der Cursor Marketplace erweitert Agent-Fähigkeiten per One-Click-Plugin-Installation. Ein Plugin bündelt eine Kombination aus Skills (Prompts, die Agents bei Bedarf aufrufen), Subagents, MCP-Servern, Hooks und Rules. Die vollständige Aufschlüsselung in den Cursor-Dokumenten.

Verfügbare Plugins decken viel ab: AWS, Figma, Linear, Stripe, Vercel, Datadog, Snowflake und mehr. Teams- und Enterprise-Pläne können private Team-Marketplaces einrichten. Bei Enterprise sind Drittanbieter-Plugin-Imports standardmäßig aus, bis ein Admin sie aktiviert.

Eine Lücke, die es nicht geben sollte: Es gibt keine integrierte UI, um Umgebungsvariablen für Marketplace-Plugin-MCP-Server zu setzen. Der Workaround ist, den Server manuell zu ~/.cursor/mcp.json mit einem env-Feld hinzuzufügen und den doppelten Eintrag in den Cursor Settings zu deaktivieren. Das funktioniert, ist aber in einem bezahlten Produkt eigentlich nicht akzeptabel.

Automations

Automations, veröffentlicht am 5. März 2026, sind Always-on-Agents, die durch externe Events ausgelöst werden: Zeitpläne, Slack-Nachrichten, Linear-Issues, GitHub-Events und PagerDuty-Incidents. Der Agent startet eine Cloud-Sandbox und befolgt Anweisungen mit konfigurierten MCPs und Modellen. Wenn Memory aktiviert ist, erhält der Agent ein persistentes Notizbuch (kleine Textdateien wie MEMORIES.md, die zwischen Runs erhalten bleiben). Der Agent entscheidet, was er notiert: Fortschritt, erkannte Muster, Kontext aus früheren Runs. Der nächste Run liest diese Notizen und macht dort weiter. Du kannst diese Dateien im Automations-Bereich des Dashboards ansehen und bearbeiten.

Cursor-3-Preise und Planvoraussetzungen

Nicht alle Funktionen gibt es in jedem Plan. Hier ist die aktuelle Aufschlüsselung:

Cloud-Agents und Composer 2 erfordern Pro oder höher. Team Marketplaces benötigen Teams oder Enterprise, selbstgehostete Cloud-Agents sind ausschließlich Enterprise.

Cursor führt in individuellen Bezahlplänen zwei getrennte Credit-Pools: einen für Auto-Mode und Composer-Nutzung, von Cursor als "großzügig" beschrieben ohne veröffentlichte Obergrenze, und einen für manuell gewählte Frontier-Modelle wie Claude oder GPT. Wenn du ein Modell manuell auswählst, belastet das den Credit-Pool. Auto-Mode nicht.

Hinweis für Heavy User: Entwickler im Pro-Plan, die häufig Agent-Sessions laufen lassen, berichten von tatsächlichen Kosten eher bei $40 bis $50 pro Monat, sobald Overages greifen. Die $20 sind die Untergrenze.

Wie Cursor 3 Developer-Workflows verändert

Hier ein konkreter Vergleich für eine typische Backend-API-Aufgabe:

Die Veränderung ist nicht von schwer zu leicht. Sie geht von Schreiben zu Steuern. Du verbringst weniger Zeit mit Implementierung und mehr mit Anforderungen präzisieren und Output prüfen. Ob sich das lohnt, hängt von der Aufgabe ab – und ehrlich gesagt davon, wie sehr du dem Agent an einem bestimmten Tag vertraust.

Lang laufende Aufgaben profitieren am meisten. Eine Refactor, die im Terminal Stunden dauern würde, geht an einen Cloud-Agent; du klappst den Laptop zu, der Agent macht weiter, und die Diffs warten später auf dich.

Cursor 3 vs. frühere Versionen von Cursor

Frühes Cursor (2022 bis 2024) war ein IDE-First-Tool. KI-gestütztes Dateiediting in einer VS-Code-Umgebung.

Cursor 1.0 (Juni 2025) war der erste stabile Release. Cursor 2.0 (Oktober 2025) brachte das erste Composer-Modell und den In-App-Browser. Cursor 2.5 (Februar 2026) ergänzte asynchrone Subagents und den Plugin-Marketplace. Cursor 2.6 (März 2026) fügte Team-Marketplaces hinzu.

Cursor 3.0 macht den Wechsel offiziell. Cloud-Agents sind komplett aus dem Editor herausgezogen und leben nun ausschließlich im Agents Window. Die Worktree-Unterstützung hat sich ebenfalls geändert: Das alte Dropdown-UI wurde deprecatet und durch die Befehle /worktree und /best-of-n ersetzt, die im klassischen Editor-Chat laufen. Falls du interne Dokus zur Nutzung des Worktree-Dropdowns oder zum Starten von Cloud-Agents im Editor hast, sind sie veraltet.

Cursor hat den 3.0-Neuaufbau genutzt, um Performance-Schulden aus 2.x zu tilgen: Fixes für Memory- und CPU-Leaks, den React Compiler. Robinson beschreibt das Ergebnis als schneller und weniger anfällig für UI-Ruckler. Windows wird voll unterstützt und die Oberfläche handhabt mehrere Workspaces in einem Fenster.

Der Sprung von 2.x auf 3.0 ist struktureller, als er aussieht. Frühere Versionen haben Agent-Features an eine IDE angedockt. Cursor 3 dockt eine IDE an eine Agent-Plattform an. Diese Reihenfolge zählt.

Cursor 3 vs. traditionelle IDEs

Traditionelle IDEs sind dateizentriert. Du öffnest eine Datei, bearbeitest Text, und die IDE hilft dir, schneller zu tippen. Selbst mit GitHub Copilot bleibt das Dokument die Abstraktion.

Cursor 3 macht die Datei zweitrangig. Die primäre Oberfläche ist die Aufgabenliste. Die IDE wird zum Fallback für Edits, die zu spezifisch sind, um sie zu prompten.

Der Vergleich wird jedoch unschärfer. GitHub Copilot bietet inzwischen Cloud-Agents und Code-Review über individuelle Planstufen hinweg. JetBrains bündelt Junie, seinen autonomen Coding-Agent, mit AI-Abos. Und wie erwähnt läuft Cursor jetzt via ACP auch in JetBrains-IDEs. Alle haben Agents. Der eigentliche Unterschied bei Cursor 3 ist, dass der Workspace um sie herum gebaut wurde – nicht als Add-on zu einem bestehenden Editor.

Einschränkungen und offene Fragen

Der Alltag hat mehr Reibung, als die Launch-Materialien vermuten lassen.

Entwickleraufsicht

Agents machen Fehler. Bei komplexen Multi-File-Aufgaben viele. Die Prüfung von Agent-Outputs erfordert genug Vertrautheit mit dem Codebestand, um falsche Annahmen, halluzinierte Funktionen und Logik zu erkennen, die fast funktioniert. Die Zeitersparnis beim Schreiben wandert zu Lesen und Validieren. Entwickler, die den generierten Code nicht kritisch lesen können, werden den Codebestand nicht stabil halten. Das ist kein spezieller Vorwurf an Cursor; das gilt für jedes agentische Coding-Tool.

Zuverlässigkeit von Cloud-Agents

Fehlschläge beim Einrichten der Umgebung sind dokumentiert und andauernd. Secrets können während des Initial-Setup-Skripts nicht injiziert werden, nur danach. Ausgedehnte parallele Sessions ziehen viele Ressourcen; Nutzende berichten von hoher RAM-Auslastung auf eigentlich ausreichender Hardware. Halte Sessions möglichst unter zwei Stunden und setze für längere Läufe Reindexing-Checkpoints.

Ein weiteres konkretes Loch: Plan Mode ist in der Cursor-Weboberfläche noch nicht verfügbar. Du kannst Cloud-Agents inklusive Planung aus der Cursor-3-Desktop-App starten und steuern, aber nicht direkt von cursor.com/agents aus.

Es gibt außerdem einen bekannten Bug, bei dem Agents hängen bleiben, wenn das Agents Window nicht im Fokus ist. Gemeldet kurz nach dem Launch und bis Anfang April 2026 ungelöst. Für ein Tool, das auf lang laufende Sessions baut, ist das problematisch.

Zu parallelen Agents allgemein: Google DeepMind fand in Multi-Agent-Systemen eine Fehlerverstärkung um bis zu das 17,2-Fache in unstrukturierten Netzwerken. Selbst bei 99% Zuverlässigkeit pro Agent sinkt eine Kette von zehn Agents auf etwa 90% Gesamtzuverlässigkeit. Der Befehl /best-of-n nutzt isolierte Worktrees, was manches begrenzt – nicht alles.

Sicherheitsaspekte

Zwei CVEs wurden 2025 gefunden und gepatcht. CVE-2025-54136 (MCPoison) erlaubte es, genehmigte MCP-Tools still zu modifizieren; gepatcht in Version 1.3. CVE-2025-64106 war eine Deep-Link-Remote-Code-Execution mit einer Schwere von 8,8, innerhalb von zwei Tagen gepatcht. Workspace Trust ist zudem standardmäßig deaktiviert. Wenn du MCP-Tools in sensiblen Umgebungen verbindest, ist das relevant.

Selbstgehostete Cloud-Agents halten – wie oben beschrieben – die Arbeit des Agents in deinem Netzwerk, aber die Cursor-Plattform selbst ist nicht als vollständige On-Premises-Installation verfügbar. Cursor besitzt keine FedRAMP- oder HIPAA-Zertifizierung. Die Verfügbarkeit eines BAA ist nicht öffentlich dokumentiert, also kläre das direkt mit Cursor, bevor du dich für Compliance darauf stützt. Wenn deine Umgebung FedRAMP oder vollständiges On-Prem erfordert, passt Cursor 3 nicht.

Zwei weitere praktische Limits: Der Design Mode funktioniert derzeit nur in Chrome; Firefox und Safari werden nicht unterstützt. Und in den Tagen nach dem Cursor-3-Launch meldete die Community bei einigen Nutzenden eine rund zehnfach höhere Token-Nutzung von Composer 2, verknüpft mit Cache-Read-Issues.

Das Credit-Modell

Wie im Abschnitt zu parallelen Agents beschrieben, wird jedes /best-of-n-Modell separat berechnet. Ein Drei-Modell-Vergleich bei einer komplexen Aufgabe kann einen großen Teil deines monatlichen Pools in einer einzigen Session verbrauchen.

Für wen ist Cursor 3 geeignet?

Wenn du bereits agent-gestützte Workflows fährst und alles an einem Ort haben willst, ist das für dich gebaut. Es ergibt am meisten Sinn für Teams über mehrere Repos, für längere Aufgaben, die du in die Cloud gibst, und für Enterprise-Teams, die Code in ihrer eigenen Infrastruktur halten müssen.

Für Einsteiger würde ich es nicht empfehlen. Nicht, weil es schwer zu bedienen ist, sondern weil Agents Code erzeugen, den du kritisch lesen musst. Wenn du nicht erkennst, wann der Output falsch ist, kannst du ihn nicht reparieren – und nach sechs Monaten sieht man das im Code. Für einfache Skripte oder One-Offs lohnt sich der Setup-Overhead ebenfalls nicht. Und wenn deine Umgebung HIPAA-reguliert oder air-gapped ist, lies vorher den Sicherheitsabschnitt.

Große, alte Monorepos bleiben ein echtes Problem. Kontextfenster brechen dort weiterhin.

Die Zukunft des KI-Codings mit Cursor

Im Februar 2026 veröffentlichte Cursor "Towards Self-Driving Codebases" und beschrieb Experimente mit Tausenden orchestrierter Agents über große Codebasen. Das formulierte Ziel: "bis Codebasen selbstfahrend sind."

Kontextfenster brechen weiterhin bei großen Monorepos. Agents halluzinieren regelmäßig. Die Vision ist weit genug entfernt, dass ich nicht darauf planen würde.

Was Cursor 3 tut: die Hauptbausteine an Ort und Stelle bringen – das Modell in Composer 2, die Oberfläche im Agents Window, Cloud-VMs als Runtime und Self-Hosted-Optionen für Enterprise. Die selbstfahrende Codebasis hängt von Modellfortschritten ab, die Cursor nicht vollständig kontrolliert.

Truells "Fabrik"-Bild ist noch weit von der Realität entfernt. Vorerst bist du es, der die Fabrikhalle überprüft.

Fazit

Die wichtigste Änderung in Cursor 3 ist kein Feature. Es ist die Annahme hinter der Oberfläche: Der Agent, nicht die Datei, ist die Arbeitseinheit. Vor zwei Jahren war das eine Wette. Die Nutzungsdaten deuten darauf hin, dass sie aufgeht.

Ob es zu deinem Workflow passt, hängt von Dingen ab, die ich hier nicht beurteilen kann: Größe des Codebestands, Sicherheitsanforderungen und ob du mit einem Produkt leben kannst, das erst vor wenigen Wochen gelauncht wurde und noch Ecken und Kanten hat. Wenn du unschlüssig bist, lies den Abschnitt zu den Einschränkungen nochmal.

Wenn du Cursor praktisch weiter vertiefen willst, unser Software Development with Cursor-Kurs deckt Prompting, Refactoring, Testing und Agent-Workflows ab.