CursorBench 3.1: Ergebnisse der Modellbewertung

 (cursor.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • In Cursors Bewertungsübersicht für Coding-Modelle belegt Fable 5 Max mit 72,9 % den ersten Platz und setzt damit den Maßstab für den Wettbewerb an der Spitze
  • Die Fable-5-Reihe belegt mit Max, Extra High, High und Medium die Plätze 1 bis 4 und zeigt einen deutlichen Abstand zu anderen Modellfamilien
  • Danach folgen in den Top 10 Opus 4.7 Max mit 64,8 %, GPT-5.5 Extra High mit 64,3 %, Fable 5 Low mit 64,2 %, Opus 4.8 Max mit 63,8 % sowie Composer 2.5 mit 63,2 %
  • CursorBench 3.1 ergänzt Aufgaben rund um Codebase-Verständnis, Bug-Finding, Planung und Code Reviews und verbessert die Bewertungskriterien für einige Editieraufgaben
  • Die durchschnittlichen Kosten pro Aufgabe werden anhand der veröffentlichten Token-Preise und der pro Aufgabe verwendeten Tokens berechnet; kleine Punktunterschiede sind möglicherweise statistisch nicht signifikant

Spitzenfeld wird von Fable 5 dominiert

  • Die Tabelle von CursorBench 3.1 vergleicht Rang, Score, durchschnittliche Kosten pro Aufgabe und nutzungsbezogene Kennzahlen je Modell
  • Die Plätze 1 bis 4 gehen alle an die Fable-5-Reihe
    • Fable 5 Max: 72,9 %, $18.02, 63.842, 76
    • Fable 5 Extra High: 72,0 %, $13.74, 48.754, 63
    • Fable 5 High: 70,6 %, $10.81, 37.173, 54
    • Fable 5 Medium: 69,8 %, $8.27, 28.507, 47
  • Auf den Plätzen 5 bis 10 mischen sich Modelle von Opus, GPT-5.5, Fable und Composer
    • Opus 4.7 Max: 64,8 %, $11.02, 62.989, 96
    • GPT-5.5 Extra High: 64,3 %, $4.37, 17.905, 46
    • Fable 5 Low: 64,2 %, $5.70, 18.882, 36
    • Opus 4.8 Max: 63,8 %, $7.59, 77.370, 60
    • Composer 2.5: 63,2 %, $0.55, 15.152, 37
    • GPT-5.5 High: 62,6 %, $3.59, 13.329, 40

Scores der Modelle im mittleren und unteren Feld

  • Die Plätze 11 bis 20 werden vor allem von Opus-, Sonnet- und GPT-5.5-Modellen belegt
    • Opus 4.8 Extra High: 62,1 %, $6.14, 55.622, 54
    • Opus 4.7 Extra High: 61,6 %, $7.11, 43.942, 72
    • Sonnet 5 Max: 61,2 %, $6.87, 93.485, 93
    • Opus 4.7 High: 59,4 %, $5.01, 32.227, 59
    • GPT-5.5 Medium: 59,2 %, $2.22, 9.065, 35
    • Opus 4.8 High: 58,4 %, $4.41, 36.788, 45
    • Sonnet 5 Extra High: 58,4 %, $5.23, 58.228, 86
    • Sonnet 5 High: 57,0 %, $3.74, 41.735, 66
    • Opus 4.8 Medium: 56,6 %, $3.83, 31.684, 41
    • Sonnet 5 Medium: 54,9 %, $2.57, 27.469, 53
  • Auf den Plätzen 21 bis 36 finden sich unter anderem GLM, Kimi, Gemini, Sonnet und Composer
    • GLM 5.2 Max: 54,6 %, $3.11, 51.312, 83
    • Opus 4.8 Low: 54,3 %, $2.93, 22.726, 36
    • Opus 4.7 Medium: 52,7 %, $2.93, 19.193, 41
    • Kimi K2.7 Code: 52,7 %, $1.92, 32.902, 70
    • Composer 2: 52,2 %, $0.56, 14.163, 40
    • GLM 5.2 High: 50,7 %, $2.46, 30.621, 76
    • Gemini 3.5 Flash: 49,8 %, $1.94, 35.105, 79
    • Sonnet 4.6 Max: 49,0 %, $3.09, 40.280, 55
    • GPT-5.5 Low: 48,8 %, $1.19, 4.923, 24
    • Sonnet 4.6 High: 48,8 %, $3.06, 37.352, 57
    • Opus 4.7 Low: 48,3 %, $1.87, 13.164, 29
    • Sonnet 5 Low: 47,7 %, $1.46, 17.028, 37
    • Kimi 2.6: 47,6 %, $1.27, 24.783, 56
    • Sonnet 4.6 Medium: 46,0 %, $2.64, 31.360, 50
    • Sonnet 4.6 Low: 41,5 %, $1.89, 21.211, 50
    • Kimi 2.5: 31,9 %, $0.87, 9.446, 30

Bewertungsumfang von CursorBench 3.1

  • CursorBench 3.1 führt Aufgaben ein, die auf Codebase-Verständnis, Bug-Finding, Planung und Code Reviews ausgerichtet sind
  • Auch die Bewertungskriterien für einige Editieraufgaben wurden verbessert
  • CursorBench 3.0 war ein früher Aufgabensatz mit Fokus auf Editieren, Refactoring und Bugfixes

Kostenberechnung und Einschränkungen bei der Interpretation

  • Die durchschnittlichen Kosten pro Aufgabe werden anhand der veröffentlichten Preise pro Million Tokens des jeweiligen Modells berechnet
  • Eingabe-, Cache-Read-, Cache-Write- und Ausgabe-Preise sind alle einbezogen
  • Die Preise werden auf die Tokens angewendet, die jedes Modell bei den Aufgaben von CursorBench 3.1 verwendet hat; anschließend wird der Durchschnitt über alle Aufgaben gebildet
  • In den Ergebnissen bleibt Variabilität bestehen, und kleine Score-Unterschiede sind möglicherweise statistisch nicht signifikant

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Ich bin etwas skeptisch.
    In Cursors Benchmark schneidet das Cursor-Modell Composer 2.5 so gut ab wie Opus 4.8 max und GPT-5.5 xhigh, kostet aber deutlich weniger.
    In den Tests von Artificial Analysis liegt Composer 2.5 jedoch ziemlich weit zurück: https://artificialanalysis.ai/agents/coding-agents
    Im DeepSWE-Benchmark kommt GPT-5.5 xhigh auf 64, Opus 4.8 max auf 56 und Cursor 2.5 auf 16.
    Ich bezweifle nicht, dass Cursor für manche gut passen kann, aber die Behauptung, es sei ein Konkurrent zu Opus 4.8 oder GPT-5.5, wirkt fragwürdig. Es erscheint allzu bequem, dass es in den eigenen Benchmarks gut aussieht und in Benchmarks Dritter deutlich zurückliegt.

    • Ich arbeite bei Cursor. Als Composer 2.5 veröffentlicht wurde, war es im Gesamtbenchmark von AA ziemlich konkurrenzfähig; soweit ich mich erinnere, lag es insgesamt auf Platz 3.
      Kürzlich hat AA auf DeepSWE umgestellt, und dieser Benchmark konzentriert sich stärker auf Aufgaben mit sehr langem Zeithorizont. Composer ist bei solchen Aufgaben noch nicht stark, und wir arbeiten daran, das im nächsten Modell zu verbessern.
      Insgesamt schneidet Composer in manchen Benchmarks gut ab, in anderen nicht. Trotzdem halte ich es in der aktuellen Preisklasse für ein sehr leistungsfähiges Modell. Wenn ihr bestimmte Verhaltensweisen oder Schwachstellen seht, könnt ihr sie hier melden oder eine Mail an lrobinson at cursor.com schicken.
    • Es ist nicht schwer zu verstehen, was da passiert. Wenn man Reinforcement Learning auf Muster und bestimmte Fähigkeiten in den eigenen Daten ausrichtet, baut man natürlich am Ende einen Benchmark, der zum Trainingsset passt.
      Ironischerweise könnte dieser Benchmark in dem engen Bereich, der Cursors „eigene Kunden“ wirklich interessiert, genauer sein als Artificial Analysis. Für alles andere ist er einfach ein weiterer Datenpunkt.
    • DeepSWE ist insofern etwas fehlerhaft, als es nur sein eigenes Execution Harness verwendet, was bei Modellen Probleme verursacht, die von diesem Harness nicht richtig unterstützt werden.
      Es gibt viele Hinweise darauf, dass das Harness einen großen Einfluss darauf hat, wie diese Modelle funktionieren, und DeepSWE eliminiert diesen Faktor vollständig. Wahrscheinlich haben sie nur geprüft, ob es mit einigen von ihnen bevorzugten Modellen gut funktioniert.
      Wie auch in GitHub-Issues berichtet wurde, gibt es bei der Kostenberechnung ebenfalls Probleme, weil das Harness kein Caching nutzt. Kein Benchmark ist perfekt, aber das erklärt einen guten Teil der Abweichungen zwischen Benchmarks.
    • Cursor-Sessions entsprechen ziemlich genau dem, worauf das Composer-Modell per Reinforcement Learning trainiert wird. Dieser Benchmark und die Trainingsdaten sollten faktisch aus derselben Verteilung stammen.
    • Zu Benchmarks kann ich nicht viel sagen, aber ich habe Composer 2.5 intensiv genutzt, und in echter Arbeit hat es ziemlich gut funktioniert.

  • Die Wahl der Achsen ist ziemlich verwirrend. Ich dachte, links wäre die günstigste Seite, dabei ist es genau die teuerste.
    Ich verstehe die Anordnung, bei der oben rechts das Beste sein soll, aber dass die Kostenachse umgekehrt ist, bleibt unintuitiv.
    Davon abgesehen mache ich täglich den ganzen Tag extrem schwierige Implementierungen, die Agenten gerade so schaffen können, und für Aufgaben, die „echte Verifikation“ brauchen, musste ich Opus eine Zeit lang auf max lassen. Das fühlte sich praktisch wie die einzige Möglichkeit an, Opus auch nur annähernd auf das Niveau von GPT-5.5 xhigh zu bringen.
    Wenn man GPT-5.5 per Abo nutzt, ist das Kontextfenster klein; es sind zwar 400k, effektiv aber eher etwa 258k, deshalb nutze ich Opus.
    Der Unterschied ist, dass GPT-5.5 xhigh in den meisten realen Fällen sehr schnell ist. Auch die vollständige Implementierung ist effizient, und bei Fragen, die kein tiefes Nachdenken erfordern, antwortet es adaptiv schnell.
    Opus 4.8 Max hingegen kaut unnötig lange auf allem herum, und selbst einfache Implementierungen können Stunden dauern, sodass ich es hauptsächlich für Planung und Reviews nutze.
    Fable ist bei adaptivem Denken und schnellen Antworten viel besser, aber vermutlich immer noch schlechter als GPT-5.5 xhigh. Ich glaube, die Stärken und Schwächen wurden ausreichend benannt, und leider ist es bei meinen schwierigen Aufgaben noch kein verlässlicher Implementierer. Das ist weiterhin GPT-Territorium, und Fable neigt dazu, große, gefährliche Lücken in der Implementierung zu hinterlassen, wenn man es nicht sorgfältig betreut.

    • Gibt es irgendetwas Belegbares an der Aussage „ich mache täglich den ganzen Tag extrem schwierige Implementierungen, die Agenten gerade so schaffen können“? Oder sollen wir das einfach glauben? Das klingt alles lächerlich subjektiv.
    • Wenn Fable gefährliche Lücken in Implementierungen hinterlässt, könnte man GLM oder DeepSeek als Code-Red-Teaming-Komponente dazumischen und integrieren.
      Fable ist vom Design her sicherheitsblind[0], während offene Modelle darin ziemlich gut sind.
      [0] Es ist unklar, wie GPT-5.6 aussehen wird, aber dem Blog zufolge dürfte es ähnlich übervorsichtige Safety-Filter enthalten.
      Interessant ist, dass die jüngsten Opus-Release-Posts damit prahlen, Sicherheitsfähigkeiten absichtlich reduziert zu haben: „during its [Opus 4.7] training we experimented with efforts to differentially reduce these ["cyber"] capabilities“
    • Das ist Gartner-Stil. Oben rechts ist der Platz, an dem man stehen will.
    • Ich stimme zu, dass die x-Achse umgedreht ist. Dadurch wird diese Grafik für normale Betrachter sehr schwer verständlich.
    • Ich frage mich, ob du in der Praxis wirklich das Gefühl hast, dass „bei GPT-5.5 im Abo das Kontextfenster klein ist“ einen Unterschied macht.
      Ich nutze 5.5 high/xhigh, um eine C-Codebasis zu optimieren und zu benchmarken, und schon das Einlesen des anfänglichen Codes füllt das erste Kontextfenster fast vollständig.
      Die Session wird etwa 5- bis 15-mal automatisch komprimiert, aber die Arbeit konzentriert sich jedes Mal hauptsächlich auf das neueste Fenster, daher kommt es einigermaßen gut zurecht.
      Beim Programmieren scheinen GPTs Stärken gegenüber Opus groß genug zu sein, um den Unterschied beim Kontextfenster aufzuwiegen.

  • Dass Composer 2.5 so gut sein soll, fällt mir schwer zu glauben. Ich habe ihn mit GLM 5.2 und Opus 4.6 verglichen, und ihm fehlten die Denktiefe und das kritische Schlussfolgern bei Problemen.
    Er ist gut darin, Pläne auszuführen, die andere Modelle erstellt haben, aber selbst dann nimmt er oft seltsame Code-Manipulationen vor, die weit davon entfernt sind, wie die umliegenden Dateien tatsächlich funktionieren.

    • Ich nutze Cursor derzeit nicht, aber als ich es vor Kurzem verwendet habe, war meine Erfahrung ähnlich. Ich habe mit Opus geplant, mit Composer implementiert und mit Opus aufgeräumt.
      Composer ist kompetent, wenn ein guter Plan vorliegt, aber nicht auf erstaunlichem Niveau. Was mir dennoch wirklich gefiel, war die Geschwindigkeit.
      Was Opus 30 Minuten kostet, erledigte Composer in 5–10 Minuten. Natürlich war das Ergebnis nicht perfekt, daher ging es anschließend noch durch eine Aufräumphase mit Opus oder Codex.
      Am Ende ist es eine Frage der Balance, sie verändert sich ständig und hängt vollständig vom Problem ab, das man gerade löst. Ich bleibe flexibel und passe mich dem Prozess an, der in dem Moment am besten funktioniert.
    • Wenn ich so etwas sehe, denke ich einfach an eine zerklüftete Grenze. Ich zweifle persönliche Erfahrungen nicht an. Letzten Monat habe ich Composer 2.5 mit Grok und Credits aus einem X-Premium-Konto ausprobiert.
      Ich baue keine Raketen, aber es war ziemlich beeindruckend. Alle Modelle machen gelegentlich dumme Dinge, aber die Aufgaben, um die ich gebeten habe, hat es ziemlich gut erledigt und auch beeindruckende Ergebnisse geliefert.
      In Grok ist es schnell, und verglichen mit anderen Modellen, die ich viel genutzt habe, halte ich es für besser als gemini 3.1. Nach meinen Maßstäben waren 3.5 und antigravity schlechter als die frühere gemini cli. Mit Opus 4.6 ist es vergleichbar. Die neueren Modelle in Claude Code habe ich noch nicht ausprobiert.

  • Wenn ich die Grafik richtig verstehe, verwendet Fable im Vergleich zu sonet und opus weniger Tokens, um dieselbe Aufgabe zu erledigen. Wenn ja, ist das eine gute Sache.
    Eine Zeit lang fühlte es sich so an, als würden Modelle einfach Tokens herauswerfen, um bessere Ergebnisse zu erzielen; wenn das Modell selbst besser wird, ohne mehr Tokens zu erzeugen, fühlt sich das nach einem echten Fortschritt an.
    Frage 1: Warum ist in dieser Grafik die Anzahl der Schritte wichtig? Was sagt sie aus?
    Frage 2: Warum wurde die horizontale Achse umgedreht, sodass 0 nicht am Ursprung, sondern rechts liegt? Ist das eine neue, clevere Methode? Ich glaube, so etwas bisher noch nicht gesehen zu haben.

  • Interessant, dass Opus 4.7 besser abschneidet als 4.8. Es wäre schön gewesen, wenn auch 4.6 getestet worden wäre. Gestern habe ich hier jemanden gesehen, der ausgelacht wurde, weil er darauf bestand, dass 4.6 besser sei als die Nachfolgemodelle.
    Allerdings sind Benchmarks immer trickreich. In DeepSWE schlägt GPT-5.5 Opus-4.8 mit recht deutlichem Abstand, aber in FrontierCode ist es umgekehrt.
    Der einzig verlässliche Benchmark ist die eigene reale Workload.

  • Jedes Mal, wenn ein neuer Benchmark erscheint, schneiden chinesische Modelle deutlich schlechter ab, als man nach den bestehenden Benchmarks erwarten würde, und mit der Zeit erholen sie sich wieder.

    • Die Magie der Destillation.

  • Ich wünschte, all diese Websites würden Diagramme zur Kosten/Leistungs-Pareto-Frontier zeigen. Wichtig sind meist diese beiden Dinge. Man könnte noch einen Geschwindigkeitsparameter hinzufügen und daraus etwas Dreidimensionales machen.
    https://paraplouis.github.io/llm-pareto-frontier/ ist die beste Grafik, die ich bisher gesehen habe, wird aber nicht so oft aktualisiert, wie ich es mir wünschen würde.

    • Diese Seite ist nicht besonders nützlich, weil Thinking-Tokens, Caching und deren Effizienz nicht berücksichtigt werden.
      GLM5.2 wird im Internet von sämtlichen Wumao beworben, die die PLA mobilisieren kann, aber seine Denkprozesse sind übermäßig weitschweifig und legen die Schwächen offen.
      Anthropic-Modelle haben dasselbe Problem, starten aber von einer deutlich höheren tatsächlichen Intelligenzbasis.
      Genau deshalb zeigen verlässliche Vergleiche inzwischen nicht mehr willkürliche Kosten für Eingabe-/Ausgabe-Tokens, sondern die Gesamtkosten, die für die Erledigung einer Aufgabe anfallen.

  • Ich habe Composer 2.5 und GPT 5.5 ausgiebig sowohl in Cursor als auch in Codex genutzt, und die Behauptung, die Leistung von Composer 2.5 liege nahe an GPT 5.5, ist völlig absurd.
    Er ist zwar schneller, aber die Qualität ist bei Weitem nicht auf diesem Niveau.
    Außerdem kann man Composer nur mit einem monatlichen Cursor-Abo nutzen, daher ist auch der Kostenvergleich sinnlos. Mit einem OpenAI-Abo zu einem ähnlichen Preis kann man ein besseres Modell entsprechend viel nutzen.

  • Der interessanteste Teil sind die Kosten. GPT 5.5 und sonnet 5 kosten so viel wie GLM 5.2, sind aber leistungsfähigere Modelle.

  • Ein Cursor-Modell schneidet in einem Cursor-Benchmark hervorragend ab – Stoff für die 11-Uhr-Nachrichten.
    Allerdings liegen alle anderen Modelle nach meiner eigenen Nutzungserfahrung ziemlich plausibel dort, wo ich sie erwartet hätte.
    Fable kostet das Zehnfache, übertrifft die anderen Modelle aber in den meisten Fällen deutlich. Manchmal geht es jedoch nicht um die Wahl zwischen billig und teuer, sondern zwischen teuer, aber möglich, und überhaupt nicht möglich. Wie bei den anderen Modellen muss man lernen, wo diese Grenze verläuft.