Mit KI programmieren: Wann Cursor Composer 2 und 2.5 passen

Wer mit KI programmieren möchte, findet in Cursor Composer 2 einen guten Einstieg für klar umrissene, gut prüfbare Codeänderungen. Die aktuell von Cursor aufgeführte Composer-Version ist jedoch Composer 2.5. Die Composer-Familie passt zur interaktiven Umsetzung; ein stärkeres Planungsmodell ist sinnvoll, wenn zunächst geklärt werden muss, was das System überhaupt leisten soll. Entscheidend ist die Klarheit der Aufgabe, nicht allein die Zahl der betroffenen Dateien.

Geprüft am 14. November 2026, anhand der aktuellen Modelldokumentation, der Veröffentlichungsbeiträge und des technischen Berichts von Cursor. Composer 2 bleibt relevant, weil es den Trainingsansatz eingeführt hat, auf dem sein Nachfolger aufbaut. Diese Einschätzung mit praktischen Auswahlregeln stützt sich auf die Dokumentation; sie ist kein eigener Praxistest mit Benchmarks.

Mit KI programmieren: Was leistet Composer 2?

Composer 2 ist ein Coding-Modell, das darauf trainiert wurde, Softwareaufgaben in der Agentenumgebung von Cursor zu bearbeiten. Ein Agent verbindet ein Modell mit Werkzeugen, mit denen es ein Repository untersuchen, Dateien ändern und die Ergebnisse prüfen kann. Das Modell bestimmt den nächsten Schritt; die umgebende Software führt ihn aus und liefert das Ergebnis zurück.

Diese Unterscheidung hilft beim Blick auf Composer in der Modellauswahl. Ausgewählt wird die Intelligenz, die den Agenten steuert. Es öffnet sich weder ein separater Editor noch wird auf eine Autovervollständigung umgeschaltet. Cursor ist die Arbeitsumgebung; Composer ist eines der darin verfügbaren Modelle.

Als Vergleich eignet sich ein Ingenieurbüro: Das Modell übernimmt die Rolle des Ingenieurs, der entscheidet, welche Verbindung untersucht werden muss. Dateisuche, Bearbeitungsfunktionen und Terminal sind seine Ausrüstung. Tests liefern die Messwerte, an denen sich der Erfolg einer Änderung ablesen lässt. Ein fähigerer Ingenieur trifft womöglich bessere Entscheidungen. Eine fehlende Spezifikation können aber weder er noch seine Ausrüstung auf Dauer ausgleichen.

Soll etwa ein bereits vorhandenes Feld zum Kontostatus auf einer Einstellungsseite erscheinen, sind möglicherweise eine Komponente, eine Datenzuordnung und Tests anzupassen. Die Arbeit verteilt sich auf mehrere Dateien, das gewünschte Verhalten steht jedoch fest. Das ist eine sinnvolle Aufgabe für Composer. Soll dagegen neu definiert werden, was der Kontostatus für Abrechnung, Zugriffskontrolle und Migrationslogik bedeutet, liegt eine andere Aufgabe vor: Hier müssen vor der Umsetzung erst Entscheidungen fallen.

Für eine neue Bewertung zählt Composer 2.5

Wer Composer neu bewertet, sollte Composer 2.5 heranziehen. Cursor veröffentlichte Composer 2 am 19. März 2026 und stellte am 18. Mai 2026 Composer 2.5 vor. Die Ankündigung von Composer 2.5 beschreibt mehr Ausdauer bei längeren Aufgaben, die zuverlässigere Befolgung komplexer Anweisungen und eine verbesserte Zusammenarbeit.

Nach Angaben von Cursor kann der Nachfolger seinen Aufwand besser anpassen, also genauer dosieren, wie viel Arbeit er vor einer Antwort investiert. Hinzu kommt gezieltes textliches Feedback im Training. Statt nur den abschließenden Erfolg zu bewerten, lässt sich damit ein bestimmter Fehler adressieren, etwa die Wahl eines nicht verfügbaren Werkzeugs. Cursor erzeugt außerdem schwierigere synthetische Aufgaben aus echten Codebasen: Beispielsweise wird ein Feature entfernt und das Modell soll es anhand von Tests wiederherstellen.

Für die Entwicklung hat das eine praktische Folge: Ein Modell kann bereits durch weniger unnötige Aktionen oder klarere Kommunikation nützlicher werden, auch ohne spektakulären Sprung im Benchmark. Bei der Bewertung durch eine Entwicklungsleitung gehören solche Verhaltensweisen neben der Korrektheit auf die Liste. Zu berücksichtigen ist auch, wie viel Klärungs-, Nachbesserungs- und Prüfaufwand das Ergebnis verursacht.

Composer 2.5 baut weiterhin auf demselben zugrunde liegenden Checkpoint auf wie Composer 2. Es ist ein Nachfolger mit zusätzlichem Training. Daraus folgt nicht, dass sämtliche früheren Aussagen zu Composer automatisch für das aktuelle Modell gelten.

Der technische Bericht zu Composer 2: So hat Cursor das Modell trainiert

Cursor hat ein bestehendes Modell auf Programmierarbeit spezialisiert und anschließend für Aufgaben in seiner tatsächlichen Einsatzumgebung trainiert. Der Überblick zum Training beschreibt ein fortgesetztes Vortraining mit einem stark codehaltigen Datenmix. Darauf folgte Reinforcement Learning in realistischen Cursor-Sitzungen mit den produktiv eingesetzten Werkzeugen und der entsprechenden Agentenkonfiguration.

Beim fortgesetzten Vortraining lernt das Basismodell anhand weiterer Daten hinzu und vertieft so sein Programmierwissen. Beim Reinforcement Learning bearbeitet es Aufgaben; sein Verhalten wird danach angepasst, wie gut das Ergebnis ausfällt. Die erste Stufe erweitert das Wissen, die nächste verbessert dessen Anwendung.

Der vollständige technische Bericht ergänzt die Details: Training mit langem Kontext, gezielt ausgewählte Beispiele für überwachtes Lernen und Belohnungen, die Kommunikation und Werkzeugnutzung formen. Außerdem beschreibt er Abzüge, die übermäßigen Aufwand bei einfachen Anfragen verhindern sollen, ohne die Arbeit an schwierigen Aufgaben einzuschränken. Das erklärt das Produktziel: nützliche Programmierintelligenz in einem Tempo, das interaktives Arbeiten erlaubt.

Composer 2 und Kimi: Was steckt hinter der Verbindung?

Composer 2 basiert auf dem Kimi K2.5-Checkpoint von Moonshot. Die Bezeichnung als Cursors eigenes Modell bedeutet nicht, dass Cursor das ursprüngliche Basismodell von Grund auf vortrainiert hat. Cursor benennt diesen Ausgangspunkt ausdrücklich und erläutert das zusätzliche eigene Training.

Umgekehrt macht ein gemeinsamer Ausgangscheckpoint die eingesetzten Systeme nicht austauschbar. Weiteres Training verändert das Verhalten; die Agentenumgebung bestimmt mit, welche Aktionen möglich sind. Für das eigene Repository zählt, ob das Gesamtsystem ein korrektes, gut prüfbares Ergebnis liefert. Die Herkunft des Modells erklärt die Technik, ersetzt aber diese Bewertung nicht.

Deshalb greift auch die Erklärung „auf Code trainiert“ zu kurz. Composers Spezialisierung umfasst die Auswahl von Werkzeugen, den Umgang mit deren Ergebnissen und das ausdauernde Bearbeiten einer Aufgabe. Es geht um mehr als eine plausibel aussehende Funktion in einer Chatantwort.

Kontext und Werkzeuge: Welche Grenze bleibt bestehen?

Die aktuelle Produktreferenz zu Composer 2.5 nennt ein Kontextfenster von 200k Tokens. Tokens sind die Text- und Codebausteine, die ein Modell verarbeitet; der Kontext ist sein Arbeitsbereich für eine Anfrage. Die aktuelle Composer-Modelldokumentation führt Agent- und Thinking-Fähigkeiten auf, außerdem Dateisuche, Lesen und Bearbeiten von Dateien, Shell-Befehle und weitere Agentenwerkzeuge.

Dieselbe Seite beschreibt Browser- und Bildgenerierungswerkzeuge. Diese stehen über die Agentenumgebung bereit; daraus lässt sich nicht ableiten, dass das zugrunde liegende Modell sämtliche Eingabearten beherrscht. Insbesondere knüpft die allgemeine Beschreibung des Dateilesens das Lesen von Bildern an ein Modell mit Bildverständnis. Die gemeinsame Werkzeugliste belegt daher kein natives Bildverständnis.

Bei einem großen Repository liegt nicht die gesamte Codebasis dauerhaft im Arbeitskontext. Die passenden Dateien zu suchen und zu lesen, gehört zur Aufgabe. Ein großes Kontextfenster bietet mehr Platz für relevante Informationen; die richtige Auswahl bleibt trotzdem entscheidend.

Composers Bericht beschreibt die Selbstzusammenfassung: Das Modell verdichtet seinen bisherigen Arbeitsverlauf, um eine lange Aufgabe fortsetzen zu können. Im Training werden Zusammenfassungen belohnt, die zur späteren Lösung beitragen. Gehen wichtige Informationen verloren, gibt es Abzüge. Das ähnelt eher einer laufend aktualisierten Übergabenotiz als dem Versuch, jedes Gespräch für immer auf dem Schreibtisch liegen zu lassen.

Die entscheidende Grenze ist der Verlust einer wesentlichen Vorgabe, nicht bloß fehlender Platz. Vergisst ein Agent bei einem langen Refactoring, dass eine alte API weiter funktionieren muss, können weitere Änderungen den Fehler verschärfen. Kompatibilitätsanforderungen und Abnahmeprüfungen gehören deshalb in dauerhaft verfügbare Projektanweisungen oder eine Aufgabenspezifikation. Driftet das Gespräch ab, sollte die Vorgabe erneut genannt und der Diff geprüft werden, bevor der Agent weiterarbeitet.

Composer-2-Benchmarks: Was belegen Cursors Ergebnisse?

Cursors Ergebnisse sprechen für einen deutlichen Fortschritt beim Programmieren gegenüber früheren Composer-Modellen, nicht für einen allgemeinen Sieg über jedes Spitzenmodell. Der Veröffentlichungsbeitrag zu Composer 2 nennt 61.3 auf CursorBench, 61.7 auf Terminal-Bench 2.0 und 73.7 auf SWE-bench Multilingual. Das sind Messungen von Cursor, keine unabhängigen Ergebnisse dieses Artikels.

CursorBench basiert auf Programmiersitzungen von Cursor-Entwicklern. Terminal-Bench prüft Agentenarbeit in einer Terminalumgebung; SWE-bench Multilingual bewertet die Lösung von Repository-Issues in verschiedenen Sprachen. Aufgaben, Bewertung und Agentenkonfigurationen unterscheiden sich. Aus den Punktzahlen lässt sich keine Erfolgswahrscheinlichkeit für die nächste eigene Migration errechnen.

Der Veröffentlichungsbeitrag erklärt zudem, dass Vergleiche unterschiedliche Agentenkonfigurationen nutzen können, also unterschiedliche Software um das jeweilige Modell herum. Das schränkt die Aussagekraft ein: Wenn Werkzeuge und Ausführungsmethoden variieren, lassen sich die Leistung eines Modells und die eines vollständigen Agenten nicht sauber voneinander trennen.

Composer-2.5-Benchmarks: Die Versionen getrennt betrachten

Veröffentlichte Ergebnisse von Composer 2 werden nicht zu Ergebnissen von Composer 2.5. Die Ankündigung des Nachfolgers beschreibt Verbesserungen bei Intelligenz und Verhalten und liefert eigenes Evaluationsmaterial. Für eine aktuelle Auswahlentscheidung sind diese Belege getrennt von den Zahlen der älteren Veröffentlichung zu betrachten.

Eine hilfreiche eigene Bewertung nutzt eine repräsentative Repository-Aufgabe mit bekannter Abnahmebedingung. Ein Modell, das eine saubere Korrektur mit nachvollziehbaren Tests liefert, ist wertvoller als eines, das anderswo gut abschneidet, dessen Absicht sich aber erst mühsam rekonstruieren lässt. Das ist eine Empfehlung für die eigene Evaluation, keine Behauptung, dieser Artikel habe sie durchgeführt.

Composer 2 oder Composer 2 Fast?

Fast steht laut Cursor für schnellere Bereitstellung der Antworten, nicht für ein intelligenteres Modell. Sowohl die Ankündigung von Composer 2 als auch die aktuelle Composer-Dokumentation schreiben der schnelleren Variante dieselbe Intelligenz zu. Sie eignet sich, wenn Wartezeiten zwischen Interaktionen stören. Schwächen im Schlussfolgern behebt eine frühere Antwort nicht.

Der historische Geschwindigkeitsvergleich verwendete eine Momentaufnahme des Cursor-Datenverkehrs vom 18. März 2026. Cursor weist darauf hin, dass die Geschwindigkeit von den Kapazitäten der Anbieter abhängt und sich im Zeitverlauf verändert. Eine bei der Einführung gemessene Tokenrate wäre deshalb kein belastbares Versprechen für eine heutige Sitzung.

Auch die damalige Aussage, Fast sei standardmäßig aktiv, hat inzwischen eine tarifbedingte Ausnahme: Im Plus-Tarif ist Fast fest deaktiviert. Für Kontoeinstellungen hat Cursors aktuelle Modell- und Tarifreferenz Vorrang vor der alten Ankündigung. Composer nutzt in kostenpflichtigen Tarifen das enthaltene Kontingent für Cursor-Modelle. Der Zugriff auf Claude und GPT erfordert einen geeigneten Tarif und unterliegt eigenen Nutzungsregeln.

Die umfassenderen Änderungen beim Zugriff, einschließlich der Unterschiede zwischen aktuellen und älteren Konten, behandelt Cursor-Modelle nach der Oktober-Umstellung. Für die Praxis zählt hier: die gewählte Variante und die Einstellungen des eigenen Kontos prüfen, bevor identische Bedingungen für jede Composer-Sitzung vorausgesetzt werden.

Wann sind Composer, Claude oder GPT die richtige Wahl?

Für eine klar definierte Änderung eignet sich Composer; überwiegt die Ungewissheit, empfiehlt sich ein stärkeres Planungsmodell. Das folgt Cursors Empfehlungen zur Modellauswahl. Dort ist Composer für interaktives Programmieren vorgesehen, während Anthropic Claude Opus und OpenAI GPT-5.6 Sol für komplexe Aufgaben mit mehreren Schritten empfohlen werden.

Eine schnelle Änderung über mehrere Dateien: Mit Composer beginnen

Ein bereits von einer API geliefertes Feld soll sichtbar werden, die bestehende Validierung erhalten bleiben und die zugehörigen Tests sollen angepasst werden. Composer braucht dafür eine Beschreibung des geänderten Verhaltens, der unveränderlichen Anforderungen und der Abnahmeprüfung. Die betroffenen Dateien kann der Agent selbst suchen; nicht jeder Dateiname muss vorab erraten werden.

Der Vorteil liegt in der kurzen Rückkopplung: eine vorgeschlagene Änderung prüfen, eine falsche Annahme korrigieren und weiterarbeiten. Eine Aufgabe kann viele Dateien betreffen, ohne offene Architekturfragen aufzuwerfen. Die Dateizahl ist ein schlechter Maßstab für die Modellauswahl; ungeklärte Entscheidungen sind ein besserer.

Kehrt derselbe Fehler immer wieder zurück, hilft es nicht, den Prompt endlos zu verschärfen. Sind die Anforderungen klar, das Modell übersieht aber wiederholt eine Abhängigkeit, sollten die Schritte zur Reproduktion und der aktuelle Diff an ein anderes Modell gehen. Sind die Anforderungen unklar, müssen sie vor dem Wechsel präzisiert werden.

Eine schwierige Architekturänderung: Mit Claude Opus oder GPT planen

Kontoberechtigungen sollen aus verstreuten Einzelprüfungen in eine gemeinsame Autorisierungsschicht überführt werden. Das Risiko liegt weniger im Schreiben der Hilfsfunktion. Entscheidend ist, welche Dienste welcher Identität vertrauen, wie das bestehende Verhalten während der Migration erhalten bleibt und wie sich die Umstellung zurückrollen lässt.

Ein stärkeres Planungsmodell kann diese Abhängigkeiten vor der Bearbeitung abbilden und den Migrationsentwurf kritisch prüfen. Cursors Referenz zu Claude Opus 5.5 nennt einen Standardkontext von 300k und ein Maximum von 1M sowie die Empfehlung, die Variante mit hohem Denkaufwand zu verwenden. Das ist ein dokumentierter Kapazitätsgrund, das Modell in Betracht zu ziehen, wenn umfangreiche Informationen gemeinsam verglichen werden müssen. Für komplexe, mehrstufige Arbeit nennt Cursor außerdem GPT-5.6 Sol.

Die Empfehlung gilt vor allem dort, wo Ungewissheit teuer wird: bei langen Abhängigkeitsketten und der Prüfung eines Entwurfs. Sie besagt nicht, dass eines dieser Modelle jede Repository-Aufgabe gewinnt. Sobald der Plan steht, lässt sich Composer weiterhin für klar abgegrenzte Teile der Umsetzung bewerten.

Ein Claude-Modell in Cursor auszuwählen, ist eine andere Entscheidung als die für das Produkt Claude Code. Der Vergleich von Claude Code und Cursor behandelt diese Frage des Arbeitsablaufs. Die Intelligenz im vorhandenen Editor zu wechseln, erfordert keinen Editorwechsel.

Wo der Hype täuscht: Schnelle Ausgabe ist noch keine fertige Arbeit

Der Trugschluss besteht darin, Tempo, langen Kontext oder einen Benchmark-Vorsprung als Beleg für eine zusammenführbare Änderung zu behandeln. Cursor selbst beschreibt ein für schwierige Aufgaben trainiertes Modell. Trotzdem muss geprüft werden, ob die konkrete Anforderung erfüllt wurde.

Ein Test kann erfolgreich sein, während nicht spezifiziertes Verhalten weiterhin falsch ist. Ein langer Kontext kann eine Kompatibilitätsanforderung enthalten, ohne dass der Agent sie konsequent anwendet. Eine überzeugende Zusammenfassung kann einen fehlgeschlagenen Befehl auslassen. Geprüft werden müssen die tatsächlichen Änderungen und Belege, nicht nur die abschließende Erklärung.

Der praktische Engpass verschiebt sich häufig vom Schreiben des Codes zur Prüfung von Entscheidungen. Wer allein entwickelt, sollte Aufgaben so weit eingrenzen, dass sich der resultierende Diff erklären lässt. Eine Entwicklungsleitung sollte festlegen, welche Nachweise eine abgeschlossene Aufgabe enthalten muss: betroffenes Verhalten, ausgeführte Tests, ungelöste Fehler und Annahmen, die eine menschliche Entscheidung erfordern.

Was sich ab Montag konkret ändern sollte

Einzelentwickler sollten das aktuelle Composer jetzt an einem abgegrenzten Ticket erproben; Entwicklungsleitungen sollten erst Belege aus dem eigenen Repository sammeln, bevor sie es zum Teamstandard machen. Ein funktionierendes Setup sollte bleiben, bis eine repräsentative Aufgabe einen konkreten Grund für den Wechsel liefert.

1. 1

   Das ausgewählte Modell prüfen

   Die Modellauswahl im Chat- oder Agentenbereich von Cursor öffnen. Prüfen, ob der aktuelle Composer-Eintrag ausgewählt ist, und die verfügbaren Geschwindigkeitseinstellungen ansehen. Die Auswahl bleibt über Gespräche hinweg bestehen; ein neuer Chat setzt sie also nicht automatisch zurück.

2. 2

   Die Abnahmebedingung festlegen

   Ein klar umrissenes Backlog-Ticket auswählen. Das erwartete Verhalten, die zu erhaltende Kompatibilität und die Erfolgskontrollen beschreiben. Der Agent soll auch melden, welche Prüfungen er nicht ausführen konnte.

3. 3

   Ungeklärte Fragen in die Planung geben

   Zeigt die Arbeit eine offene Entwurfsentscheidung, die Umsetzung unterbrechen und diese Entscheidung mit einem geeigneten Planungsmodell prüfen. Reproduktionsschritte, Vorgaben und Diff übergeben statt einer vagen Aufforderung, sich mehr anzustrengen.

4. 4

   Die abgenommene Änderung bewerten

   Diff und Testnachweise prüfen. Composer dort als Standard beibehalten, wo es mit überschaubarem Korrekturaufwand akzeptable Arbeit liefert. Für Aufgaben mit offenen Entwurfsfragen oder wiederholten Fehlern einen Weg zum Modellwechsel vorsehen.

Häufige Fragen

Was ist Cursor Composer?

Composer bezeichnet in der Modellauswahl Cursors eigene Familie von Coding-Modellen. Sie steuert die Agentenarbeit in Cursor. Die aktuell dokumentierte Composer-Version ist Composer 2.5.

Woran erkenne ich die Composer-Version?

Den Namen des ausgewählten Modells im Chat- oder Agentenbereich mit der aktuellen Modellreferenz vergleichen. Auto ist eine Routing-Option und kann zwischen Gesprächsschritten unterschiedliche Modelle einsetzen. Die Auswahl von Auto belegt daher nicht, dass Composer verwendet wird.

Eignet sich Composer 2.5 zum Programmieren?

Cursor beschreibt es als Modell für interaktives Programmieren mit verbesserter Ausdauer bei längeren Aufgaben. Der Einstieg sollte eine Aufgabe sein, deren Erfolg sich überprüfen lässt. Bei einer unklaren Architekturänderung muss erst der Entwurf stehen, bevor die Umsetzung beurteilt wird.

Was ist Composer und wozu wird es eingesetzt?

In diesem Artikel ist mit Composer das Coding-Modell von Cursor gemeint. Es wird ausgewählt, um mit den Werkzeugen des Agenten im Repository zu arbeiten, besonders wenn die Umsetzung interaktiv gesteuert werden soll.

Wie wird Composer verwendet?

Im Agentenbereich von Cursor das aktuelle Composer-Modell auswählen, die gewünschte Änderung beschreiben und Abnahmeprüfungen vorgeben. Vor der Übernahme die entstandenen Änderungen und Werkzeugergebnisse prüfen.

Wofür wird die Software Composer genutzt?

Bei Cursors Composer geht es um Softwareentwicklung: eine Aufgabe verstehen, Dateien untersuchen, Änderungen vornehmen und Ergebnisse mithilfe der Agentenwerkzeuge prüfen. Andere Software gleichen Namens behandelt dieser Leitfaden nicht.

Wie funktioniert Composer?

Das Modell wählt eine Aktion, ein Werkzeug führt sie aus und das Ergebnis fließt in die nächste Entscheidung ein. Cursor hat Composer mit Programmieraufgaben in einer passenden Agentenumgebung trainiert. Trainierte Selbstzusammenfassung unterstützt das Weiterarbeiten an längeren Aufgaben.

Gibt es eine kostenlose Composer-App?

Wenn Cursors Coding-Modell gemeint ist: Cursors Free-Tarif bietet begrenzte Agent- und Chat-Nutzung mit eigenen Modellen. Das ist keine unbegrenzte Composer-Nutzung. Apps zum Komponieren von Musik werden hier nicht verglichen.

Wozu dient composer install?

Die Suche nach einem Installationsbefehl ist von der Auswahl von Cursors Coding-Modell zu unterscheiden. Für das hier behandelte Modell wird Cursors Modellauswahl genutzt; dieser Leitfaden ist keine Referenz für Installationsbefehle.

Den Newsletter abonnieren für praktische Leitfäden zu Coding-Modellen und den passenden Aufgaben.