Cursor Composer und SWE‑1.5 Review – Warum ein 10‑Milliarden‑Dollar‑Unternehmen ein minderwertiges Modell herausbrachte
Cursor Composer und SWE‑1.5 Review – Warum ein 10‑Milliarden‑Dollar‑Unternehmen ein minderwertiges Modell herausbrachte
Einführung
Der Markt für KI‑Coding‑Assistenten heizt sich auf, und diese Woche stellten zwei Schwergewichte – Cursor und Windsurf – neue Modelle vor: Cursor Composer und SWE‑1.5. Beide behaupten ultra‑niedrige Latenz für „agentisches“ Coden, doch die zugrunde liegende Technologie und die Leistung werfen ernsthafte Fragen auf. Dieser Artikel zerlegt die behaupteten Fähigkeiten der Modelle, die Testmethodik und erklärt, warum die Ergebnisse selbst die nachsichtigsten Nutzer enttäuschen könnten.
Hintergrund zu den neuen Modellen
Cursor Composer
- Als „Frontier“-Modell vermarktet, das viermal schneller sein soll als vergleichbare LLMs.
- Entwickelt für Low‑Latency‑, Mehrschritt‑Coding‑Aufgaben, wobei die meisten Durchläufe in unter 30 Sekunden abgeschlossen werden.
- Auf einer nicht offengelegten „Open‑Weights“-Basis gebaut, angeblich basierend auf einem 4,6‑Klassen‑Modell.
- Es wurden keine öffentlichen Benchmark‑Ergebnisse veröffentlicht, was eine unabhängige Verifizierung erschwert.
SWE‑1.5 (Windsurf)
- Als das schnellere der beiden Modelle beworben, das bis zu 950 Token pro Sekunde auf Cerebras‑Hardware liefert.
- Auf einer nicht genannten Open‑Source‑Basis mit proprietären Reinforcement‑Learning‑Daten trainiert.
- Positioniert als hoch‑durchsatzfähige Alternative für die Code‑Generierung.
Testmethodik
Die Bewertung erfolgte mit den offiziellen CLI‑Tools, die von jedem Anbieter bereitgestellt werden:
- Cursor Composer – über die Cursor‑CLI aufgerufen (die Editor‑UI zeigte nur das ältere Cheetah‑Modell).
- SWE‑1.5 – über den Windsurf‑Editor zugänglich.
Beide Modelle wurden mit einer Suite repräsentativer Coding‑Challenges betraut, von einfachen Taschenrechnern bis hin zu komplexeren Web‑App‑Prototypen. Für jede Aufgabe wurden Ausführungszeit, Korrektheit und Fehlerraten aufgezeichnet.
Leistungsübersicht
Cursor Composer
- Movie‑Tracker‑App – zahlreiche UI‑Fehler; die Discover‑Ansicht war kaputt.
- Goatee UI‑Rechner – funktionierte korrekt und zeigte, dass das Modell einfache Logik bewältigen kann.
- Godo‑Spiel – ließ sich nicht ausführen; moderne Modelle wie GLM‑4.5 und Miniax erledigen das problemlos.
- Open‑Code‑Großaufgabe – wurde nicht abgeschlossen.
- Spelt‑App – es erschien nur ein Login‑Screen; Backend‑Fehler waren allgegenwärtig.
- Tari Rust Image‑Cropper – nicht funktionsfähig.
- Gesamtplatzierung: 11. auf der internen Rangliste, hinter Modellen wie Kilo, Miniax und GLM‑4.5.
SWE‑1.5
- Platz 19 auf derselben Rangliste.
- Konnte eine Rechner‑UI erzeugen, führte jedoch keine Berechnungen aus.
- Produzierte durchweg falschen oder unvollständigen Code in der gesamten Testsuite.
Warum die Ergebnisse wichtig sind
- Mangel an Transparenz – Beide Unternehmen verbergen das genaue Basismodell, das sie feinabgestimmt haben. Die Beschreibung deutet auf eine GLM‑4.5‑ oder Qwen‑3‑Coder‑Linie hin, aber konkrete Belege fehlen.
- Geschwindigkeit‑vs‑Qualität‑Trade‑off – Während SWE‑1.5 eine höhere Token‑pro‑Sekunde‑Durchsatzrate erreicht, ist die Ausgabequalität häufig unbrauchbar. Geschwindigkeit allein kompensiert keinen fehlerhaften Code.
- Fehlende Benchmarks – Ohne von der Community anerkannte Evaluierungen (z. B. HumanEval, MBPP) bleiben die Behauptungen einer „Frontier“-Performance unbelegt.
- Mögliche ethische Probleme – Das Bereitstellen eines feinabgestimmten Open‑Source‑Modells ohne Attribution kann gegen Community‑Normen und in manchen Rechtsgebieten gegen Lizenzbedingungen verstoßen.
Technische Analyse
- Modellauswahl – Das beobachtete Verhalten stimmt eher mit Qwen‑3‑Coder oder einem älteren GLM‑4.5‑Checkpoint überein als mit einem echten 4,6‑Klassen‑Modell. Das Fehlen fortgeschrittener Reasoning‑ und Tool‑Nutzung deutet auf eine unzureichende Pre‑Training‑Ausrichtung hin.
- Einfluss von Reinforcement Learning (RL) – Die modesten Gewinne durch RL‑Feinabstimmung werden durch die schlechte Wahl des Basismodells übertroffen. Eine richtige Ausrichtung bereits im Pre‑Training wäre nötig, um echte Verbesserungen zu sehen.
- Hardware‑Überlegungen – Beide Modelle laufen auf Hoch‑Durchsatz‑Hardware (Cerebras für SWE‑1.5, nicht spezifiziert für Cursor). Neuere Open‑Modelle (z. B. Miniax, GLM‑4.5) erreichen jedoch bereits vergleichbare oder bessere Geschwindigkeiten auf derselben Hardware, sodass der Geschwindigkeitsvorteil hinfällig wird.
Auswirkungen auf die Branche
- Transparenzlücke – Die Weigerung, das zugrunde liegende Modell offenzulegen, untergräbt das Vertrauen. Nutzer können nicht prüfen, ob das Produkt eine echte Innovation oder lediglich ein umbenannter Open‑Source‑Checkpoint ist.
- Opportunitätskosten – Unternehmen mit einer Marktkapitalisierung von 10 Milliarden $ könnten entweder dedizierte ML‑Teams einsetzen, um proprietäre Modelle zu entwickeln, oder zumindest das Basismodell, das sie feinabstimmen, offen nennen.
- Reaktion der Community – Das Fehlen von Kritik seitens der breiteren KI‑Community deutet auf eine wachsende Nachgiebigkeit gegenüber Modell‑Attribution hin.
Empfehlungen für Praktiker
- Bewährte Open‑Modelle priorisieren – Wenn Geschwindigkeit entscheidend ist, sollten etablierte Open‑Weights wie Miniax, GLM‑4.5 oder Mistral‑7B in Betracht gezogen und selbst feinabgestimmt werden.
- Vor der Integration validieren – Führen Sie eine kleine Benchmark‑Suite (z. B. Code‑Generierung, Tool‑Nutzung, Fehlermanagement) durch, bevor Sie ein neues Anbieter‑Modell einsetzen.
- Transparenz fordern – Bestehen Sie auf klarer Dokumentation des Basismodells, der Trainingsdaten und der Lizenzierung, um rechtliche und leistungsbezogene Fallstricke zu vermeiden.
Fazit
Sowohl Cursor Composer als auch SWE‑1.5 versprechen blitzschnelle Code‑Generierung, doch die Realität ist eine Sammlung von schnellen‑aber‑fehlerhaften Ausgaben. Die Modelle kämpfen mit Grundaufgaben, die ältere Open‑Source‑Checkpoints mühelos bewältigen, und der undurchsichtige Entwicklungsprozess wirft ethische Bedenken auf. Solange die Unternehmen ihre Grundlagen nicht offenlegen oder ein wirklich überlegenes Modell liefern, sind Entwickler besser beraten, bei gut dokumentierten, von der Community geprüften Alternativen zu bleiben.
Dieser Artikel stellt eine unabhängige technische Bewertung dar und befürwortet kein spezifisches Produkt.