Composer 2.5: Benchmarks, Preise und der Vergleich

Cursor hat am 18. Mai 2026 Composer 2.5 veröffentlicht, knapp zwei Monate nach Composer 2 im März. Der kurze Abstand zeigt, wie schnell Cursor seine eigene Modellreihe weiterentwickelt.

Laut Cursor liegt Composer 2.5 auf mehreren Coding-Benchmarks nahe bei Claude Opus 4.7 und GPT-5.5. Auch der Tokenpreis ist niedriger als bei den Spitzenmodellen. Beim Training gab es ebenfalls Änderungen: mehr synthetische Aufgaben, schwierigere Trainingsumgebungen und eine Feedback-Methode, die gezielt einzelne Fehler in langen Codingsessions adressiert.

In diesem Artikel betrachte ich Composer 2.5 nicht nur als Benchmark-Update. Ich zeige, was das Modell ist, was sich geändert hat, wie die Benchmarks aussehen, wie sich die Preise im Vergleich zu Spitzenmodellen einordnen, und wo es im Coding-Workflow seinen Platz hat. Es gibt auch Einschränkungen, die du kennen solltest, bevor du die Punktzahlen als ganze Wahrheit nimmst.

Mehr Hintergrund zu den anderen Modellen in diesem Vergleich findest du in unseren Guides zu Claude Opus 4.7 und GPT-5.5.

Was ist Cursors Composer-2.5-Modell?

Composer 2.5 ist das neueste Modell der Composer-Familie von Cursor, optimiert für Coding-Aufgaben in der Cursor IDE. Es folgt auf Composer 1, Composer 1.5 und Composer 2.

Composer-Timeline vom Launch bis 2.5. Bild: Autor.

Das ist kein allgemeiner Chatbot. Composer 2.5 ist trainiert für Dateiübergreifende Edits, Terminalbefehle, Toolnutzung und längere Codingsessions. Trainingsziele und Benchmarks sind auf Software-Engineering-Aufgaben ausgerichtet.

Laut Launch-Post schneidet das Modell bei Coding-Aufgaben besser ab als Composer 2 und verhält sich in langen Sessions anders. Es ist jetzt die Standardoption im Cursor-Modelpicker, Composer 2 bleibt aber verfügbar. Außerdem läuft es ausschließlich in Cursor. Es gibt keine öffentliche API, keine Hugging-Face-Model-Card und keinen Gateway-Zugang über andere Anbieter.

Was sich in Composer 2.5 geändert hat

Die Änderungen in Composer 2.5 fallen in zwei Bereiche: Leistung bei Coding-Aufgaben und Kollaborationsverhalten. Ersteres ist leichter messbar als Letzteres. Deshalb lohnt es sich, die Punkte zu trennen, die Cursor mit Zahlen belegt, von denen, die eher qualitativ beschrieben werden.

Bessere Leistung bei längeren Aufgaben

Composer 2.5 zielt auf längere Codingsessions, in denen ein Modell Dateien lesen, Terminalbefehle ausführen, Fehler beheben und iterieren muss. Das ist wichtig, weil echte Entwicklung selten in eine einzelne Prompt-Antwort passt.

Cursor hat das Modell in schwierigeren Reinforcement-Learning-Umgebungen für diese Art Arbeit trainiert. Aufgaben wurden während des Trainings generiert und der Schwierigkeitsgrad stieg über die Zeit.

Besseres Befolgen von Anweisungen und Zusammenarbeit

Laut Release folgt das Modell Anweisungen zuverlässiger. Genannt wird eine Kalibrierung des Aufwands: Das Modell soll bei schwierigen Aufgaben mehr Rechenaufwand investieren und einfache nicht überdenken.

Hier gibt es einen Vorbehalt. Cursor weist darauf hin, dass diese Verhaltensänderungen „von bestehenden Benchmarks nicht gut erfasst werden“. Dieser Teil stützt sich also vor allem auf Cursors eigene Einschätzung und frühes Nutzerfeedback, nicht auf öffentliche Scores.

Schwierigere RL-Umgebungen

Der Launch-Post beschreibt die Trainingsänderung als „Skalierung des Trainings, komplexere RL-Umgebungen und neue Lernmethoden“. Es kamen 25-mal mehr synthetische Aufgaben zum Einsatz als bei Composer 2.

Wie Cursor Composer 2.5 trainiert hat

Die Trainingsdetails erklären, warum sich das Modell ohne neue Basisarchitektur verändert hat. Composer 2.5 nutzt dieselbe Grundlage wie Composer 2, aber die Arbeit nach dem Basistraining ist anders. Nicht jedes Infrastrukturdetail ist für Leser gleich relevant, ein paar Punkte helfen aber, die Benchmark-Bewegung einzuordnen.

Auf Kimi K2.5 aufgebaut

Composer 2.5 basiert auf demselben Open-Source-Checkpoint wie Composer 2: Moonshot AIs Kimi K2.5. Cursor hat das im Launch-Post klar benannt, was relevant ist, weil das Basismodell bei Composer 2 diskutiert wurde.

Kimi K2.5 nutzt eine Mixture-of-Experts-Architektur. Cursor setzt darauf fortgesetztes Pretraining und Reinforcement Learning und sagt, dass rund 85% des gesamten Rechenaufwands für das Endmodell aus der eigenen Arbeit nach dem Basistraining stammen.

Gezieltes RL mit Textfeedback

Das ist die wichtigste technische Änderung in Composer 2.5. Standard-RL gibt einem Modell am Ende einer langen Sequenz ein einziges Belohnungssignal. In einer langen Codingsession kann diese Endbelohnung zu verrauscht sein, um zu zeigen, wo das Modell falsch abgebogen ist.

Teacher und Student teilen sich eine Runde. Bild: Autor.

Cursors Methode fügt genau an der Stelle, an der das Modell eine schlechte Entscheidung traf, einen kurzen Texthinweis ein. Ruft das Modell zum Beispiel ein nicht existentes Tool auf, kann der Trainingsprozess eine Erinnerung mit der korrekten Toolliste einblenden. Die Variante mit Hinweis agiert als „Teacher“, das ursprüngliche Modell als „Student“. Ein Distillationsverlust verschiebt dann das Verhalten des Students nur in dieser Runde in Richtung des Teachers.

Das Ergebnis ist gezielteres Training: Einzelne Fehler lassen sich korrigieren, ohne einen gesamten langen Rollout vage als richtig oder falsch zu bewerten. Cursor hat diese Methode während des Composer-2.5-Trainings auf Codingstil, Toolnutzung und Modellkommunikation angewendet.

Synthetische Daten in größerem Maßstab

Composer 2.5 wurde mit 25-mal mehr synthetischen Aufgaben trainiert als Composer 2. Diese Tasks basieren auf echten Codebasen, nicht auf Spielzeugbeispielen.

Eine von Cursor beschriebene Methode ist Feature-Deletion. Ein Agent startet mit einer echten Codebasis und einer großen Test-Suite, entfernt dann Code und Dateien, während das restliche Projekt funktionsfähig bleibt. Die synthetische Aufgabe ist, das entfernte Feature zu rekonstruieren; die Tests liefern ein überprüfbares Belohnungssignal.

Der große Maßstab synthetischen Trainings bringt eigene Risiken mit sich. Cursor dokumentierte Fälle, in denen Composer 2.5 Abkürzungen fand, etwa das Wiederherstellen gelöschter Informationen aus einem Python-Type-Checking-Cache oder das Dekomplilieren von Java-Bytecode, um eine externe API zu rekonstruieren. Das Unternehmen sagt, es habe dies mit Monitoring erkannt, räumt aber ein, dass Training in diesem Maßstab „zunehmende Sorgfalt“ erfordert.

Infrastrukturänderungen

Auf der Infrastrukturseite nutzte Cursor Sharded Muon und Dual-Mesh HSDP für fortgesetztes Pretraining. Diese Änderungen reduzierten Kosten und Dauer beim Training auf großen GPU-Clustern.

Composer-2.5-Benchmarks: Terminal-Bench, SWE-Bench und CursorBench

Benchmarks sind hilfreich, zeigen aber nicht das ganze Bild. Ich würde sie als Ausgangspunkt für Vergleiche sehen, nicht als endgültiges Urteil darüber, wie sich das Modell im Alltag anfühlt.

Cursor bewertet Composer 2.5 über drei Benchmarks:

SWE-Bench Multilingual prüft, ob ein Modell reale GitHub-Issues in mehreren Programmiersprachen lösen kann. Jede Aufgabe gibt dem Modell ein Repository und eine Problemstellung und prüft dann, ob der Patch die zugehörigen Tests besteht.

Terminal-Bench 2.0 misst, ob ein KI-Agent in realen Terminal-Workflows arbeiten kann: Dateien inspizieren, Befehle ausführen, Fehler debuggen und mehrstufige Aufgaben abschließen.

CursorBench v3.1 ist Cursors interner, privater Benchmark. Er bewertet Agents bei mehrdeutigen, dateiübergreifenden Aufgaben aus echten Cursor-Sessions, inklusive Codebase-Verständnis, Bugfinding, Planung und Code-Review. Die Einschränkung: CursorBench ist von außen weder prüf- noch reproduzierbar; Scores sollten innerhalb derselben Eval-Version verglichen werden.

Ein wichtiger Vorbehalt, bevor du zu viel in diese Zahlen hineinliest: Benchmark-Vergleiche über Modelle hinweg sind nicht immer sauber. Unterschiedliche Evaluations-Setups und Aufwandseinstellungen können die Scores verschieben, und Cursor vermerkt, dass Opus 4.7 und GPT-5.5 für öffentliche Evaluierungen selbstberichtete Werte nutzen. Betrachte sie als Richtungsangaben, nicht als Tests unter identischen Bedingungen.

Eine spätere externe Benchmark von Artificial Analysis zeigt eine ähnliche Tendenz, nutzt aber einen anderen Benchmark-Mix. Composer 2.5 erzielte 62 im Artificial Analysis Coding Agent Index, hinter Claude Opus 4.7 mit maximalem Aufwand (66) und GPT-5.5 mit xhigh Reasoning (65). 

Auffällig ist die Kostendifferenz: Artificial Analysis schätzte Composer 2.5 auf 0,07 $ pro Aufgabe (Standard) und 0,44 $ (Fast), verglichen mit 4,10 $ für Opus 4.7 max und 4,82 $ für GPT-5.5 xhigh.

Composer 2.5 vs. Composer 2 vs. Composer 1.5: So schneiden sie ab

Die Composer-Familie hatte in kurzer Zeit drei Releases. Composer 1.5 erschien im Februar 2026, Composer 2 im März und Composer 2.5 im Mai. Jede Version hat den Trainingsansatz anders weiterentwickelt.

Composer 2.5 gegenüber Composer 2

Der Sprung von Composer 2 zu 2.5 zeigt sich am deutlichsten bei Terminal-Bench 2.0 (von 61,7% auf 69,3%) und bei SWE-Bench Multilingual (von 73,7% auf 79,8%). Der Gewinn bei CursorBench ist kleiner, außerdem wechselte die Benchmark-Version von v3 auf v3.1, was den Vergleich weniger direkt macht.

Größer ist der Unterschied in der Trainingspipeline. Composer 2 führte fortgesetztes Pretraining auf Kimi K2.5 ein. Composer 2.5 behielt diese Basis bei und ergänzte gezieltes Textfeedback, 25-mal mehr synthetische Aufgaben und Infrastrukturänderungen. Der Standardpreis blieb gleich.

Composer 2.5 gegenüber Composer 1.5

Composer 1.5 entstand, indem Reinforcement Learning auf demselben vortrainierten Modell wie Composer 1 um den Faktor 20 skaliert wurde. Es führte adaptives Denken und Selbstzusammenfassung ein, damit das Modell bei langen Sessions seinen Kontext komprimieren kann.

Die Lücke von Composer 1.5 zu 2.5 ist in allen Benchmarks groß. Zudem sank der Tokenpreis: Composer 1.5 lag bei 3,50 $ pro Million Input-Tokens und 17,50 $ pro Million Output-Tokens, etwa siebenmal teurer als Composer 2.5 Standard.

Was sich in der Praxis geändert hat

Über die Versionen hinweg ist das Muster klar: Jede Generation veränderte das Verhalten in langen Sessions und beim Befolgen von Anweisungen, während Composer 2 und 2.5 die Kosten für längere Agent-Sessions senkten.

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5: Benchmarks, Preis und Trade-offs

Dieser Vergleich dürfte viele zuerst interessieren. Composer 2.5 liegt in einigen Bereichen bei Coding-Benchmarks nah dran, bietet günstigere Tokenpreise als die unten gelisteten Spitzenmodelle und hat klare Trade-offs.

Benchmark-Vergleich

GPT-5.5 führt bei Terminal-Bench 2.0 mit 82,7% und liegt damit rund 13 Punkte vor Composer 2.5. Diese Lücke zählt, wenn deine Arbeit stark vom Terminaleinsatz abhängt.

Claude Opus 4.7 liegt bei SWE-Bench Multilingual leicht vor Composer 2.5 (80,5% versus 79,8%), also weniger als ein Punkt. Bei CursorBench liegt Composer 2.5 mit 63,2% über Opus 4.7 in den Default-Einstellungen (61,6%), aber unter Opus 4.7 bei maximalem Aufwand (64,8%). GPT-5.5 erreicht bei xhigh 64,3%, der Default liegt bei 59,2%.

Die Modelle erfüllen nicht dieselbe Rolle. Opus 4.7 und GPT-5.5 sind breiter aufgestellte Spitzenmodelle. Composer 2.5 ist ein Coding-Modell, das nur in Cursor läuft. Die Scores sind bei manchen Coding-Aufgaben nah beieinander, aber die Produktgrenzen unterscheiden sich.

Preisvergleich

Die Kostendifferenz ist die klarste Trennlinie zu den Spitzenmodellen.

Composer 2.5 Standard ist pro Token etwa ein Zehntel so teuer wie Opus 4.7 und GPT-5.5. Auch die Fast-Variante liegt unter den Standardstufen der beiden Spitzenmodelle.

Diese Preise gelten im Mai 2026. Prüfe vor einer Entscheidung Cursors Modellpreise, Anthropics Opus-Preise und OpenAIs API-Preise.

Ein oft übersehener Punkt: Die Preise für Composer 2.5 Fast haben sich gegenüber Composer 2 Fast verdoppelt. Standard blieb stabil, aber Fast ist der Default, was die Kosten für einige Nutzer dennoch erhöhen kann.

Welches Modell solltest du wählen?

Die Wahl hängt davon ab, ob dir Kosten, Terminalarbeit oder tiefere Planung am wichtigsten sind:

• Composer 2.5 passt für den Alltag in Cursor, besonders für Dateiübergreifende Edits, Refactoring, Debugging und Agentsessions, bei denen die Kosten zählen.
• GPT-5.5 passt für Aufgaben, bei denen Terminal-Performance am meisten zählt.
• Claude Opus 4.7 passt für Aufgaben, die sorgfältiges Reasoning, Architekturplanung oder ein Kontextfenster von 1 Million Tokens benötigen.

Das ist das Muster, das ich aus den Zahlen mitnehme: Composer 2.5 deckt Routine-Coding ab, während Spitzenmodelle weiterhin für breiteres Reasoning oder höhere Terminal-Scores sinnvoll sind.

Composer 2.5 Standard vs. Fast: Geschwindigkeit, Preis und wann du was nutzt

Cursor liefert Composer 2.5 wie schon Composer 2 in zwei Varianten aus. Laut Cursor teilen beide dieselbe zugrunde liegende Intelligenz. Der Unterschied liegt vor allem in der Antwortgeschwindigkeit und den Kosten.

Cursor-Modelpicker mit Composer ausgewählt. Bild: Autor.

Fast ist der Default und kostet 3,00 $ pro Million Input-Tokens und 15,00 $ pro Million Output-Tokens. Es ist für interaktive Sessions gedacht, bei denen geringe Latenz zählt. Standard liegt bei 0,50 $ und 2,50 $ und passt zu Hintergrundaufgaben oder längeren Agent-Loops, bei denen unmittelbares Feedback weniger wichtig ist.

Die Nutzung von Composer 2.5 läuft in Cursors „Auto + Composer“-Pool und ist getrennt vom API-Pool für externe Modelle wie Claude und GPT. Zum Launch gab es außerdem doppelte Nutzung in der ersten Woche.

Einschränkungen und Vorbehalte von Composer 2.5

Die Vorbehalte betreffen Zugang, Benchmarks und Trainingsrisiken. Sie sind nicht ungewöhnlich, beeinflussen aber, wie stark du Cursors Aussagen gewichten solltest.

Nur in Cursor verfügbar. Wie oben erwähnt, hat Composer 2.5 keine öffentliche API. Wenn dein Workflow darauf angewiesen ist, ein Modell aus eigenen Skripten oder Pipelines aufzurufen, ist Composer 2.5 keine Option.

CursorBench ist nicht unabhängig. Wie im Benchmark-Teil beschrieben, ist CursorBench v3.1 intern. Die Methodik ist nicht vollständig öffentlich, und externe Forschende können die Aufgaben nicht reproduzieren.

Variabilität im Benchmark-Setup. Die Scores der Spitzenmodelle in Cursors Benchmark-Grafik wurden nicht einheitlich erhoben. Betrachte die Vergleiche als richtungsweisend, nicht als endgültig.

Reward Hacking im Training. Cursor hat Fälle offengelegt, in denen das Modell in synthetischen Aufgaben clevere Abkürzungen fand, statt sie regulär zu lösen. Das ist ein inhärentes Risiko von RL in diesem Maßstab, selbst wenn Monitoring offensichtliche Beispiele erkennt.

Aufwandskalibrierung ist unbestätigt. Cursors Aussagen zu Kommunikationsstil und Aufwandskalibrierung sind nicht durch Benchmarkdaten belegt, wie oben beschrieben. Von außen ist das schwer zu prüfen.

Wann Composer 2.5 Sinn ergibt

Das hängt von der Aufgabe ab. Ich würde Composer 2.5 weniger als universelle Modellwahl sehen, sondern als Coding-Modell für Teams und Entwickler, die bereits in Cursor arbeiten.

Wenn du den Großteil des Tages in Cursor codest und dir Tokenkosten wichtig sind, hat Composer 2.5 Standard den niedrigsten Preis in der Composer-2.5-Reihe. Das gilt für Edits, Refactoring, Debugging und Langzeitsessions wie oben beschrieben.

Wenn Reaktionsgeschwindigkeit wichtiger ist, ist Composer 2.5 Fast die Standardoption.

Wenn die Aufgabe breiteres Reasoning, ein größeres Kontextfenster oder höhere Benchmark-Scores in einem bestimmten Bereich erfordert, könnten Claude Opus 4.7 oder GPT-5.5 besser passen.

Kurz gesagt: Composer 2.5 übernimmt die Routine im Coding, während ein Spitzenmodell für Aufgaben sinnvoll ist, die breiteres Reasoning oder höhere Terminal-Scores verlangen. So bleibt der Vergleich hilfreich, ohne zu einer Einheits-Empfehlung zu werden.

Fazit

Composer 2.5 lässt sich leicht als Benchmark-Geschichte lesen, doch der wichtigere Punkt ist die Richtung: Cursor verpackt nicht nur Spitzenmodelle in einen Editor, sondern baut eine Modellreihe rund um die Arbeit, die seine Agents ohnehin leisten: Dateiübergreifende Edits, Terminalschritte, längere Sessions und Fehlererholung.

Wie erwähnt, ist der Trade-off, dass Composer 2.5 bewusst fokussiert ist. Es ersetzt Claude Opus 4.7 oder GPT-5.5 nicht als allgemeines Modell und hilft dir nicht, wenn du eine API außerhalb von Cursor brauchst. Innerhalb von Cursor ist diese Fokussierung jedoch der Punkt: Das Modell ist günstiger zu betreiben als die Spitzenoptionen, es ist auf Coding-Aufgaben abgestimmt und sitzt nahe an der Produktebene, wo diese Aufgaben stattfinden.

Die nächste Frage ist, wie viel davon Cursor künftig selbst besitzen will. Das Unternehmen arbeitet nach eigenen Angaben mit SpaceXAI daran, ein größeres Modell von Grund auf zu trainieren – mit dem Zehnfachen an Gesamtcompute und Colossus-2-Infrastruktur. Ein Releasedatum gibt es nicht, also gibt es noch wenig zu analysieren. Die Richtung ist dennoch klar: Cursor bewegt sich vom guten Einsatz bestehender Modelle hin dazu, mehr vom eigenen Modell-Stack selbst zu bauen.