Was Benchmarks wirklich messen

Qwen3.8-27B ist ein vergleichsweise kompaktes Modell mit 27 Milliarden Parametern. Seine Modellgewichte sind unter der Apache-2.0-Lizenz frei verfügbar, sodass es auch auf eigener Infrastruktur betrieben werden kann. Auf SWE-bench Pro erreicht es 61,7 %. Claude Opus 4.6, ein großes kommerzielles Modell von Anthropic, steht in derselben Vergleichstabelle bei 53,4 %. [1][2]

Auf den ersten Blick scheint die Sache damit erstaunlich einfach. Wenn wir Coding Agents vergleichen und ein Modell 61,7 Prozent erreicht, während ein anderes 53,4 Prozent schafft, liegt die naheliegende Schlussfolgerung auf der Hand: Qwen3.8-27B ist offenbar der bessere Coding Agent. Vielleicht brauchen wir für einen Technologievergleich also gar keine langen Diskussionen mehr, sondern nur noch eine Tabelle und die größte Zahl darin.

Bevor wir diese Schlussfolgerung ziehen, lohnt sich allerdings eine ziemlich unspektakuläre Frage: Was bedeutet diese Prozentzahl eigentlich?

Interessanterweise müssen wir dafür nicht einmal die Qwen-Modellkarte verlassen. Dort steht tatsächlich 61,7 für Qwen3.8-27B und 53,4 für einen von Qwen als „Opus4.6 Max“ bezeichneten Vergleichswert. Anthropic selbst berichtet den zugrunde liegenden Wert als 53,4 % für Claude Opus 4.6; eine eigenständige Modellvariante namens „Opus 4.6 Max“ ist daraus nicht abzuleiten. [1][2]

Direkt unter der Tabelle beschreibt Qwen außerdem das Evaluation Setup. Mit Ausnahme des übernommenen Opus-Werts wurden die verglichenen Modelle mit einem Claude-Code-Harness, temperature=1.0, top_p=0.95 und einem Context Window von 256K evaluiert. Qwen gibt zusätzlich an, problematische Tasks korrigiert und die Baseline-Modelle auf diesem „refined benchmark“ erneut ausgeführt zu haben. Der Opus-Wert bildet ausdrücklich die Ausnahme: Für ihn wurde der offiziell berichtete Anthropic-Score übernommen. [1]

Auch die Datensatzquelle ist nachvollziehbar. Qwens veröffentlichte Eval-Metadaten verweisen auf ScaleAI/SWE-bench_Pro; dessen öffentlich verfügbarer Test-Split enthält 731 Aufgaben. SWE-bench Pro als Gesamtbenchmark ist größer und umfasst zusätzlich Held-out- und kommerzielle Bereiche. [1][6]

Das macht die Zahlen weder falsch noch verdächtig. Es bedeutet lediglich, dass zwei Prozentwerte selbst dann nicht automatisch vollständig vergleichbar sind, wenn sie in derselben Tabelle nebeneinanderstehen. Schon bei unserem scheinbar trivialen Ausgangsvergleich gehören Modell, Harness, Sampling-Einstellungen, Datensatzvariante und Herkunft des Vergleichswerts zur Interpretation.

Nicht der Score ist das Problem, sondern die Interpretation des Scores.

Was ist überhaupt ein Benchmark?

Ein Benchmark ist zunächst nichts Geheimnisvolles. Er ist ein standardisierter Test oder eine Sammlung von Aufgaben, mit denen Systeme unter möglichst definierten Bedingungen gemessen und miteinander verglichen werden können.

Man kann sich einen Benchmark eher wie eine Prüfung als wie eine vollständige Berufsbeurteilung vorstellen. Eine Mathematikklausur kann sinnvoll messen, wie gut jemand bestimmte mathematische Aufgaben löst. Ein sehr gutes Ergebnis ist eine relevante Information. Trotzdem beantwortet die Klausur nicht automatisch die Frage, wie gut diese Person später als Ingenieur arbeitet, mit unklaren Anforderungen umgeht, Entscheidungen dokumentiert oder ein bestehendes System über zehn Jahre weiterentwickelt.

Für Coding-Benchmarks gilt dasselbe. Ein guter Benchmark kann eine bestimmte Software-Engineering-Fähigkeit unter bestimmten Bedingungen erstaunlich gut messen. Daraus folgt aber nicht, dass er sämtliche Fähigkeiten professioneller Softwareentwicklung misst.

Ein Benchmark ist kein Urteil über ein Modell. Er ist ein Messinstrument. Bevor wir die Zahl vergleichen, müssen wir verstehen, was dieses Instrument tatsächlich misst.

SWE – Software Engineering

Das Kürzel SWE begegnet uns inzwischen an ziemlich vielen Stellen: SWE-bench, SWE-bench Verified, SWE-bench Pro, SWE-Lancer oder SWE-rebench.

Die Auflösung ist wesentlich weniger exotisch, als die Namen vermuten lassen:

SWE steht schlicht für Software Engineering.

Der Begriff soll ausdrücken, dass diese Benchmarks mehr untersuchen wollen als das Generieren einer einzelnen Funktion aus einer kurzen Aufgabenbeschreibung. Wie nahe sie damit tatsächlich an realer Softwareentwicklung liegen, hängt vom jeweiligen Benchmark ab.

SWE-bench – vom Coding-Problem zum Repository

Viele klassische Coding-Benchmarks arbeiten mit weitgehend isolierten Aufgaben. Das Modell erhält beispielsweise eine Beschreibung und eine Funktionssignatur, erzeugt eine Implementierung und wird anschließend mit Tests bewertet.

Vereinfacht:

Aufgabenbeschreibung
↓
Funktion implementieren
↓
Tests ausführen

Das ist nützlich, misst aber nur einen Ausschnitt dessen, was Entwickler im Alltag tun. In einem bestehenden Projekt besteht das Problem selten darin, dass uns jemand eine leere Funktion mit perfekter Beschreibung reicht. Wir müssen zunächst herausfinden, welche Dateien relevant sind, wie das vorhandene System funktioniert, welche Änderung fachlich gemeint ist und welches bestehende Verhalten dabei nicht beschädigt werden darf.

SWE-bench brachte diese Evaluation deshalb näher an bestehende Software-Repositories. Der ursprüngliche Benchmark enthält 2.294 Aufgaben aus zwölf populären Python-Repositories. Die Aufgaben wurden aus realen GitHub-Issues und den dazugehörigen Änderungen gewonnen. Ein System erhält den Repository-Zustand vor dem menschlichen Fix sowie die ursprüngliche Problembeschreibung und soll einen Patch erzeugen, der das Problem behebt. Die Evaluation prüft anschließend, ob vorher fehlschlagende Tests erfolgreich werden und bestehendes Verhalten erhalten bleibt. [3]

Das Grundprinzip sieht damit eher so aus:

Repository-Zustand
+
GitHub-Issue
↓
Codebase untersuchen
↓
relevante Stelle finden
↓
Patch erzeugen
↓
Tests ausführen
↓
gelöst / nicht gelöst

Das ist gegenüber einer isolierten Funktion ein erheblicher Schritt in Richtung Software Engineering. Das System muss sich in fremdem Code orientieren und eine Änderung in einen vorhandenen Kontext integrieren.

Es bleibt trotzdem eine kontrollierte Aufgabe. Niemand bewertet dabei automatisch, ob die Architektur in drei Jahren noch verständlich ist, ob ein Name zur Fachsprache des Teams passt oder ob sich der Patch sinnvoll in eine langfristige Migrationsstrategie einfügt. SWE-bench misst etwas deutlich Realistischeres als reine Code Completion, aber weiterhin einen definierten Ausschnitt.

Was bedeutet „61,7 % resolved“?

Auf SWE-bench-artigen Leaderboards wird typischerweise der Anteil der nach den jeweiligen Evaluationsregeln gelösten Aufgaben als % Resolved angegeben. [3]

Ein Wert von 61,7 % bedeutet deshalb sinngemäß:

Unter den angegebenen Evaluationsbedingungen wurden 61,7 Prozent der getesteten Benchmark-Aufgaben nach den Regeln dieses Benchmarks als gelöst eingestuft.

Das klingt fast banal, ist aber die wichtigste Übersetzung des gesamten Artikels. Der Nenner dieser Prozentzahl sind Benchmark-Tasks. Der Nenner sind nicht alle denkbaren Softwareaufgaben, sämtliche Tätigkeiten eines Entwicklers oder alle Situationen, die in einem konkreten Unternehmen auftreten können.

61,7 % SWE-bench Pro bedeutet daher ausdrücklich nicht, dass das Modell 61,7 Prozent aller Softwareaufgaben lösen kann. Es bedeutet auch nicht, dass es „zu 61,7 Prozent ein Softwareentwickler“ ist oder 61,7 Prozent eines Entwicklerarbeitsplatzes ersetzt.

61,7 % SWE-bench bedeutet nicht 61,7 % eines Softwareentwicklers.

Warum SWE-bench Verified entstand

Die Nähe zu realen GitHub-Projekten bringt einen offensichtlichen Vorteil mit sich: Die Aufgaben wurden nicht künstlich für einen Lehrbuch-Benchmark konstruiert. Sie bringt aber gleichzeitig ein neues Problem mit sich. Reale Repositories, Issues, Abhängigkeiten und Tests wurden ursprünglich nicht geschrieben, um daraus ein wissenschaftlich sauberes Messinstrument zu bauen.

Beim ursprünglichen SWE-bench wurden die Aufgaben weitgehend automatisiert gesammelt. Einige erwiesen sich später als uneindeutig, schlecht spezifiziert oder aufgrund ihrer Tests und Umgebung problematisch. Eine funktional korrekte Lösung konnte an einem zu engen Test scheitern; in anderen Fällen fehlten in der Aufgabenbeschreibung Informationen, die ein versteckter Test voraussetzte. Auch unterschiedliche Python-, Betriebssystem- oder Dependency-Zustände konnten die Reproduzierbarkeit beeinflussen. [4][5]

OpenAI und das SWE-bench-Team ließen deshalb 1.699 Kandidaten durch erfahrene Softwareentwickler prüfen. Jede Aufgabe wurde unabhängig von drei Experten bewertet. Daraus entstand SWE-bench Verified mit 500 ausgewählten Tasks. [4][5]

„Verified“ bedeutet in diesem Zusammenhang also nicht, dass mathematisch bewiesen wurde, dass jede denkbare Evaluation perfekt ist. Es bedeutet, dass Menschen die Aufgaben und ihre Evaluation geprüft und ungeeignete Fälle herausgefiltert haben.

Das war eine sinnvolle Verbesserung. Gleichzeitig zeigt die weitere Geschichte des Benchmarks, wie schwer es ist, ein dauerhaft gutes Messinstrument für Softwareentwicklung zu bauen.

Wenn ein erfolgreicher Benchmark selbst Teil des Systems wird

SWE-bench Verified wurde sehr erfolgreich. Modellanbieter veröffentlichten ihre Scores, Agent-Entwickler untersuchten erfolgreiche und gescheiterte Trajektorien, Harnesses wurden besser auf Repository-Arbeit abgestimmt und der Benchmark wurde zu einem wichtigen Orientierungspunkt für Coding-Fähigkeiten.

Genau dieser Erfolg verändert mit der Zeit die Bedingungen.

Contamination

Contamination, also Kontamination, bezeichnet im Benchmark-Kontext das Risiko, dass Evaluationsdaten oder sehr ähnliche Informationen bereits während Training oder Post-Training eines Modells verfügbar waren.

Bei SWE-bench ist das besonders leicht nachvollziehbar. Die ursprünglichen Repositories sind öffentlich, ebenso die Issues und häufig auch die Pull Requests beziehungsweise Commits mit den menschlichen Lösungen. Wenn Modelle auf großen Mengen öffentlichen Codes und technischer Kommunikation trainiert werden, kann sich dieses Material mit Evaluationsdaten überschneiden.

Das bedeutet nicht automatisch, dass ein Modell beim Test eine gespeicherte Lösung einfach „nachschlägt“. Zwischen einer Überschneidung im Training, gelerntem projektspezifischem Wissen und der tatsächlichen Reproduktion einer bekannten Lösung liegen erhebliche Unterschiede. Contamination ist zunächst ein Evaluationsrisiko, keine Manipulationsunterstellung.

OpenAI veröffentlichte im Februar 2026 eine erneute Analyse von SWE-bench Verified und kam zu dem Schluss, dass der Benchmark für die Messung aktueller Frontier-Modelle inzwischen zu stark durch solche Effekte und verbleibende Task-Probleme beeinflusst sei. Bei untersuchten Aufgaben konnten alle getesteten Frontier-Modelle in einzelnen Fällen ursprüngliche Gold-Patches oder sehr spezifische Probleminformationen reproduzieren. OpenAI stellte daraufhin die eigene Berichterstattung von SWE-bench-Verified-Scores ein. [4]

Auch andere Arbeiten versuchen inzwischen, genau dieses Problem statischer, öffentlich verfügbarer Software-Engineering-Benchmarks zu adressieren. Ein Ansatz besteht darin, kontinuierlich neue Aufgaben zu sammeln und die Evaluation zeitlich von älteren Trainingsdaten zu trennen. [12][13]

Benchmark Overfitting

Contamination ist nicht dasselbe wie Benchmark Overfitting.

Ein Benchmark kann so wichtig werden, dass Modelle, Post-Training, Prompts oder Agent-Harnesses zunehmend auf genau die Fähigkeiten optimiert werden, die dieser Benchmark belohnt. Dafür muss niemand die konkreten Lösungen kennen. Es genügt, typische Aufgabenstrukturen, Tool-Sequenzen oder besonders erfolgreiche Strategien immer besser abzudecken.

Die Analogie zur Schule funktioniert hier erstaunlich gut. Wenn eine Prüfung über Jahre nahezu dieselbe Struktur besitzt und sämtliche alten Prüfungen öffentlich verfügbar sind, lernen Schüler nicht nur Mathematik. Sie lernen auch, genau diese Prüfung besonders effizient zu bestehen. Das kann weiterhin echtes Wissen erfordern, nur wird die Prüfungsleistung schwieriger von allgemeiner Kompetenz zu trennen.

Das Problem ist nicht AI-spezifisch. Machine Learning beschäftigt sich seit langem mit Overfitting auf Benchmarks, Datensätze und Leaderboards. Je wichtiger eine Kennzahl wird, desto stärker lohnt sich die Optimierung auf genau diese Kennzahl.

Ein System kann deshalb auf einem Benchmark deutlich besser werden, ohne dass dieselbe Verbesserung proportional auf jede andere Software-Engineering-Aufgabe übertragbar sein muss.

Warum SWE-bench Pro entstand

SWE-bench Pro wurde von Scale AI entwickelt, um mehrere dieser Grenzen zu verschieben. Der Benchmark umfasst 1.865 Aufgaben aus 41 Repositories. Davon gehören 731 Aufgaben zum öffentlichen Split, 858 zu einem Held-out-Bereich und 276 stammen aus kommerziellen Codebases. Die enthaltenen Repositories decken Python, Go, JavaScript und TypeScript ab. [6]

Die Aufgaben sind im Durchschnitt umfangreicher als viele klassische SWE-bench-Fälle. Scale berichtet von durchschnittlich 107,4 geänderten Codezeilen über 4,1 Dateien. Weil ursprüngliche Commit Messages und Issues nicht immer genug Kontext bieten, ergänzen menschliche Experten Problemstellungen und Requirements, ohne die konkrete Implementierung vorzugeben. [6]

Die unterschiedlichen Splits sollen dabei verschiedene Probleme adressieren. Der öffentliche Split bleibt reproduzierbar und offen evaluierbar. Held-out-Aufgaben werden nicht vollständig als öffentlicher Benchmark-Datensatz bereitgestellt, wodurch eine direkte Optimierung auf die konkreten Eval-Tasks erschwert wird. Die kommerziellen Aufgaben stammen zusätzlich aus privaten Codebases und reduzieren damit das Risiko, dass genau diese Repository-Zustände und Lösungen bereits über öffentliche Trainingsdaten bekannt sind.

Dabei ist eine Präzisierung wichtig: Held-out bedeutet nicht automatisch „garantiert niemals im Training gesehen“. Es beschreibt zunächst, dass Evaluationsdaten zurückgehalten werden. Wie vollständig dadurch Trainingsüberschneidungen ausgeschlossen sind, hängt von Herkunft der Daten und Trainingspipeline des jeweiligen Modells ab. Besonders private kommerzielle Codebases bieten hier eine stärkere Trennung als lediglich nicht veröffentlichte Benchmark-Tasks.

Held-out Daten und private Aufgaben reduzieren also Contamination-Risiken. Sie machen einen Benchmark nicht automatisch fehlerfrei.

Und dann wurde SWE-bench Pro selbst auditiert

Im Juli 2026 veröffentlichte OpenAI einen Audit von SWE-bench Pro. Das ist besonders interessant, weil OpenAI wenige Monate zuvor selbst empfohlen hatte, von Verified auf Pro zu wechseln. [4][7]

Für die neue Analyse untersuchte OpenAI die 731 Aufgaben des öffentlichen SWE-bench-Pro-Splits. Eine automatisierte Analysepipeline markierte 200 Aufgaben beziehungsweise 27,4 Prozent als problematisch. In der anschließenden Human-Annotation wurden bei 249 Aufgaben beziehungsweise 34,1 Prozent relevante Probleme identifiziert. OpenAI fasste die eigene Einschätzung deshalb vorsichtig als ungefähr 30 Prozent problematische beziehungsweise „broken“ Tasks zusammen und zog die vorherige pauschale Empfehlung für SWE-bench Pro wieder zurück. [7]

Die gefundenen Probleme umfassten zu strenge Tests, unterspezifizierte Prompts, Tests mit zu geringer Abdeckung und in einzelnen Fällen irreführende Aufgabenbeschreibungen. Diese Zahlen stammen aus OpenAIs Audit. Sie bedeuten nicht, dass exakt 30 Prozent des gesamten SWE-bench-Pro-Benchmarks objektiv und unumstritten unbrauchbar sind; bereits die unterschiedlichen Ergebnisse von automatisierter Analyse und menschlicher Annotation zeigen, dass die Einordnung selbst Bewertungsarbeit erfordert.

Gerade deshalb ist der Vorgang lehrreich. SWE-bench Pro wurde nicht wertlos, weil jemand Probleme darin gefunden hat. Der Audit zeigt vielmehr, wie schwierig es ist, reale Softwareänderungen gleichzeitig realistisch, reproduzierbar und automatisch bewertbar zu machen.

Das Messen realer Softwareentwicklung ist selbst ein schwieriges Software-Engineering-Problem.

Ein sehr aktuelles Beispiel findet sich auch bei SWE-bench Multimodal. Die ursprüngliche Version enthielt 517 Issues mit visuellen Informationen. Am 1. September 2026 veröffentlichte das SWE-bench-Team Version 2 mit 480 für reproduzierbare Evaluation ausgewählten Tasks. Bekannte flakey oder nicht zuverlässig bewertbare Tests wurden entfernt, Docker-Umgebungen gegen Dependency- und Browser-Drift neu aufgebaut und JavaScript-Grading sowie die Verarbeitung visueller Test-Assets robuster gemacht. [14]

Ein Benchmark ist damit weniger ein in Stein gemeißeltes Lineal als ein technisches Produkt, das selbst gewartet werden muss.

Modellscore oder Systemscore?

Damit kommen wir zu einem Punkt, der bei Coding Agents besonders leicht übersehen wird. Ein agentischer Coding-Benchmark misst häufig nicht das nackte Basismodell.

Zwischen dem Modell und dem fertigen Patch liegt eine ganze Laufzeitumgebung. Sie entscheidet beispielsweise, welche Dateien gesucht werden können, welche Tools verfügbar sind, wie Shell-Befehle ausgeführt werden, wie Testergebnisse zurück zum Modell gelangen, wie Context verwaltet wird und wie viele weitere Versuche ein Agent unternehmen darf.

Als Denkmodell kann man sich den Score deshalb so vorstellen:

Das ist selbstverständlich keine mathematische Gleichung. Die Bestandteile lassen sich nicht einfach addieren. Sie erinnert aber daran, dass der beobachtete Score aus dem Zusammenspiel eines Systems entsteht.

Gerade unser Qwen-Beispiel demonstriert das ungewöhnlich sauber. Qwen gibt nicht nur das Modell an, sondern Claude Code als Harness, ein 256K Context Window sowie konkrete Sampling-Parameter. Zusätzlich wurde ein korrigierter Task-Stand verwendet. [1]

Wenn wir daraus nur 61,7 % übernehmen, werfen wir einen großen Teil der Versuchsbeschreibung weg.

Harness – das Modell bekommt eine Arbeitsumgebung

Den Begriff Agent Harness haben wir im vorherigen Artikel bereits eingeführt. Er bezeichnet die Laufzeit- und Kontrollschicht rund um das Modell.

Ein Harness kann Dateien durchsuchen, Tool-Aufrufe strukturieren, Shell-Ausgaben zurückführen, Context verwalten, Iterationen organisieren und festlegen, wann beziehungsweise wie ein Agent eine Aufgabe beendet. Zwei Agenten mit demselben Basismodell können dadurch unterschiedlich erfolgreich sein.

Das ist kein störender Nebeneffekt, den man aus Benchmarks grundsätzlich entfernen müsste. Bei einem Coding Agent gehört das Harness zum System. Wenn besseres Tooling dem Modell ermöglicht, schneller die relevante Datei zu finden oder einen fehlgeschlagenen Test sinnvoller zu interpretieren, ist das für reale Nutzung durchaus wertvoll.

Problematisch wird es erst, wenn wir den daraus entstandenen Systemscore anschließend ausschließlich dem Basismodell zuschreiben.

Aktuelle Leaderboards versuchen diese Variable teilweise zu kontrollieren. Das SWE-bench-Team bietet für Verified beispielsweise eine Bash Only-Ansicht, in der Modelle innerhalb derselben mini-SWE-agent-Umgebung verglichen werden. [3] Damit verschwinden nicht alle Unterschiede, aber zumindest ein Teil der Harness-Variation wird standardisiert.

Pass@1 und Pass@k

Eine weitere kleine Angabe hinter einem Benchmark kann die Interpretation erheblich verändern: das k.

Pass@1 betrachtet vereinfacht die Erfolgswahrscheinlichkeit bei einem einzelnen Versuch. Pass@k beschreibt beziehungsweise schätzt, wie häufig unter mehreren erzeugten Kandidaten mindestens einer erfolgreich ist. Das Konzept wurde unter anderem durch die HumanEval-Evaluation von Codex verbreitet. [8]

Wenn ein System pro Versuch eine bestimmte Erfolgschance besitzt, steigt mit mehreren Versuchen natürlich die Chance, mindestens eine erfolgreiche Lösung zu erzeugen. Acht Kandidaten zu erzeugen und anschließend einen erfolgreichen auszuwählen ist deshalb ein anderes Experiment als genau einen Versuch zuzulassen.

Das macht pass@8 nicht schlechter als pass@1. Für reale Produkte kann es sogar völlig sinnvoll sein, mehrere Lösungen parallel zu erzeugen und anschließend automatisch oder durch Menschen auszuwählen. Entscheidend ist lediglich, dass wir zwei Zahlen nicht behandeln, als hätten beide Systeme dieselbe Anzahl Chancen erhalten.

Das k ist damit keine statistische Fußnote, sondern Teil der Versuchsanordnung.

Token- und Compute-Budget

Ähnlich verhält es sich mit dem Rechenbudget. Ein Agent, der eine Aufgabe mit wenigen Iterationen und 50.000 Tokens bearbeitet, arbeitet unter anderen Bedingungen als ein Agent, der Millionen Tokens, zahlreiche Tool Calls und viele weitere Schritte verwenden darf.

Mehr Compute ist dabei nicht grundsätzlich schlecht. Wenn zusätzliche Inference zuverlässig bessere Ergebnisse erzeugt und der reale Anwendungsfall dieses Budget erlaubt, kann das eine vollkommen sinnvolle technische Entscheidung sein.

Für einen Benchmarkvergleich müssen wir trotzdem wissen, welche Ressourcen den jeweiligen Systemen zur Verfügung standen. Sonst vergleichen wir nicht nur Fähigkeiten, sondern gleichzeitig unterschiedliche Mengen erlaubter Arbeit.

Wie groß diese Unterschiede sein können, zeigt die auf dem SWE-rebench-Leaderboard veröffentlichte Auswertung zum Tokenverbrauch (abgerufen am 10. September 2026). Dort variiert der Tokenverbrauch verschiedener Agent-Systeme um mehr als den Faktor 30, obwohl sie auf derselben Aufgabenfamilie verglichen werden. [12]

Ob sich dieses zusätzliche Budget wirtschaftlich lohnt, ist eine andere Frage. Sie bekommt später in dieser Serie ihren eigenen Platz.

Sogar die Infrastruktur kann Punkte erzeugen

Bei klassischen Text-Benchmarks ist die Maschine, auf der eine Antwort erzeugt wird, häufig weitgehend unsichtbar. Ein Coding Agent arbeitet dagegen aktiv in seiner Umgebung. Er installiert Dependencies, startet Compiler, führt Tests aus und kann speicher- oder CPU-intensive Prozesse erzeugen.

Anthropic untersuchte diesen Effekt Anfang 2026 mit Terminal-Bench 2.0. Bei identischem Modell, identischem Harness und demselben Task-Set wurde die Ressourcenkonfiguration variiert. Zwischen der knappsten und großzügigsten getesteten Infrastruktur lagen sechs Prozentpunkte. Selbst innerhalb moderaterer Konfigurationen blieb eine Streuung von knapp zwei Punkten. [9]

Das heißt nicht, dass jeder Benchmarkscore um sechs Punkte falsch liegt. Es zeigt, dass die Runtime bei agentischen Evals Teil der Versuchsanordnung ist. Ein Prozess, der wegen eines Memory-Limits beendet wird, erscheint im Endergebnis ebenfalls als nicht gelöster Task, obwohl die Ursache eine andere ist als bei einer fachlich falschen Lösung.

Bei Leaderboard-Abständen von ein oder zwei Prozentpunkten lohnt sich deshalb Zurückhaltung bei Formulierungen wie „Modell A schlägt Modell B eindeutig“.

Wenn sich der Benchmark selbst ändert

Terminal-Bench liefert dafür 2026 noch ein zweites gutes Beispiel. Version 2.1 korrigierte 28 der 89 Aufgaben aus Terminal-Bench 2.0 und führte eine kontinuierliche Validierung ein. Bei der erneuten Evaluation veränderten sich einige Scores erheblich. Claude Opus 4.6 mit Claude Code stieg in der veröffentlichten Gegenüberstellung beispielsweise von 58,0 auf 70,1 Prozent. [10]

Das Modell ist dadurch nicht plötzlich intelligenter geworden. Der Benchmark wurde verändert und sollte danach fairer beziehungsweise reproduzierbarer messen.

Die Bezeichnung „Terminal-Bench“ allein reicht dabei nicht aus: Die offizielle Benchmark-Übersicht führt bereits Terminal-Bench 3.0, während die hier herangezogene Qwen3.8-Modellkarte weiterhin Terminal-Bench 2.1 verwendet. [1][10] Entscheidend für einen Vergleich sind die konkrete Version und die jeweilige Versuchsanordnung, nicht die Annahme einer einzigen „aktuellen“ Referenz.

Wer einen „Terminal-Bench-Score“ zitiert, sollte deshalb auch Version und Versuchsanordnung nennen. Werte verschiedener Versionen und Setups sind nicht unmittelbar miteinander vergleichbar.

Versionsnummern bei Benchmarks sind keine Pedanterie. Sie gehören zur Messgröße.

Ein höherer Score ist noch keine Beschaffungsentscheidung

Kehren wir für einen Moment zu unserem Ausgangsbeispiel zurück. Qwen3.8-27B besitzt 27 Milliarden Parameter; seine Modellgewichte stehen unter Apache 2.0 zur Verfügung, und die Model Card beschreibt verschiedene Wege, das Modell auf eigener Infrastruktur zu betreiben. [1]

Ein Entscheider könnte deshalb auf zwei Zahlen schauen:

Qwen3.8-27B:      61,7 %
Claude Opus 4.6:  53,4 %

und daraus ableiten, dass einige eigene GPU-Systeme offenbar die bessere Wahl als kommerzielle Cloud-Modelle seien.

Der Benchmark allein trägt diese Entscheidung nicht. Dafür müssten zusätzlich das tatsächliche Aufgabenprofil, benötigte Fähigkeiten, Datenhoheit, Datenschutz, Geheimhaltung, Betrieb, Parallelität, Latenz, Context-Anforderungen, Kosten und späterer Review-Aufwand betrachtet werden.

Auch die lokale beziehungsweise self-hosted Verarbeitung hat eine präzisere Bedeutung, als „die Daten bleiben im Haus“ manchmal vermuten lässt. Self-hosted Inference ermöglicht vollständig interne Verarbeitung, wenn auch Tooling, Telemetrie, Monitoring, Retrieval und sämtliche weiteren beteiligten Komponenten entsprechend betrieben und konfiguriert werden.

Umgekehrt folgt aus einem höheren allgemeinen Benchmarkscore auch nicht, dass für jede Entwicklungsaufgabe das stärkste verfügbare Frontier Model eingesetzt werden sollte. Für eine eng begrenzte und gut spezifizierte Implementierungsaufgabe kann ein kleineres Modell vollkommen ausreichend sein, während andere Aufgaben deutlich höhere Anforderungen an Analyse oder Exploration stellen können.

Das sind wichtige Entscheidungen. Sie werden nur nicht von SWE-bench Pro beantwortet.

Unterschiedliche Benchmarks stellen unterschiedliche Fragen

SWE-bench ist deshalb nicht schlecht, weil er nicht sämtliche Softwareentwicklung abbildet. Kein einzelner Benchmark kann das sinnvoll leisten.

Interessanter wird die Landschaft, wenn wir Benchmarks als unterschiedliche Messinstrumente betrachten:

Benchmark	Welche Fähigkeit wird ungefähr untersucht?
SWE-bench Pro	Änderungen an bestehenden Repositories anhand realitätsnaher Software-Engineering-Aufgaben
Terminal-Bench	mehrstufige Arbeit in Terminal-Umgebungen mit Tools, Programmen und Systeminteraktion
SWE-Lancer	reale ehemals bezahlte Freelance-Softwareaufgaben sowie technische Entscheidungsaufgaben
LiveCodeBench	fortlaufend neue algorithmische Coding-Aufgaben mit zeitlicher Trennung zur Reduktion von Contamination
SWE-rebench	kontinuierlich neu gewonnene Repository-Aufgaben für frischere Software-Engineering-Evaluation
SWE-bench Multilingual	SWE-bench-artige Repository-Aufgaben über mehrere Programmiersprachen hinweg
SWE-bench Multimodal	Repository-Issues, bei denen visuelle Informationen Teil der Anforderung sind

Terminal-Bench erweitert den Aktionsraum über Repository-Patches hinaus. Ein Agent arbeitet in einer Terminal-Umgebung und muss beispielsweise Software bauen, Konfiguration verändern, Programme ausführen oder mit vorhandenen Tools interagieren. Die umfangreiche Überarbeitung von Version 2.0 zu 2.1 zeigt gleichzeitig, wie anspruchsvoll die reproduzierbare Evaluation solcher Umgebungen ist. [9][10]

SWE-Lancer setzt einen anderen Akzent. Der Benchmark enthält mehr als 1.400 reale Freelance-Aufgaben von Upwork, denen insgesamt rund eine Million US-Dollar tatsächlicher Vergütung zugeordnet waren. Die Aufgaben reichen von 50-Dollar-Bugfixes bis zu Feature-Implementierungen im Wert von 32.000 Dollar. Zusätzlich enthält der Benchmark Management-Aufgaben, bei denen technische Lösungsvorschläge bewertet werden müssen. [11] Der monetäre Bezug macht ihn für bestimmte Fragestellungen interessant, ist aber ebenfalls kein allgemeiner „Wert eines Entwicklers“.

LiveCodeBench versucht vor allem das Zeitproblem statischer Coding-Benchmarks zu reduzieren. Neue Aufgaben werden kontinuierlich aus Programmierwettbewerben wie LeetCode, AtCoder und Codeforces gesammelt und mit ihrem Veröffentlichungsdatum versehen. Damit können Modelle auf Aufgaben getestet werden, die nach einem bekannten Trainings-Cutoff erschienen sind. [13] Gleichzeitig misst der Benchmark vor allem algorithmische Coding-Fähigkeiten und verwandte Aufgaben wie Code Execution oder Self-Repair. Das ist etwas anderes als die Arbeit in einer zehn Jahre alten Enterprise-Codebase.

SWE-rebench verfolgt Freshness direkt auf Repository-Ebene. Die ursprüngliche Veröffentlichung von 2025 sammelte mehr als 21.000 interaktive Python-Aufgaben aus über 3.400 Repositories und nutzte fortlaufend neue Tasks für contamination-resistentere Evaluation. Inzwischen erweitert SWE-rebench V2 die Sammlung deutlich: Die 2026 veröffentlichte Version beschreibt mehr als 32.000 ausführbare Tasks aus über 3.600 Repositories und 20 Programmiersprachen; zusätzlich wurden mehr als 120.000 weitere Tasks mit Installationsinformationen und Metadaten veröffentlicht. [12] Das Grundprinzip bleibt: Ein dynamischer Nachschub frischer Aufgaben soll verhindern, dass ein einziger statischer Datensatz über Jahre zum Prüfungsbogen der gesamten Branche wird.

SWE-bench Multilingual erweitert die sprachliche Abdeckung. Er enthält 300 kuratierte Aufgaben aus 42 Repositories und neun Programmiersprachen: C, C++, Go, Java, JavaScript, TypeScript, PHP, Ruby und Rust. [15] Das ist relevant, weil ein weitgehend Python-basierter Benchmark wenig darüber sagt, wie zuverlässig dieselben Fähigkeiten auf andere Ökosysteme übertragen werden.

SWE-bench Multimodal stellt schließlich eine andere Frage: Was passiert, wenn die Anforderung nicht vollständig im Text steckt? Screenshots eines Fehlers, Design-Mockups, Wireframes oder Diagramme sind gerade in Frontend-Projekten ganz normale Bestandteile der Arbeit. Die am 1. September 2026 veröffentlichte Version 2 umfasst 480 für reproduzierbare Evaluation ausgewählte Tasks. [14]

Keiner dieser Benchmarks ist damit „der beste“. Sie stellen unterschiedliche Fragen.

Ein öffentlicher Benchmark ist eine Landkarte, nicht das eigene Gelände

Öffentliche Benchmarks sind enorm nützlich, wenn wir uns einen ersten Überblick verschaffen wollen. Ein Modell, das auf mehreren für unseren Anwendungsfall relevanten Coding-Evals deutlich zurückliegt, liefert ein anderes Signal als eines, das über verschiedene Messinstrumente hinweg stark abschneidet.

Für eine konkrete Organisation kann die entscheidende Frage trotzdem anders aussehen.

Vielleicht besteht der Großteil der Arbeit nicht aus Python-Bugfixes, sondern aus Angular-Migrationen. Vielleicht ist das Repository riesig, die Architektur stark modularisiert und eine zentrale Anforderung besteht darin, bestehende Boundaries nicht zu verletzen. Vielleicht sollen Agents vor allem Tests ergänzen, Legacy-Code analysieren oder Änderungen in einer proprietären .NET-Codebase vorbereiten.

Dann können eigene Evals erheblich relevanter werden.

Ein internes Eval muss kein neuer wissenschaftlicher Weltbenchmark sein. Schon eine kleine, reproduzierbare Sammlung repräsentativer Aufgaben kann zeigen, wie verschiedene Modell-Agent-Systeme mit der eigenen Realität umgehen: ein typischer Bugfix, ein Feature, ein Refactoring, eine Migration, Testergänzungen oder eine Repository-Analyse.

Entscheidend ist dabei dieselbe Disziplin wie bei öffentlichen Benchmarks. Welche Aufgabe bekommt das System? Welcher Repository-Zustand wird verwendet? Welche Tools sind erlaubt? Welches Budget erhält der Agent? Wie wird Erfolg bewertet? Und wer prüft, ob die eigene Evaluation tatsächlich das misst, was für die Organisation relevant ist?

Öffentliche Benchmarks helfen uns, Modelle einzuordnen. Eigene Evals helfen uns, konkrete Entscheidungen vorzubereiten.

Zurück zu 61,7 Prozent

Am Anfang standen zwei Zahlen:

Qwen3.8-27B      61,7 %
Claude Opus 4.6  53,4 %

Nach allem, was wir inzwischen wissen, sind diese Zahlen nicht weniger interessant. Qwen3.8-27B erreicht in seiner veröffentlichten Evaluation einen bemerkenswerten SWE-bench-Pro-Wert für ein Modell dieser Größe. Dass die Modellgewichte verfügbar sind und sich das Modell auf eigener Infrastruktur betreiben lässt, macht das Ergebnis technisch und strategisch durchaus relevant. [1]

Die Zahlen sollten lediglich weniger magisch wirken.

Wir wissen jetzt, dass Qwens 61,7 % auf ScaleAI/SWE-bench_Pro berichtet werden und mit Claude Code, konkreten Sampling-Einstellungen, einem 256K Context Window sowie einem korrigierten Task-Stand entstanden sind. Wir wissen ebenfalls, dass die 53,4 % für Claude Opus 4.6 in derselben Qwen-Tabelle nicht aus demselben Lauf stammen, sondern als offiziell berichteter Anthropic-Wert übernommen wurden. [1][2]

Wir wissen, dass SWE-bench Pro reale Repository-Arbeit besser approximiert als viele klassische isolierte Coding-Aufgaben, aber nicht sämtliche Softwareentwicklung misst. Wir wissen, warum zurückgehaltene und private Daten Contamination-Risiken reduzieren können und warum selbst ein neuer Benchmark weiterhin fehlerhafte Tasks enthalten kann. Und wir wissen, dass Harness, Tools, Compute-Budget und sogar Infrastruktur das Ergebnis beeinflussen können.

Damit verliert der Benchmark nicht seinen Wert. Im Gegenteil: Erst wenn wir seine Grenzen kennen, können wir die gemessene Information sinnvoll verwenden.

Benchmarks sind nützlich, wenn wir verstehen, was sie messen. Gefährlich werden sie dort, wo wir aus einer gut messbaren Zahl etwas ableiten, das der Benchmark nie gemessen hat.

Ein Benchmark ist kein Urteil über ein Modell. Er ist ein Messinstrument.

Und eine weitere Erkenntnis haben wir beinahe nebenbei gewonnen: Sobald ein Coding Agent bewertet wird, sprechen wir kaum noch über das Modell allein. Context, Tools, Harness, gespeicherter Zustand und die Art, wie ein System Informationen bereitstellt, beeinflussen seine Arbeit erheblich.

Bevor wir deshalb später untersuchen, warum dasselbe Modell unterschiedliche Lösungen erzeugen kann, müssen wir zunächst klären, was diese Schichten eigentlich voneinander unterscheidet: Context, Memory, Skills und Agents.

Darum geht es im nächsten Artikel.

Quellen

[1] Qwen Team: Qwen3.8-27B Model Card. Hugging Face, 2026; einschließlich der am 14. August 2026 veröffentlichten Eval-Metadaten für ScaleAI/SWE-bench_Pro.

[2] Anthropic: Project Glasswing: Securing critical software for the AI era. 2026. Dort berichteter SWE-bench-Pro-Wert für Claude Opus 4.6: 53,4 %.

[3] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan: SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024; ergänzend offizielle SWE-bench-Dokumentation und Leaderboards, Stand September 2026.

[4] OpenAI: Why SWE-bench Verified no longer measures frontier coding capabilities. 23. Februar 2026.

[5] OpenAI: Introducing SWE-bench Verified. 13. August 2024.

[6] Scale AI Research Team: SWE-Bench Pro: Raising the Bar for Agentic Coding. 19. September 2025.

[7] OpenAI: Separating signal from noise in coding evaluations. 8. Juli 2026.

[8] Mark Chen et al.: Evaluating Large Language Models Trained on Code. 2021. arXiv:2107.03374.

[9] Gian Segato / Anthropic: Quantifying infrastructure noise in agentic coding evals. Anthropic Engineering, 5. Februar 2026.

[10] Terminal-Bench Team: Terminal-Bench 2.1, Release Notes, 6. Mai 2026; ergänzend Terminal-Bench 3.0 und die Benchmark-Übersicht, abgerufen am 10. September 2026. Die Versionsangaben gehören jeweils zur konkreten Evaluation.

[11] Samuel Miserendino, Michele Wang, Tejal Patwardhan, Johannes Heidecke: SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering? ICML 2025.

[12] Ibragim Badertdinov et al.: SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. 2025. arXiv:2505.20411; Ibragim Badertdinov et al.: SWE-rebench V2: Language-Agnostic SWE Task Collection at Scale. 2026. arXiv:2602.23866; ergänzend SWE-rebench-Leaderboard, Auswertung zum Tokenverbrauch, abgerufen am 10. September 2026. Der dynamische Leaderboard ist keine unveränderliche Benchmark-Zeitreihe.

[13] Naman Jain et al.: LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. 2024. arXiv:2403.07974.

[14] John Yang, Carlos E. Jimenez, Alex L. Zhang et al.: SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? ICLR 2025; SWE-bench Multimodal v2 vom 1. September 2026.

[15] Kabir Khandpur, Kilian Lieret, Carlos E. Jimenez, Ofir Press, John Yang: SWE-bench Multilingual. 300 kuratierte Aufgaben aus 42 Repositories und neun Programmiersprachen.