Was SWE-bench und andere Coding-Benchmarks messen

Was ist SWE-bench und wie wird es bewertet?

Ein Coding-Benchmark besteht aus einer festen Liste von Aufgaben und einer Bewertungsregel. Das Modell oder der Coding-Agent löst die Aufgaben, die Regel markiert jede Lösung als bestanden oder nicht bestanden, und der Score ist der Anteil der bestandenen in Prozent. Dieser Beitrag nimmt sich zuerst den Benchmark vor, über den am meisten gesprochen wird, SWE-bench, und liest dann die anderen mit denselben vier Fragen. Den Aufbau um das Modell herum (den Harness) haben wir im Beitrag über Harness Engineering beschrieben, Bewertungen durch ein Richtermodell im Beitrag über LLM-as-a-judge.

SWE-bench ist ein Benchmark, der aus echten GitHub-Issues gebaut ist. Laut seiner Seite erschien die erste Version im Oktober 2023 und umfasst 2.294 Aufgaben aus Issues und Pull Requests von 12 beliebten Python-Repositorys. Jede Aufgabe stammt aus einem Pull Request, der ein Issue geschlossen und dabei auch Testdateien geändert hat.

Die Bewertung läuft so: Das Modell bekommt den Text des Issues und das Repository im Zustand vor dem Pull Request und ändert den Code. Ist das Modell fertig, laufen zwei Gruppen von Tests:

• FAIL_TO_PASS: Tests, die vor dem Pull Request fehlschlugen und danach bestehen. Sie zeigen, dass das Issue wirklich gelöst ist.
• PASS_TO_PASS: Tests, die vorher wie nachher bestehen müssen. Sie zeigen, dass die Änderung nichts kaputt gemacht hat, was schon funktionierte.

Bestehen beide Gruppen, gilt die Aufgabe als gelöst. Der Score ist der Anteil gelöster Aufgaben in Prozent; in den Leaderboards steht er als “% Resolved”.

SWE-bench ist heute kein einzelnes Set mehr, sondern eine Familie. Die Zahlen in der Tabelle haben wir am 20. Oktober 2026 auf der Seite des jeweiligen Sets gelesen:

Quelle: die Seite von SWE-bench, die Vorstellung von Multilingual und die SWE-bench-Pro-Seite von Scale AI, 20. Oktober 2026. Die Ergebnisse des privaten Pro-Sets erscheinen in einem eigenen Leaderboard.

Beim Lesen des Leaderboards zählt noch ein Detail. Die Seite von Verified schreibt, dass das Leaderboard Coding-Systeme jeder Art in dieselbe Liste stellt, von einfachen Agentenschleifen bis zu Systemen, die mehrere Versuche machen. Um Modelle untereinander zu vergleichen, gibt es eine eigene Ansicht “Bash Only”: Dort läuft jedes Modell mit demselben kleinen Agenten (mini-SWE-agent) und nur mit einer Bash-Shell.

Warum reicht SWE-bench Verified nicht mehr?

Verified erschien im August 2024 gemeinsam mit OpenAI. Laut Epoch AI wurden seine 500 Aufgaben aus den 2.294 des ursprünglichen Sets durch die unabhängige Prüfung von drei Fachleuten ausgewählt, um Aufgaben mit Problemen auszusortieren.

Am 3. September prüfte Epoch Verified erneut und stufte es als „fehlerhaft“ (Flawed) ein. Es nennt drei Gründe:

• Die Tests weisen richtige Lösungen zurück. In einer Prüfung, die OpenAI am 23. Februar 2026 veröffentlichte, sah es sich die Aufgaben an, an denen Modelle oft scheitern. Es prüfte 27,6 % der Aufgaben und fand bei 59,4 % davon einen Test, der eine korrekt funktionierende Lösung zurückwies. Laut Epoch heißt das, dass mindestens 16,4 % aller Aufgaben kaputt sind. Epochs Messlatte ist, dass weniger als 20 % der Fragen einen solchen Fehler haben.
• Die Aufgaben sind in Trainingsdaten gelangt. Verified ist ein festes Set; alle Aufgaben und alle Lösungen sind öffentlich. Laut OpenAIs Prüfung hatte jedes getestete Frontier-Modell zumindest einen Teil dieser Probleme und ihrer Lösungen im Training gesehen. OpenAIs Schluss: Fortschritt auf Verified zeigt nicht mehr echtes Können in der Softwareentwicklung, sondern wie viel das Modell im Training von diesem Benchmark gesehen hat.
• Der Score lässt sich austricksen. Das RDI-Team in Berkeley fand einen Reward Hack, der die volle Punktzahl bringt.

Die Modellhersteller haben darauf reagiert. Laut einem Beitrag von Cursor hörte OpenAI ganz auf, Ergebnisse auf Verified zu berichten, als es sah, dass Frontier-Modelle die Referenzlösungen aus dem Gedächtnis wiedergeben konnten. Anthropics Systemkarte zu Opus 5 vom 24. Juli berichtete Verified noch: 96,0 %, gemittelt über fünf Versuche. In der Karte zu Opus 5.5 vom 22. September fehlt Verified; dort stehen nur Pro, Multilingual und Multimodal. In der Ankündigung desselben Modells schreibt Anthropic außerdem, dass Abstände in Benchmarks auf diesem Leistungsniveau weniger zuverlässig zeigen, wie groß der Unterschied im echten Einsatz ist.

Ein Benchmark, bei dem alle nahe an der Obergrenze liegen, kann Modelle nicht mehr unterscheiden. Das sehen auch die, die Benchmarks bauen. Aider ersetzte seinen alten Editing-Benchmark durch ein schwierigeres Set, als die Scores 80 % überschritten. Terminal-Bench 4.0 wertete Aufgaben, die alle neuesten Modelle in 5 von 5 Versuchen lösten, als „gesättigt“ und nahm sie aus dem Set. Die Seite von DeepSWE schreibt ebenfalls, dass sich die führenden Modelle in einem schmalen Score-Band drängen und dass sich die Konfidenzintervalle benachbarter Konfigurationen oft überlappen.

In derselben Woche fällte Epoch dasselbe Urteil über zwei weitere Coding-Benchmarks. Es stuft einen Benchmark als „fehlerhaft“ ein, wenn Fehler 20 % oder mehr des Scores betreffen können:

Quelle: die Prüfungen von Epoch AI. Bei Verified stützt sich Epoch auf die Prüfung von OpenAI. Die Aufgaben von Terminal-Bench kommen aus der Community; Epoch zählte die Probleme, die in seinem Repository öffentlich gemeldet sind. Bei BFCL zog es eine Zufallsstichprobe aus 5.088 Einträgen.

Wie so ein Fehler aussieht, zeigt ein Beispiel aus BFCL. In der Aufgabe “What is the current time in Sydney, Australia?” bekommt das Modell eine Funktion namens get_local_time(location). Der Antwortschlüssel markiert die Aufgabe als „irrelevant“. Die volle Punktzahl bekommt nur ein Modell, das gar keine Funktion aufruft; ein Modell, das die Funktion richtig aufruft, bekommt null Punkte.

Was messen die anderen Coding-Benchmarks?

SWE-bench betrachtet eine einzige Art von Arbeit: einen Patch, der ein Issue in einem Repository schließt. Was man von einem Coding-Agenten erwartet, ist breiter, deshalb misst jeder Benchmark einen anderen Ausschnitt. Die Angaben in der Tabelle haben wir am 20. Oktober 2026 auf der Seite des jeweiligen Benchmarks gelesen:

Quelle: die Seite oder Ankündigung des jeweiligen Benchmarks, 20. Oktober 2026. „Steht nicht auf der Seite“ heißt: Auf der Seite, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu. Die Einschätzungen von Cognition und Cursor stammen aus den Beiträgen, in denen sie ihre eigenen Benchmarks vorstellen.

Auch wie aktuell die Leaderboards sind, ist verschieden. Das Leaderboard von Aider wurde zuletzt am 20. November 2025 aktualisiert, das von BFCL am 12. April 2026. Die neueste Version im Repository von LiveCodeBench (release_v6) umfasst 1.055 Probleme, die zwischen Mai 2023 und April 2025 erschienen sind. Fehlt ein Modell in so einem Leaderboard, kann das heißen, dass das Leaderboard alt ist, und nicht, dass das Modell schlecht ist.

Der älteste Name, der nicht in der Liste steht, ist HumanEval: ein Set, das OpenAI 2021 veröffentlichte und bei dem Modelle Code aus einem Docstring schreiben. Sein Repository ist heute als “Deprecated and unmaintained” markiert. Das Team von LiveCodeBench fand außerdem, dass manche Modelle, die bei HumanEval gut abschneiden, womöglich auf dieses Set überangepasst sind.

Auch Code-Review-Tools haben Benchmarks. GitHub hat am 5. Oktober ReviewBench veröffentlicht; dort entscheidet ein Richtermodell, ob ein Kommentar eine zutreffende Feststellung ist, und GitHub hat auch den Prompt des Richters veröffentlicht. Wie man einen Benchmark liest, den ein Richtermodell bewertet, haben wir im Beitrag über LLM-as-a-judge beschrieben.

Wird Code, der die Tests besteht, auch gemergt?

Der Score von SWE-bench kommt von einem automatischen Bewerter: Bestehen die Tests, gilt die Aufgabe als gelöst. In einer Studie, die METR am 10. März 2026 veröffentlichte, hat es gemessen, wie gut diese Zahl zum Review eines echten Maintainers passt. 4 aktive Maintainer von 3 Repositorys aus Verified (scikit-learn, Sphinx, pytest) lasen insgesamt 296 von KI geschriebene PRs wie in einem echten Review und entschieden, ob sie sie mergen würden. Wer den PR geschrieben hatte, wussten sie nicht.

Das Ergebnis: Etwa die Hälfte der PRs, die die Tests bestanden, hätten die Maintainer nicht gemergt. Weil die Entscheidung eines Maintainers von Person zu Person schwanken kann, ließ METR dieselben Maintainer auch menschliche PRs lesen, die im Repository tatsächlich gemergt worden waren; davon nahmen sie etwa 68 % an. Werden die Scores auf diese Basis skaliert, liegt der automatische Bewerter im Schnitt 24,2 Punkte über der Entscheidung der Maintainer. Ohne Skalierung beträgt der Abstand 34,9 Punkte.

Die Maintainer lehnten aus drei Arten von Gründen ab: Die Änderung löst das Problem nicht wirklich, sie greift in fremden Code ein und macht ihn kaputt, oder der Code entspricht nicht dem Standard des Repositorys. METR nennt auch seine Grenzen offen: Die Agenten bekamen keine Gelegenheit, ihre Arbeit nach Feedback zu verbessern, und untersucht wurden nur ein Teil eines einzigen Benchmarks und ein einziger Agent. Das Ergebnis sagt also nicht, dass Modelle das nicht können. Es sagt etwas anderes: Wer den Score für sich allein liest, hält den Agenten für nützlicher, als er ist.

FrontierCode ist ein Benchmark, der diese Fragen in den Score einbezieht. Cognition hat mit den Maintainern von 36 Open-Source-Repositorys 150 Aufgaben erarbeitet; die Kriterien, nach denen eine Änderung als mergebar gilt, legten in jedem Repository die Maintainer fest. Neben den Unit-Tests gibt es eine Umfangsprüfung: Berührt die Änderung nur die Dateien, die sie berühren darf, und überschreitet der Diff eine bestimmte Größe? Außerdem laufen die Tests, die der Agent schreibt, auch auf dem alten, fehlerhaften Code; ein Test, der dort nicht fehlschlägt, prüft nichts.

Was die Strafe für zu viel Umfang bewirkt, zeigt Anthropics eigener Bericht. Laut der Systemkarte zu Opus 5 nahm das Modell auf Effort-Stufen über high mehr Änderungen vor, als die Aufgabe verlangte, und sein FrontierCode-Score sank. Als der Prompt eine kurze Anweisung bekam, im Rahmen der Aufgabe zu bleiben, kam der Score bei den meisten dieser Aufgaben zurück. Das ist ein Ergebnis, das der Hersteller für Opus 5 berichtet; wie viele Punkte zurückkamen, steht nicht in der Karte.

Genau in dieser Lücke arbeitet das Code-Review: Der Test zeigt, dass die Änderung das gewünschte Verhalten liefert; das Review fragt, ob die Änderung dorthin gehört. In diffox stellen spezialisierte Agenten diese Frage. Einer vergleicht die geänderten Zeilen Regel für Regel mit den Regeln in der Regeldatei des Repositorys (AGENTS.md, CLAUDE.md); eine Regel, die nicht in der Datei steht, zählt nicht. Ein anderer sucht einen Test, der nicht prüft, was sein Name sagt, oder eine Assertion, die nie fehlschlagen kann; einen fehlenden Test wertet er dagegen nicht als Feststellung. Wie Sie erkennen, ob ein Test wirklich etwas prüft, haben wir im Beitrag über das Review von KI-generiertem Code beschrieben.

Wie liest man einen Benchmark-Score?

Wenn Sie auf einen Score stoßen, stellen Sie diese sechs Fragen. Unterscheiden sich zwei Scores in einer davon, messen sie nicht mehr dasselbe:

1. Welches Set oder welche Teilmenge? „SWE-bench“ allein sagt nichts: Verified, das öffentliche Set von Pro und eine Teilmenge, die ein Unternehmen ausgewählt hat, sind verschiedene Zahlen. Die Dokumentation von Anthropic schreibt, dass Scores auf der Teilmenge von 482 Problemen, die Anthropic aus Pro ausgewählt hat, nicht mit dem öffentlichen Leaderboard vergleichbar sind. Mit den Pro-Ergebnissen in der Systemkarte desselben Unternehmens sind sie ebenfalls nicht vergleichbar, denn diese wurden auf einem anderen Problemset und mit max effort gemessen.
2. In welchem Agenten? Ein Score gehört nicht dem Modell, sondern dem Paar aus dem Modell und dem Agenten, der es ausführt. Laut Epoch hängen die Ergebnisse auf Verified stark vom verwendeten Agenten ab; im Leaderboard von Terminal-Bench ist jede Zeile ein Modell und ein Agent. Selbst auf demselben Benchmark können die Einstellungen abweichen: Epoch stellte fest, dass Codex-Einträge auf Terminal-Bench abgelehnte Anfragen aus Sicherheitsgründen erneut versuchen, die Standardeinstellung dagegen nicht. Artificial Analysis schreibt ebenfalls, dass seine Ergebnisse zu bestimmten Konfigurationen gehören und nicht zu Produktnamen, und dass Modell, Einstellungen und die Art der Ausführung das Ergebnis deutlich verändern können. Epoch wertet auch ein schlechtes Kontextmanagement des Agenten als Problem des Aufbaus, das den Score drückt; was Coding-Agenten tun, wenn der Kontext voll ist, haben wir im Beitrag über Auto-Compact beschrieben.
3. Auf welcher Effort-Stufe? Leaderboards zeigen ein Modell oft auf der Stufe, auf der es am besten abschneidet. Die Ergebnisse in Anthropics Ankündigung von Opus 5.5 wurden, wenn nicht anders angegeben, mit max effort gemessen; die Zeile zu Terminal-Bench zeigt jedes Modell auf der Stufe, die ihm den höchsten Score brachte. Auch FrontierCode lässt jedes Modell auf jeder Effort-Stufe 5-mal laufen und berichtet die beste Stufe. Wenn Sie das Tool auf der Standardstufe nutzen, sehen Sie das Ergebnis aus der Tabelle womöglich nicht.
4. Wie viele Läufe, wie viel Unsicherheit? Dieselbe Konfiguration kann in zwei Läufen verschiedene Scores liefern. Das Leaderboard von Terminal-Bench zeigt den Mittelwert aus 5 Läufen mit einem Konfidenzintervall von 95 %; Epoch empfiehlt für Fehlerbalken mindestens 5 Läufe pro Modell. Ein Unterschied, der nicht größer ist als das Rauschen, ist kein Unterschied; das Rauschen zwischen zwei Läufen in unseren eigenen Messungen haben wir im Beitrag über LLM-as-a-judge beschrieben.
5. Wer hat gemessen? Die Tabelle eines Modellherstellers ist unter Bedingungen gemessen, die er selbst gewählt hat. Unabhängige Messungen versuchen, jedes Modell nach denselben Regeln laufen zu lassen: DeepSWE lässt alle Modelle mit demselben kleinen Agenten laufen. Achten Sie in beiden Fällen auf die Details: Artificial Analysis lässt ein anderes Modell weitermachen, wenn ein Modell eine Aufgabe ablehnt, und zählt auch diesen Versuch; Anthropic schreibt ebenfalls, dass andere Modelle einen Teil der Aufgaben von Opus 5.5 erledigten, wenn Sicherheitsvorkehrungen eingriffen.
6. Ist das Set gesättigt, kontaminiert, aktuell? Ein Set, bei dem alle nahe an der Obergrenze liegen, unterscheidet die Modelle nicht; ein Set mit öffentlichen Aufgaben und Lösungen misst womöglich auch das Gedächtnis. Achten Sie auf das Veröffentlichungsdatum der Aufgaben (LiveCodeBench führt es für jedes Problem), fragen Sie, ob das Set einen geschlossenen Teil hat, und prüfen Sie, wann das Leaderboard zuletzt aktualisiert wurde.

Ein Beispiel, das zeigt, was der Effort an demselben Modell und denselben Aufgaben bewirkt, steht in Anthropics Dokument zu Kosten und Intelligenz. Das Einzige, was sich ändert, ist die Effort-Stufe:

Am selben Modell, bei dem sich nur der Effort ändert, verschiebt sich der Score um 9,3 Punkte, und die Kosten pro Aufgabe steigen von $0,11 auf $0,74. In einer Tabelle, die zwei Modelle vergleicht, prüfen Sie zuerst, auf welcher Stufe jedes gemessen wurde: Wurde eines auf max und das andere auf seiner Standardstufe gemessen, kann der Unterschied von der Einstellung kommen und nicht vom Modell.

Welcher Benchmark passt zu welcher Arbeit?

Einen Benchmark auszuwählen heißt auszuwählen, was Sie vom Agenten wollen. Die Tabelle unten ordnet häufigen Arbeiten den Benchmark zu, der ihnen am nächsten kommt:

Quelle: die Tabellen in diesem Beitrag und die Seite des jeweiligen Benchmarks, 20. Oktober 2026.

Keiner davon ersetzt die Arbeit in Ihrem eigenen Repository. Auch die Dokumentation von Anthropic empfiehlt, die Effort-Einstellung an Ihrer eigenen Arbeit auszuprobieren. Die verlässlichste Messung ist, ein paar echte Aufgaben aus Ihrem eigenen Repository mit demselben Agenten, auf derselben Effort-Stufe und mehrmals laufen zu lassen.

Keiner davon misst außerdem, ob eine Änderung gemergt werden sollte. Am nächsten kommt dem FrontierCode, aber auch dort entscheiden Kriterien, die die Maintainer vorher aufgeschrieben haben. In Ihrem Repository trifft diese Entscheidung das Review.

Häufige Fragen

Was ist SWE-bench?

SWE-bench ist ein Benchmark, der misst, ob KI-Modelle und Coding-Agenten echte GitHub-Issues lösen können. Das Modell bekommt den Text des Issues und das Repository im damaligen Zustand und ändert den Code. Besteht die Änderung die FAIL_TO_PASS-Tests, die zeigen, dass das Issue gelöst ist, und die PASS_TO_PASS-Tests, die zeigen, dass nichts kaputtgegangen ist, gilt die Aufgabe als gelöst. Die erste Version umfasst 2.294 Aufgaben aus 12 Python-Repositorys; dazu kommen Teilmengen und verwandte Sets wie Verified, Pro und Multilingual.

Was ist der Unterschied zwischen SWE-bench Verified und SWE-bench Pro?

Verified ist eine von Menschen geprüfte Teilmenge des ursprünglichen Sets mit 500 Aufgaben; Aufgaben und Lösungen sind öffentlich. Pro ist das schwierigere Set von Scale AI mit 1.865 Aufgaben aus 41 Repositorys: Die Lösungen umfassen im Schnitt 107,4 Zeilen und 4,1 Dateien. Die Aufgaben von Pro stammen aus Repositorys mit Copyleft-Lizenz und aus geschlossenem Firmencode, und für einen Teil davon werden die Ergebnisse nie veröffentlicht. Epoch AI stufte Verified im September 2026 als fehlerhaft ein; auch Anthropics neueste Modellkarte berichtet Pro statt Verified.

Ab wie viel Prozent ist ein SWE-bench-Score gut?

Eine einzelne Schwelle gibt es nicht. Ein Score hängt davon ab, zu welchem Set, welchem Agenten und welcher Effort-Stufe er gehört: Auf Anthropics eigener Teilmenge verschiebt sich der Score desselben Modells allein durch die Effort-Stufe um 9,3 Punkte, und Anthropic schreibt, dass diese Scores nicht mit dem öffentlichen Leaderboard vergleichbar sind. Vergleichen Sie zwei Scores nur, wenn sie auf demselben Set, mit demselben Agenten und ähnlichen Einstellungen gemessen wurden; schauen Sie nicht auf eine Zahl für sich, sondern auf ihren Abstand zu anderen Modellen, die unter denselben Bedingungen gemessen wurden.

Was misst Terminal-Bench?

Terminal-Bench misst, ob ein Agent End-to-End-Aufgaben im Terminal erledigen kann: Aufgaben aus Software, Wissenschaft, ML, Betrieb, Sicherheit, Hardware und Medien. Jede Aufgabe hat ihren eigenen Verifier. Mit Version 4.0 wurde es zu einem laufend aktualisierten Benchmark; gesättigte Aufgaben, abgelehnte Aufgaben und Aufgaben, deren Lösung öffentlich geworden ist, nimmt es aus dem Set. Das Leaderboard zeigt für jedes Paar aus Modell und Agent den Mittelwert aus 5 Läufen mit einem Konfidenzintervall von 95 %. Epoch AI verzeichnete am 4. September bei 30 von 66 Aufgaben einen öffentlich bekannten Bewertungsfehler.

Was ist der Unterschied zwischen LiveCodeBench und SWE-bench?

LiveCodeBench prüft mit Problemen aus Wettbewerben auf LeetCode, AtCoder und Codeforces, wie gut ein Modell Code schreibt, eigenen Code repariert, Code ausführt und Testausgaben vorhersagt; eine Aufgabe ist ein einzelnes Problem. SWE-bench verlangt dagegen eine Änderung, die ein echtes Issue in einem Repository schließt. Weil LiveCodeBench jedes Problem mit seinem Veröffentlichungsdatum versieht, können Sie ein Modell an Problemen messen, die nach seinem Trainings-Cutoff erschienen sind; so kann das Modell die Lösung nicht im Training gesehen haben.

Wie sehr kann man einem Benchmark-Score trauen?

Ein Score beantwortet die enge Frage, die der Benchmark stellt. Bevor Sie ihm trauen, prüfen Sie sechs Dinge: welches Set, welcher Agent, welche Effort-Stufe, wie viele Läufe und welches Konfidenzintervall, wer gemessen hat und ob das Set gesättigt oder kontaminiert ist. Deshalb sind unabhängige Prüfungen wichtig: Epoch AI stufte im September 2026 SWE-bench Verified, Terminal-Bench 4.0 und BFCL v4 als fehlerhaft ein; METR maß, dass etwa die Hälfte der SWE-bench-PRs, die die Tests bestehen, im Review der Maintainer durchfallen würde.

Mit welchem Benchmark wird diffox gemessen?

diffox ist ein KI-Code-Review-Tool und wird deshalb nicht mit Coding-Benchmarks gemessen, sondern mit Benchmarks für Code-Review. Wir haben Martians Open-Source-Benchmark für Code-Review selbst ausgeführt und das Ergebnis mit Nachweis veröffentlicht: Jedes Review ist ein öffentlicher Pull Request, bewertet hat der Code des Benchmarks selbst, und mit den Befehlen im Nachweis-Repository können Sie die Tabelle auf Ihrem eigenen Rechner nachbauen. Dieser Beitrag sagt auch, aus wie vielen Läufen jede Zeile stammt: Den öffentlichen Lauf haben wir auf der damaligen Empfindlichkeitsstufe Hoch ausgeführt; die Zeilen Mittel und Niedrig sind der Mittelwert mehrerer interner Läufe.