Ähnliche KI-Benchmark-Werte verbergen große Unterschiede

Ähnliche KI-Benchmark-Werte können Modelle verbergen, die in einem echten Repository völlig anders arbeiten. Bei DeepSWE liegt Luna Max 2,2 Punkte hinter Sol High, doch Luna braucht fast dreimal so viele Agent-Schritte. Die Erfolgsrate allein sagt mir weder, wie viel Aufsicht ein Modell braucht, noch ob ich seinen Pull Request annehmen würde.

Was misst ein Benchmark-Wert von 67 % gegenüber 69 %?

Er misst den Erfolg pro Versuch in einem bestimmten DeepSWE-Aufbau. Sol High erreicht 69,4 % und liegt damit 2,2 Punkte vor Luna Max mit 67,2 %. Dieser Abstand ist jedoch kleiner als die Schwankung zwischen den Läufen in denselben Daten [2]. Das Ergebnis ist für mich ein Grund, beide Modelle zu testen, aber kein vollständiges Urteil über ihre Qualität.

Messwert	Luna Max	Sol High
Erfolg pro Versuch, %	67,2	69,4
95-%-Intervall zwischen Läufen	63,2–71,2 %	68,0–70,8 %
Gewertete Versuche	448	451
Aufgaben mit ≥1 Erfolg, %	90,3 (Bester Wert der Zeile)	86,7
Mittlere Kosten pro Versuch, $	0,61 (Bester Wert der Zeile)	3,47
Ausgabe-Token pro Versuch, Tsd.	73,4	28,5 (Bester Wert der Zeile)
Agent-Schritte pro Versuch	101,7	36,9 (Bester Wert der Zeile)

Datacurves Daten zu DeepSWE v1.1 enthalten 301 erfolgreiche Versuche von 448 für Luna Max und 313 von 451 für Sol High [1] [2]. Aus diesen Summen entstehen die Werte in Abbildung 1.

DeepSWE hält mehrere wichtige Variablen konstant. Die 113 Aufgaben stammen aus 91 Open-Source-Repositorys und decken TypeScript, Go, Python, JavaScript und Rust ab [1]. Sie wurden eigens für diese Evaluation geschrieben, statt aus alten GitHub-Issues übernommen zu werden. Jedes Modell nutzte außerdem mini-swe-agent mit demselben bash-Tool und demselben grundlegenden Prompt [5]. Ein frischer Container prüfte jeden Patch auf das verlangte Verhalten und auf Regressionen.

Diese Kontrollen machen den Vergleich nützlich, doch das Ergebnis bleibt unsicher. Datacurve gibt für Luna ein 95-%-Intervall von 63,2 % bis 71,2 % an, für Sol eines von 68,0 % bis 70,8 % [2]. Die Bereiche überschneiden sich. Der Abstand von 2,2 Punkten ist damit kleiner als die beobachtete Schwankung zwischen den Läufen. Datacurve veröffentlicht keinen statistischen Vergleich beider Modelle auf denselben Aufgaben, weshalb die Daten nicht belegen, dass sich Sols Vorsprung wiederholen lässt.

Die beiden Konfigurationen nutzen zudem unterschiedliche Effort-Stufen: max für Luna und high für Sol. Bei Datacurves empirischem Pass@4-Wert dreht sich die Rangfolge um. Dieser Messwert fragt, ob mindestens einer der aufgezeichneten Versuche eine Aufgabe gelöst hat. Luna deckt damit 90,3 % der 113 Aufgaben ab, Sol 86,7 % [2]. Beim Erfolg pro Versuch liegt Sol vorn, bei der Aufgabenabdeckung Luna. Die Messwerte beantworten unterschiedliche Fragen.

Jeder Wert in Abbildung 1 gehört zu den Aufgaben und zum Agent-Aufbau von DeepSWE. Mein eigenes Repository kann andere Stärken belohnen und andere Fehler aufdecken. Deshalb ist als Nächstes wichtig, wie die Modelle zu ihrem Ergebnis kommen.

Ähnliche Werte können fast dreimal so viele Agent-Schritte verbergen

Eine Erfolgsrate zeigt nicht, wie ein Modell zum Patch gelangt ist. Zwei ähnliche Werte können daher sehr unterschiedlich viel Arbeit bedeuten. Ich achte darauf, ob ein Modell die richtigen Dateien findet, das vorhandene Design beibehält, vor einer riskanten Annahme nachfragt, sich nach einem fehlgeschlagenen Befehl fängt und nach der gewünschten Änderung aufhört. DeepSWE bewertet diese Verhaltensweisen nicht einzeln.

Die Rohdaten von DeepSWE geben jedoch einen Hinweis. Luna Max brauchte im Mittel 101,7 Agent-Schritte und 73.400 Ausgabe-Token pro Versuch, Sol High dagegen 36,9 Schritte und 28.450 Token [2]. Luna nutzte somit etwa 2,8-mal so viele Schritte und 2,6-mal so viele Ausgabe-Token, um eine ähnliche Erfolgsrate zu erreichen. Die Modelle arbeiteten nicht auf dieselbe Weise.

Auch der angezeigte Preis braucht Kontext. Lunas Versuche liefen am 7. Juli 2026, als die aufgezeichnete Token-Nutzung etwa 3,03 Dollar pro Versuch kostete [2] [3]. OpenAI senkte Lunas Token-Preise am 30. Juli 2026 um 80 % [4]. Daraufhin berechnete DeepSWE den alten Verbrauch zum neuen Tarif neu. So wurden aus 3,03 Dollar die angezeigten 0,61 Dollar. Der niedrigere Wert ist eine gültige Schätzung der heutigen Kosten für dieselbe Nutzung, aber nicht der Betrag, den Datacurve beim Test zahlte.

API-Kosten pro Versuch unterscheiden sich außerdem von den Kosten bis zu einem akzeptierten Patch. Der Leaderboard-Preis enthält keine Wiederholungen, Review-Zeit, manuellen Korrekturen oder Wartezeit. Auch ein zweites Modell, das die Arbeit des ersten kontrolliert oder repariert, fehlt. Ein Versuch kann nur ein Sechstel kosten und insgesamt dennoch teurer sein, wenn ein Entwickler jede Entscheidung beaufsichtigen muss.

Entwickler nennen solche Unterschiede manchmal „big model smell“: das Gefühl, dass ein stärkeres Modell die Aufgabe mit weniger Erklärung versteht und weniger Entscheidungen trifft, die später rückgängig gemacht werden müssen. Der Ausdruck ist informell, aber die Erfahrung dahinter lässt sich messen. Ich kann zählen, wie oft ich das Modell neu ausrichte, seine Arbeit repariere oder einen Patch ablehne, der die Tests bestanden hat.

Aus diesem Eindruck werden konkrete Fragen. Behielt das Modell alle Einschränkungen im Blick, traf es sinnvolle Entscheidungen für dieses Repository und vermied es unnötige Änderungen? War ein Fehler leicht zu erkennen und rückgängig zu machen? Eine einzelne Erfolgsrate kann diese Fragen nicht beantworten.

Wie stark kann der Benchmark-Aufbau den Wert verändern?

In den folgenden veröffentlichten Beispielen verschob allein der Benchmark-Aufbau die Werte um etwa 5 bis 15 Prozentpunkte, ohne das Modell zu ändern [6] [7]. Das ist mehr als der Abstand von 2,2 Punkten zwischen Luna und Sol. Ein Coding-Benchmark misst neben dem Modell auch Prompt, Tools, Laufzeitgrenzen, Zahl der Versuche und Grader.

Das NeurIPS-Paper zu SWE-agent liefert ein klares Beispiel. Mit demselben GPT-4 Turbo auf SWE-bench Lite löste eine reine Shell-Oberfläche 11 % der Aufgaben, die vollständige SWE-agent-Oberfläche dagegen 18 % [6]. Als die Forschenden wiederholte Suchausgaben durch ein Tool ersetzten, das die Ergebnisse zusammenfasste, stieg der Wert von 12 % auf 18 %. Ein Dateibetrachter mit 100 Zeilen statt der gesamten Datei erhöhte ihn von 12,7 % auf 18 %. Diese Änderungen an der Oberfläche brachten fünf bis sieben Prozentpunkte, ohne das Modell zu wechseln.

Die Zahl der Versuche verändert das Ergebnis noch stärker. Sechs Läufe derselben Kombination aus GPT-4 und SWE-agent erreichten beim ersten Versuch im Mittel 17,94 %. Galt eine Aufgabe als gelöst, sobald einer von sechs Versuchen bestand, stieg die Abdeckung auf 32,67 % [6]. Dieser Gewinn von 14,73 Punkten ist nützlich, wenn ein produktives System tatsächlich sechs Kandidaten erzeugt und den richtigen erkennen kann. Neben einem einmaligen Versuch ist der Wert ohne klare Kennzeichnung jedoch irreführend.

Auch die Infrastruktur kann Rauschen verursachen. Anthropic ließ das Claude-Modell, den Harness und die Terminal-Bench-2.0-Aufgaben unverändert und passte nur die Grenzen für CPU, Arbeitsspeicher und Laufzeit an. Ohne die strengen Limits lag das Ergebnis etwa sechs Prozentpunkte höher, während Infrastrukturfehler von 5,8 % auf 0,5 % sanken [7]. Deshalb sollte ein Leaderboard-Eintrag als Ergebnis des geprüften Systems gelten, nicht als fester Wert am Modellnamen.

Die vier folgenden Änderungen bewegten die Werte jeweils stärker als der Abstand zwischen Luna und Sol.

Systemänderung	Vorher	Nachher	Änderung
Nur Shell → SWE-agent-Oberfläche	11,0 %	18,0 %	+7,0 PP
Ganze Datei → 100-Zeilen-Ansicht	12,7 %	18,0 %	+5,3 PP
Ein → sechs Versuche	17,94 %	32,67 %	+14,73 PP
Strenge Limits → keine Limits	Nicht veröffentlicht	Nicht veröffentlicht	etwa +6 PP

Benchmarks werden dadurch nicht nutzlos, doch ihr Aufbau gehört zum Ergebnis. Bevor ich zwei Werte vergleiche, prüfe ich deshalb Aufgabenversion, Agent-Aufbau, Ressourcen, Zahl der Versuche und Bewertungsregel.

Warum kann ein bestandener Patch im Code-Review scheitern?

Besteht ein Patch den Benchmark, hat er dessen Prüfungen bestanden. Das ist ein nützlicher Hinweis auf funktionierenden Code, aber kein Code-Review. Die Prüfungen können einen unvollständigen Fix übersehen und berücksichtigen womöglich weder Wartbarkeit noch die vorhandene Architektur, unnötige Änderungen oder die Arbeit bis zu einem mergebaren Patch.

Das NeurIPS-Paper zu EvalPlus zeigte, wie stark die ausgewählten Tests das Ergebnis beeinflussen können. Die Forschenden erweiterten die HumanEval-Tests ungefähr um den Faktor 80 und evaluierten 26 Modelle. Unter den stärkeren Tests fielen die Erfolgsraten der am stärksten betroffenen Modelle um 19,3 bis 28,9 Prozentpunkte, und einige Rangfolgen drehten sich um [8]. Die Antworten blieben gleich. Die größeren Testreihen fanden lediglich mehr Fehler.

Repository-Benchmarks haben dasselbe Problem. Im Februar 2026 prüfte OpenAI 138 Aufgaben aus SWE-bench Verified, bei denen o3 in 64 Läufen unregelmäßig scheiterte. Bei 59,4 % dieser gezielt ausgewählten Gruppe fand das Team erhebliche Probleme. Dazu gehörten Tests, die gültige Lösungen ablehnten, und Tests auf Verhalten, das im Issue nicht verlangt wurde [9]. Weil die Prüfung bewusst verdächtige Aufgaben auswählte, beschreibt der Anteil nicht alle 500 Aufgaben. Er zeigt aber, dass Fehler in Aufgaben und Tests die Unterschiede zwischen sehr leistungsfähigen Modellen verzerren können.

Der umgekehrte Fehler ist genauso wichtig: Ein Patch kann die automatischen Tests bestehen und trotzdem nicht zum Mergen geeignet sein. METR ließ Maintainer 296 KI-generierte Pull Requests aus drei Repositorys und 95 Aufgaben prüfen. Ihre Annahmerate lag 24,2 Prozentpunkte unter dem automatischen SWE-bench-Ergebnis [10]. Sie lehnten Patches wegen Fehlern in der Kernfunktion, Schäden an anderen Stellen, schlechter Codequalität und weiteren Integrationsproblemen ab. Ein binärer Benchmark-Wert verbirgt all diese Gründe hinter „bestanden“ oder „nicht bestanden“.

mehr Tests in EvalPlus

80×

einige Rangfolgen drehten sich um

Probleme in gezielter SWE-bench-Prüfung

59,4 %

nicht repräsentativ für alle 500 Aufgaben

Lücke zum Maintainer-Review

24,2 PP

METR prüfte 296 Pull Requests

Zusammen zeigen diese Ergebnisse, dass Testqualität und menschliches Review unterschiedliche Fragen beantworten. „Der Patch hat bestanden“ ist ein wichtiger Hinweis, sagt mir aber nicht, ob ich dieses Modell jeden Tag Änderungen in meinem Branch vornehmen lassen möchte.

Was verbirgt ein Mittelwert? Wiederholbarkeit und lange Aufgaben

Eine mittlere Erfolgsrate fasst alle Erfolge und Fehler in einer Zahl zusammen. Sie zeigt weder, wie zuverlässig ein Modell denselben Erfolg wiederholt, noch wie stark die Zuverlässigkeit bei längeren Aufgaben sinkt. Auch die Folgen eines fehlgeschlagenen Laufs bleiben unsichtbar. Diese Unterschiede zählen, wenn ich das Modell täglich nutze, statt es einmal zu prüfen.

Das arXiv-Paper zu tau-bench macht das Problem mit pass^k sichtbar. Dieser Wert fragt, ob ein Agent dieselbe Aufgabe in mehreren Versuchen jedes Mal löst. GPT-4o erreichte bei Retail-Aufgaben in der Ansicht mit einem Versuch 61,2 %, doch sein Retail-pass^8 fiel unter 25 % [11]. Ein Modell, das dreimal funktioniert und beim vierten Mal scheitert, kann weiterhin einen ordentlichen Durchschnitt erreichen. Im täglichen Einsatz wirkt es unberechenbar.

Die Aufgabenlänge führt zu einer ähnlichen Trennung. METR evaluierte Agenten auf 170 Aufgaben mit ungefähr acht Läufen pro Kombination aus Modell und Aufgabe. Der Aufgabenhorizont, bei dem ein Modell in 80 % der Fälle erfolgreich war, war vier- bis sechsmal kürzer als sein 50-%-Erfolgshorizont [12]. Ein Modell kann also bei einer 50-%-Grenze beeindruckende Zwei-Stunden-Aufgaben schaffen und trotzdem nur bei deutlich kürzeren Aufgaben verlässlich sein.

Das erklärt, warum meine praktische Erfahrung einem Leaderboard widersprechen kann. Im Alltag geht es um wiederkehrende Aufgaben, leicht zu übersehenden Repository-Kontext, fehlerhafte Befehle, mehrdeutige Anforderungen, Review-Schleifen und die Folgen der schlechtesten Läufe. Meine Eindrücke können ebenfalls falsch sein, weil eine gelungene Antwort oder ein katastrophaler Fehler meine Erinnerung prägen kann. Statt zwischen Benchmarks und Intuition zu wählen, muss ich die Teile meines Arbeitsablaufs messen, die diesen Eindruck erzeugen.

Wie sollte ich Modelle für meine eigene Arbeit vergleichen?

Ich nutze öffentliche Benchmarks als Filter. Sie zeigen mir, für welche Modelle sich ein genauerer Test lohnt, und eine kontrollierte Evaluation wie DeepSWE ist deutlich aussagekräftiger als eine Launch-Demo. Die endgültige Wahl treffe ich dennoch mit einer kleinen Evaluation aus meiner eigenen Arbeit.

Anthropic empfiehlt, eine Agent-Evaluation mit 20 bis 50 Aufgaben zu beginnen, die aus manuellen Prüfungen, bekannten Fehlern, Bug-Reports und echten Entwicklungsanfragen stammen [13]. Das reicht, um grobe Fehlanpassungen zu erkennen, ohne ein allgemeines Leaderboard vorzutäuschen. Für einen engen Vergleich würde ich dieselben Aufgaben mehrfach ausführen und Umgebung, Tools, Prompts, Effort-Stufe und Budget konstant halten.

Bevor ich die Ergebnisse ansehe, würde ich festlegen, wann ich einen Patch akzeptiere. Tests stehen an erster Stelle, bilden aber nicht die gesamte Bewertungsgrundlage. Zusätzlich würde ich erfassen:

• ob ich das Ergebnis beim ersten Versuch akzeptiert habe;
• die gesamte Zeit bis zum akzeptierten Ergebnis, einschließlich Review und Reparatur;
• aktive Review-Minuten getrennt von der Modelllatenz;
• Nachfragen, Kurskorrekturen, Neustarts und manuelle Änderungen;
• unnötig geänderte Dateien und Verstöße gegen Repository-Konventionen;
• schwere Fehler wie Sicherheitsregressionen, Datenverlustrisiko oder Schäden an nicht betroffenen Funktionen;
• Token und API-Kosten für das vollständige akzeptierte Ergebnis.

Für die Bewertung der Codequalität würde ich die Modellnamen ausblenden und konkurrierende Patches möglichst in zufälliger Reihenfolge prüfen. Ergebnisse würde ich nach Aufgabentyp ausweisen, statt Bugfixes, Reviews, Refactorings und lange Feature-Arbeit in einer Summe zu vermischen. Bleiben zwei Modelle über mehrere Läufe hinweg ähnlich, würde ich das günstigere wählen. Verbraucht sein höherer Review-Aufwand jedoch die API-Ersparnis, ist es für meinen Arbeitsablauf nicht günstiger.

DeepSWE hat Luna Max einen Platz auf meiner Testliste verdient. In meinem nächsten Vergleich würde ich Aufgaben und Tools konstant halten und danach den gesamten Weg bis zu einem akzeptierten Patch zählen: Steuerung, Review, Reparatur und fehlgeschlagene Läufe. Wenn Luna nach Einrechnung dieser Kosten noch günstiger ist, ist es auch für meine Arbeit die günstigere Wahl. Wenn nicht, ist der Leaderboard-Preis nicht der Preis, den ich zahle.