Cursor hat am 18. Mai 2026 mit Composer 2.5 sein hauseigenes Coding-Modell der dritten Generation veroeffentlicht — und macht damit ein lautes Versprechen: Frontier-Performance zu einem Bruchteil des Preises. Wir haben Benchmarks, Preise und die Praxis-Tauglichkeit fuer deutsche Entwickler-Teams eingeordnet — inklusive der unbequemen Fragen.
Spoiler: Auf dem wichtigsten externen Coding-Benchmark ist Composer 2.5 fast gleichauf mit Claude Opus 4.7 — kostet aber nur einen Bruchteil. Der Haken steckt nicht im Preis, sondern darin, wo du das Modell ueberhaupt einsetzen darfst.
Die Eckdaten auf einen Blick
| Spec | Cursor Composer 2.5 |
|---|---|
| Release | 18. Mai 2026 |
| Generation | 3. Cursor-eigener Coding-Agent |
| Basismodell | Moonshot AI Kimi K2.5 (Open-Weight) |
| Input-Preis (Standard) | 0,50 USD / 1M Token |
| Output-Preis (Standard) | 2,50 USD / 1M Token |
| Schnelle Variante | 3,00 USD / 15,00 USD |
| SWE-Bench Multilingual | 79,8 % |
| Verfuegbarkeit | Nur Cursor-IDE + @cursor/sdk |
Drei Dinge fallen sofort auf:
- Der Preis ist aggressiv. 0,50 USD Input ist ein Niveau, das man bisher nur von Billig-Modellen fuer Klassifikations-Jobs kannte — nicht von einem Coding-Agenten, der mit Opus mithaelt.
- Die Basis kommt aus China. Cursor hat nicht von Null trainiert, sondern Moonshot AIs Kimi K2.5 als Open-Weight-Fundament genommen und darauf fein-getunt.
- Es ist kein offenes API-Produkt. Composer 2.5 laeuft ausschliesslich in der Cursor-IDE und ueber das
@cursor/sdk— du kannst es nicht einfach in dein bestehendes Backend stecken.
Wie gut ist Composer 2.5 wirklich?
Der entscheidende Wert ist SWE-Bench Multilingual — der breit akzeptierte externe Standard fuer das Loesen echter GitHub-Issues ueber mehrere Programmiersprachen hinweg. Hier zaehlt nicht ein synthetischer Test, sondern: Bekommt das Modell einen realen Bug-Report und schliesst er ihn mit einem funktionierenden Patch?
| Modell | SWE-Bench Multilingual |
|---|---|
| Claude Opus 4.7 | 80,5 % |
| Cursor Composer 2.5 | 79,8 % |
Ein Abstand von 0,7 Prozentpunkten ist innerhalb der Messtoleranz — praktisch ein Gleichstand. Bei Terminal-Tasks (kompilieren, testen, deployen im echten Shell-Kontext) liegt Composer 2.5 ebenfalls auf Augenhoehe mit Opus.
Praxis-Einordnung: Wenn dein Workflow aus “Issue rein, Patch raus” besteht — also klassisches Bug-Fixing und Feature-Arbeit in einer bestehenden Codebase —, bekommst du mit Composer 2.5 Opus-nahe Ergebnisse zu einem Sechstel bis Zehntel der Token-Kosten. Das ist der Use-Case, fuer den das Modell gebaut wurde.
Der eigentliche Clou: Daten aus Millionen Sessions
Das technisch Spannende ist die Trainings-Strategie. Cursor hat nicht versucht, ein eigenes Frontier-Modell aus dem Nichts zu stemmen — das koennen sich nur OpenAI, Google und Anthropic leisten. Stattdessen:
- Start mit Kimi K2.5 — einem starken, frei verfuegbaren Open-Weight-Modell von Moonshot AI.
- Massives Fine-Tuning mit Daten, die in Echtzeit aus den Millionen Entwickler-Sessions stammen, die taeglich durch den Cursor-Editor laufen.
Das ist ein cleverer Hebel: Cursor besitzt einen Datenschatz, den kein reines Modell-Labor hat — naemlich echte Akzeptanz-Signale. Welcher Vorschlag wurde uebernommen? Welcher Patch hat den Test gruen gemacht? Welche Aenderung wurde sofort wieder rueckgaengig gemacht? Genau dieses Feedback fliesst ins Fine-Tuning.
Wer verstehen will, warum offene Basismodelle gerade so wichtig werden, findet im Hintergrund-Artikel zu Open Source KI die groessere Bewegung dahinter.
Was DACH-Teams jetzt rechnen sollten
Drei konkrete Szenarien, in denen Composer 2.5 die Kalkulation veraendert:
1. Hochfrequentes Bug-Fixing
Teams, die taeglich dutzende kleine Issues abarbeiten, zahlen bei einem Frontier-Flagship schnell drei- bis vierstellig pro Monat. Mit Composer 2.5 sinken die reinen Token-Kosten drastisch — bei nahezu identischer Erfolgsquote auf Standard-Issues.
2. Iterations-lastige Entwicklung
Beim “Vibe Coding” — vielen schnellen Durchlaeufen, in denen du Vorschlaege annimmst, verwirfst und nachschaerfst — summieren sich die Tokens. Genau hier zahlt sich der Preisvorteil am staerksten aus, weil die Anzahl der Calls hoch ist.
3. Onboarding und Boilerplate
Routinearbeit wie Test-Gerueste schreiben, Typen ableiten, Doc-Strings ergaenzen oder Refactorings nach Schema F braucht keine teure Reasoning-Maschine. Composer 2.5 erledigt das schnell und guenstig.
Die unbequemen Fragen
Drei Punkte, die kein Marketing-Deck erwaehnt — und die du vor einer Umstellung kennen solltest:
1. Vendor-Lock-in ist hier real. Composer 2.5 gibt es nur in der Cursor-IDE und ueber das @cursor/sdk. Du kannst das Modell nicht in deine eigene Pipeline, deinen CI-Runner oder ein anderes Tool ziehen. Wer eine offene API braucht, schaut eher Richtung DeepSeek V4 oder die etablierten Anbieter.
2. Die China-Basis ist ein Governance-Thema. Kimi K2.5 als Open-Weight-Fundament ist technisch keine Schwaeche — das Fine-Tuning und Hosting laeuft bei Cursor. Aber in regulierten Branchen oder bei oeffentlichen Auftraggebern willst du die Herkunfts- und Verarbeitungskette sauber dokumentieren koennen. Der AI Act Readiness Check im AEGIS-Hub hilft dir einzuordnen, welche Nachweispflichten fuer dein KI-gestuetztes Entwicklungs-Setup gelten.
3. Maximale Code-Qualitaet bleibt woanders. Die 0,7 Punkte Abstand auf SWE-Bench klingen winzig — aber in produktionskritischem Code (Zahlungsverkehr, Sicherheit, Medizintechnik) ist die letzte Meile entscheidend. Hier bleibt Claude Opus 4.7 die sicherere Wahl, auch wenn es teurer ist.
Composer 2.5 vs. die Alternativen — die Entscheidungshilfe
| Wenn du… | dann nimm… |
|---|---|
| viele Standard-Issues guenstig abarbeiten willst | Composer 2.5 |
| produktionskritischen Code mit maximaler Qualitaet brauchst | Claude Opus 4.7 |
| eine offene API fuer dein eigenes Backend brauchst | DeepSeek V4 / Gemini 3.5 Flash |
| schon im Cursor-Oekosystem lebst und Kosten senken willst | Composer 2.5 |
| Coding-Agenten ausserhalb der IDE orchestrierst | Claude Code / OpenAI Codex |
Wer ohnehin zwischen den IDEs vergleicht, findet im Beitrag Cursor vs GitHub Copilot die grundsaetzliche Editor-Entscheidung — Composer 2.5 verschiebt diese Rechnung jetzt klar zugunsten von Cursor, sobald Token-Kosten ein Thema sind.
Fazit: Der Preis-Hammer mit einem Sternchen
Composer 2.5 ist die bisher beste Antwort auf die Frage “Wie kriege ich Frontier-nahe Coding-Qualitaet, ohne ein Vermoegen fuer Tokens auszugeben?”. Fuer den Grossteil der taeglichen Entwicklungsarbeit — Bugs fixen, Features bauen, refactoren — ist es ab sofort eine sehr ernsthafte Standard-Option.
Das Sternchen: Du kaufst dir den Preisvorteil mit Bindung an das Cursor-Oekosystem und solltest die Herkunftskette sauber dokumentieren. Wer damit leben kann, bekommt eines der besten Preis-Leistungs-Verhaeltnisse, die der Coding-Markt 2026 zu bieten hat.
