Anthropic
April 7, 2026
Felix Braun
Cursor Composer 2 ist seit dem 19. März 2026 verfügbar — als nativer Coding-Agent direkt in der Cursor IDE. Die zweite Generation basiert auf Moonshot AIs Kimi K2.5 und übertrifft den Vorgänger in allen relevanten Benchmarks. Was das Modell kann, was es kostet und für wen es sich lohnt.
Cursor hat mit Composer 2 nicht nur ein Update veröffentlicht. Es ist ein komplett neu trainiertes Modell. Basis ist Kimi K2.5 von Moonshot AI — ein chinesisches Sprachmodell, das Cursor mit eigenem Continued Pretraining und Reinforcement Learning für Coding-Aufgaben weiterentwickelt hat. Das Ergebnis ist ein Agent, der deutlich eigenständiger arbeitet als sein Vorgänger.
Composer 1.5 war bereits nützlich für einfache Datei-Edits und Code-Completion. Composer 2 geht weiter: Der Agent liest mehrere Dateien gleichzeitig, versteht Projektstrukturen und Dependencies, editiert Code an mehreren Stellen, führt Terminal-Commands aus — und iteriert anschließend auf Basis des Outputs. Das ist kein linearer Prozess. Wenn ein Test fehlschlägt, analysiert Composer 2 den Fehler und korrigiert seinen eigenen Code.
Cursor hat das Modell vollständig in die IDE integriert. Es gibt keine externe Oberfläche, keine API-Schlüssel für Drittdienste. Wer Cursor nutzt, hat Composer 2 direkt verfügbar.
Im Vergleich zum Cursor Composer 1.5 fällt vor allem auf: Die Kontexttiefe ist größer. Das Modell verliert weniger den Überblick, wenn ein Projekt mehrere hundert Dateien hat. Entwickler berichten, dass Composer 2 deutlich seltener auf Halbwissen zurückgreift oder Datei-Pfade verwechselt. Das war bei 1.5 noch ein häufiges Problem.
Der Begriff „Coding-Agent“ wird oft inflationär verwendet. Bei Cursor Composer 2 lässt sich genau beschreiben, was damit gemeint ist — und was nicht.
Viele Tools bezeichnen sich als „agentic“, weil sie mehrere Tokens nacheinander generieren. Cursor Composer 2 meint etwas anderes: ein Modell, das eigenständig Entscheidungen über den nächsten Schritt trifft, diesen ausführt und dann auf Basis des Ergebnisses entscheidet, was als nächstes passiert. Das ist ein fundamentaler Unterschied zu einem einfachen Code-Completion-Tool.
Ein typischer Workflow sieht so aus: Sie beschreiben in natürlicher Sprache, was gebaut werden soll. Composer 2 liest zunächst alle relevanten Dateien — nicht nur die aktuell geöffnete. Das Modell analysiert Imports, Funktionsdefinitionen und bestehende Tests. Dann beginnt es mit dem Schreiben: Dateien werden editiert, neue Dateien angelegt, bestehende Strukturen angepasst.
Sobald Code-Änderungen vorliegen, führt Composer 2 automatisch die zugehörigen Tests aus. Bei einem Fehler stoppt der Agent nicht. Er liest den Stack Trace, identifiziert die Ursache und korrigiert den Code. Dieser Zyklus kann mehrere Runden dauern — und läuft ohne manuelle Eingriffe.
Das klingt nach Science-Fiction, ist aber in der Praxis gut beobachtbar. Cursor zeigt jeden Schritt transparent an: welche Dateien gelesen wurden, welche Edits vorgenommen wurden, welche Commands ausgeführt wurden. Sie behalten die Kontrolle und können jederzeit eingreifen oder Änderungen ablehnen.
Besonders hilfreich ist das Protokoll-Feature: Composer 2 zeigt nach jeder Aktion eine kurze Begründung an. Warum wurde Datei X gelesen? Warum wurde Command Y ausgeführt? Diese Transparenz ist kein Luxus — sie ist notwendig, damit Entwickler verstehen, was der Agent tut, und bei Bedarf korrigieren können. Blinde Ausführung wäre kontraproduktiv.
In der Praxis empfiehlt Cursor, Aufgaben in überschaubare Einheiten zu zerlegen. Statt „baue das gesamte Authentifizierungssystem“ besser: „implementiere den Login-Endpoint mit JWT-Token-Generierung“. Je präziser die Aufgabe, desto zuverlässiger der Output. Das ist kein Fehler des Modells — es ist die richtige Arbeitsweise mit einem Agenten dieser Art.
Besonders stark ist Composer 2 bei Refactoring-Aufgaben. Wenn Sie eine Funktion umbenennen, die an zwanzig Stellen verwendet wird, findet das Modell alle Verwendungen — auch in Konfigurationsdateien oder Dokumentation. Composer 1.5 hat dabei regelmäßig Stellen übersehen.
Auch bei komplexen Migrations-Aufgaben — etwa einem Framework-Upgrade — zeigt sich die Stärke: Composer 2 versteht den Unterschied zwischen alter und neuer API-Syntax und schreibt den nötigen Migrations-Code ohne manuellen Eingriff.
Ein weiterer Bereich: Testgenerierung. Composer 2 analysiert vorhandenen Code und schreibt Unit-Tests mit korrekten Assertions — ohne dass Sie die Teststruktur vorgeben müssen. Es liest die Funktion, leitet mögliche Fehlerfälle ab und generiert Edge-Case-Tests, die Sie vielleicht selbst nicht sofort im Kopf gehabt hätten. Das ist einer der nützlichsten Anwendungsfälle im Alltag.
Vibe Coding hat durch solche Agenten eine neue Dimension bekommen. Wer noch nicht damit gearbeitet hat, findet einen guten Einstieg in unserem Artikel über Vibe Coding — einer Arbeitsweise, die stark auf KI-Coding-Tools wie Cursor setzt.
Wichtig für die tägliche Nutzung: Cursor Composer 2 arbeitet am besten, wenn das Projekt eine klare Verzeichnisstruktur hat und bestehende Tests vorhanden sind. Projekte ohne Tests sind für den Agenten schwieriger — er kann Änderungen nicht verifizieren und muss nach jeder Aktion auf manuelles Feedback warten. Wer also Composer 2 ernsthaft nutzen will, sollte zuerst eine grundlegende Test-Coverage aufbauen.
Cursor hat für Composer 2 nicht auf GPT-4o oder Claude gebaut — sondern auf Kimi K2.5 von Moonshot AI. Das ist bemerkenswert. Die meisten westlichen Coding-Tools setzen auf OpenAI oder Anthropic. Cursor geht einen eigenen Weg.
Kimi K2.5 ist ein chinesisches Großsprachmodell, das Moonshot AI speziell für Code-intensive Aufgaben entwickelt hat. Cursor hat es mit eigenem Continued Pretraining weiterentwickelt — also mit zusätzlichen Trainingsdaten aus echten Coding-Workflows. Dazu kommt Reinforcement Learning, das das Modell auf Coding-Aufgaben weiter spezialisiert.
Das Ergebnis ist ein Modell, das nicht allgemein gut im Schreiben von Text ist, sondern gezielt für das gemacht wurde, was Entwickler täglich tun: Bugs fixen, Tests schreiben, Code strukturieren, Dependencies verwalten.
Informationen zur Modell-Entwicklung und zum vollständigen Changelog finden Sie direkt bei Cursor: cursor.com/de/changelog.
Cursor hat Composer 2 auf drei Benchmarks gemessen — und die Zahlen sind eindeutig.
Auf dem hauseigenen CursorBench erreicht Composer 2 einen Score von 61,3. Composer 1.5 kam auf 44,2. Das ist ein Unterschied von fast 40 Prozent.
Beim Terminal-Bench 2.0, der speziell die Qualität von Terminal-Commands und Agentic Loops misst, liegt Composer 2 bei 61,7. Composer 1.5 erzielte 47,9.
Am stärksten ist der Unterschied beim SWE-bench Multilingual — einem Standard-Benchmark, der misst, wie gut ein Modell echte GitHub-Issues lösen kann. Composer 2 erreicht 73,7. Der Vorgänger lag bei 65,9. Dieser Benchmark ist besonders relevant, weil er auf realen Code-Repositories basiert, nicht auf synthetischen Aufgaben.
Was bedeuten diese Zahlen in der Praxis? Ein höherer SWE-bench-Score bedeutet, dass das Modell häufiger echte Bugs korrekt löst — ohne dass Sie den Fix im Anschluss manuell korrigieren müssen. Das spart Zeit. Bei 65,9 Punkten (Composer 1.5) musste man bei etwa einem Drittel der Aufgaben nacharbeiten. Bei 73,7 ist der Anteil deutlich kleiner.
Der SWE-bench Multilingual-Test ist dabei besonders aufschlussreich, weil er mehrsprachige Codebases einbezieht — also nicht nur Python oder JavaScript, sondern auch TypeScript, Java, Go und andere Sprachen. Das ist für Teams relevant, die in gemischten Tech-Stacks arbeiten. Dass Composer 2 hier 73,7 erreicht, zeigt, dass das Modell auch jenseits von reinen Python-Projekten zuverlässig funktioniert.
CursorBench und Terminal-Bench sind intern entwickelte Benchmarks von Cursor. Sie messen spezifisch, wie gut der Agent in der IDE-Umgebung agiert — also wie zuverlässig er Dateien liest, Commands ausführt und auf Fehler reagiert. Diese Zahlen sind für den Alltag in der Cursor IDE relevanter als allgemeine Coding-Benchmarks.
Terminal-Bench 2.0 ist dabei ein aktualisierter Standard, der stärker auf mehrstufige Terminal-Interaktionen setzt: Szenarien, in denen der Agent mehrere Commands hintereinander ausführen, deren Output interpretieren und darauf reagieren muss. Mit 61,7 Punkten liegt Composer 2 hier deutlich über dem Vorgänger — was sich direkt in der Zuverlässigkeit von Agentic Loops widerspiegelt.
Einen ausführlichen Überblick über aktuelle KI-Coding-Tools — inklusive Vergleich mit anderen Produkten — bietet unser Artikel ChatGPT Canvas vs. Cursor.
Für eine unabhängige Einschätzung der Modell-Performance lohnt sich ein Blick auf externe Benchmark-Seiten. SWE-bench Multilingual wird von Princeton University gepflegt und gilt als einer der seriösesten Coding-Benchmarks im Bereich autonomer Software-Entwicklung.
Cursor Composer 2 ist über zwei Preisebenen verfügbar, die unterschiedliche Antwortgeschwindigkeiten bieten.
Die Standard-Variante kostet $0,50 pro Million Input-Tokens und $2,50 pro Million Output-Tokens. Sie ist die günstigere Option — mit etwas längeren Antwortzeiten.
Die Faster-Variante ist der Standard in Cursor. Sie kostet $1,50 pro Million Input-Tokens und $7,50 pro Million Output-Tokens — also dreimal so viel. Dafür ist die Latenz deutlich geringer. In Agentic Workflows, wo Composer mehrere Schritte nacheinander ausführt, summiert sich das: Faster ist für produktive Nutzung die sinnvollere Wahl.
Zum Vergleich: Claude 3.7 Sonnet liegt bei $3,00 / $15,00, GPT-4o bei $5,00 / $15,00 (Stand Anfang 2026). Composer 2 ist damit im Faster-Modus günstiger als GPT-4o und vergleichbar mit Claude — bei einem Fokus, der spezifisch auf Coding ausgerichtet ist.
Wer Cursor im Business-Umfeld einsetzt, sollte die Token-Kosten im Blick behalten. Ein typischer Agentic Loop — bei dem Composer 2 fünf bis zehn Schritte durchläuft — verbraucht deutlich mehr Tokens als ein einfaches Code-Completion. Im Faster-Modus kommt dabei schnell ein nennenswerter Betrag zusammen, wenn täglich viele komplexe Aufgaben delegiert werden. Cursor bietet in den Plan-Übersichten eine Nutzungsanzeige, mit der Sie Ihren Verbrauch im Blick behalten können.
Wer Cursor bereits im Team-Plan nutzt, hat Composer 2 über die enthaltenen Fast-Request-Kontingente verfügbar. Zusätzliche Requests werden nach den oben genannten Preisen abgerechnet.
Details zum Pricing finden Sie auf dem Cursor-Blog: cursor.com/de/blog.
Compositor 2 ist kein Allzweck-Agent. Es gibt klare Grenzen, die man kennen sollte.
Das Modell arbeitet lokal in der IDE. Es hat keinen Zugriff auf externe Systeme — kein Internet, keine APIs, keine Produktionsdatenbanken. Wenn Sie Aufgaben brauchen, die über den lokalen Code hinausgehen (zum Beispiel Live-Deployment oder API-Calls gegen Drittdienste), brauchen Sie zusätzliche Tools.
Ein weiterer Punkt: Datenschutz. Cursor sendet Code an Moonshot AIs Server für die Inferenz. Wer in einem regulierten Umfeld arbeitet — etwa Finanz- oder Gesundheitssektor — sollte prüfen, ob das mit den eigenen Compliance-Anforderungen vereinbar ist. Cursor bietet für Enterprise-Kunden spezifische Datenschutz-Optionen an, die das Code-Sharing einschränken. Diese sind aber mit zusätzlichen Kosten verbunden und nicht im Standard-Plan enthalten.
Außerdem gilt: Je größer und unstrukturierter ein Codebase ist, desto öfter verliert Composer 2 den Kontext. Bei sehr großen Monorepos mit schlechter Struktur arbeitet das Modell weniger zuverlässig. Gute Dokumentation und klare Dateistrukturen helfen merklich.
Cursor betont selbst, dass Composer 2 für iteratives Arbeiten ausgelegt ist — nicht für One-Shot-Lösungen komplexer Architektur-Fragen. Wer erwartet, dass das Modell auf Anhieb ein ganzes System plant und implementiert, wird enttäuscht. Wer damit in kleinen Schritten arbeitet und regelmäßig reviewt, kommt deutlich weiter.
Composer 2 ist nicht der Endpunkt. Cursor hat bereits angekündigt, dass Cursor 3 auf dem aufbaut, was Composer 2 eingeführt hat. Die nächste Version soll das Agenten-Fenster weiter ausbauen: längere Kontextfenster, bessere Tool-Integration und mehr Kontrolle über den Agenten-Prozess.
Das zeigt, in welche Richtung Cursor die IDE entwickelt: weg vom manuellen Code-Editor, hin zu einer Umgebung, in der ein Agent eigenständig große Teile der Implementierung übernimmt — während Entwickler die Richtung vorgeben und reviewen.
Für Teams, die heute mit Cursor arbeiten, lohnt sich das Update auf Composer 2 sofort. Die Benchmarks sind nicht nur Marketing — sie spiegeln sich in spürbar weniger Nacharbeit wider. Wer mit dem Vorgänger gearbeitet hat und die Frustration über vergessene Datei-Pfade oder fehlerhafte Terminal-Commands kennt, wird den Unterschied schnell bemerken.
Cursor Composer 2 ist ein solider Schritt nach vorne. Das Modell basiert auf einer ungewöhnlichen Basis — Kimi K2.5 von Moonshot AI — und wurde für Coding-Aufgaben gezielt weiterentwickelt. Die Benchmark-Verbesserungen sind real und messbar. Der Multi-Step-Ansatz funktioniert in der Praxis besser als bei Composer 1.5.
Ob sich der Faster-Tarif lohnt, hängt von Ihrer Nutzungsintensität ab. Für gelegentliche Code-Hilfe reicht Standard. Für tägliches Arbeiten mit dem Agenten ist Faster die richtige Wahl — die Zeitersparnis übersteigt die Mehrkosten.
Wichtig zu wissen: Composer 2 ist ein Werkzeug, kein Entwickler-Ersatz. Es nimmt repetitive Aufgaben ab und beschleunigt bekannte Patterns. Für Architektur-Entscheidungen, Code-Reviews und komplexe Debugging-Sessions brauchen Sie nach wie vor menschliches Urteilsvermögen.
