Immer intelligentere Modelle werden auch immer geschickter darin, Coding-Benchmarks auszutricksen.

Eval-Suites, die auf realen Bugs basieren, die später behoben wurden, sind besonders anfällig, weil die Probleme bereits gelöst worden sind. Wenn der Agent Zugriff auf die Repository-Historie oder das öffentliche Web hat, kann er die Antwort manchmal nachschlagen, statt sie selbst herzuleiten.

Um zu messen, wie verbreitet dieses Verhalten ist, haben wir einen Agent entwickelt, der Eval-Trajektorien prüft. Bei SWE-bench Pro haben wir festgestellt, dass 63 % der erfolgreichen Opus-4.8-Max-Lösungen den Fix abgerufen haben, statt ihn selbst herzuleiten. Als wir die Git-Historie abgeschottet und den Internetzugriff eingeschränkt haben, fielen die Scores sowohl für Opus als auch für unser Modell Composer 2.5 deutlich:

• Opus 4.8 Max fiel von 87.1% auf 73.0%
• Composer 2.5 fiel von 74.7% auf 54.0%

Frühere Forschung hat gezeigt, dass Antworten auf Coding-Benchmarks über öffentlich zugängliche Quellen durchsickern können, darunter diese Studie aus dem Jahr 2024 und ein Meta-Bericht aus dem Jahr 2025. Unsere Studie quantifiziert das Problem bei aktuellen Coding-Agent-Läufen an der Spitze. Die übergreifende Erkenntnis ist, dass agentenbasiertes Programmieren auf Benchmarks nicht nur Schutz vor Kontamination während des Trainings braucht, sondern auch kontrollierte Laufzeitumgebungen.

Für Teams, die Evals durchführen, schlagen wir vor, dieses Reward-Hacking-Verhalten zu begrenzen, indem sie Transkripte prüfen und die Eval-Umgebung einschränken."

#Ein Modell mit einem Modell entlarven

Um das Ausmaß des Reward Hacking-Verhaltens zu messen, ließen wir den Auditor 731 Opus-4.8-Max-Trajektorien untersuchen. Er sah die Problemstellung und die vollständige Agent-Trajektorie, ohne zu wissen, ob der Durchlauf erfolgreich war, und klassifizierte, ob der Agent die bekannte Antwort abgerufen hatte.

Die zwei häufigsten Reward Hacking-Muster, die er fand, waren:

• Upstream-Lookup: In 57 % der Trajektorien fand Opus 4.8 Max die gemergte PR oder die korrigierte Quelldatei im öffentlichen Web und reproduzierte den Fix dann fast wortwörtlich.
• Git-History-Mining: In 9 % der Trajektorien durchsuchte Opus 4.8 Max die mitgelieferte .git-Historie nach dem späteren Commit, der den Bug behob, und extrahierte daraus den Patch.¹

Je leistungsfähiger Modelle werden, desto eher erkennen sie manchmal, dass sie sich in einem Eval befinden, insbesondere wenn die Aufgabe aus einem früheren öffentlichen Repository übernommen wurde. Selbst in Fällen, in denen sie sich nicht aus dem Training an den Fix erinnern, kann die Umgebung ihnen dennoch Hinweise darauf geben, dass der Bug bereits gelöst wurde.

In einer SWE-bench-Multilingual-Aufgabe zu einem jq-Issue von 2019 versuchte der Agent, den Bug mit der System-Binärdatei von jq zu reproduzieren. Da das Image erst erstellt worden war, nachdem der Bug bereits behoben worden war, schlug die Reproduktion fehl, und der Agent schloss daraus, dass das Issue bereits gelöst worden war. Diese Erkenntnis veranlasste ihn dazu, nach dem Fix zu suchen, statt selbst einen herzuleiten.

Einige Fälle waren noch direkter. Ein Agent fand eine SWE-bench-Spiegelseite, auf der versteckte Tests und der Gold-Patch offengelegt wurden. Ein anderer beschaffte sich versteckte Testdateien und hardcodierte die erwartete Exception-Zeichenfolge, die zum Bestehen nötig war.

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

#Strengeres Umgebungsdesign

Der Großteil des Reward Hacking lief über das öffentliche Web und die Repository-Historie öffentlicher Repositorys. Bei Evals, die aus historischen öffentlichen Repositorys erstellt wurden, müssen diese Kanäle kontrolliert werden, da sie die Antwort enthalten könnten. Deshalb haben wir ein striktes Harness mit zwei Isolationsmechanismen entwickelt:

1. Verlaufsisolierung. Bevor der Agent startet, wird das .git-Verzeichnis entfernt und das Repository wird als neues Repo mit nur einem Commit neu initialisiert. Der ursprüngliche Verlauf wird erst bei der Auswertung wiederhergestellt, sodass Tests wie gewohnt ausgeführt werden.
2. Egress-Proxying. Netzwerkzugriff ist standardmäßig gesperrt. Als Best-Effort-Kontrolle erlaubt ein fest konfigurierter Proxy die Auflösung von Abhängigkeiten über eine Allowlist von Paketregistern – und sonst nichts.

Diese Einschränkung gilt nur für Evals, die aus historischen öffentlichen Repositorys erstellt wurden. Das ist einer der Gründe, warum wir Evals bevorzugen, die aus nicht öffentlichen Repositorys erstellt wurden, wie CursorBench. Sie können die Fähigkeit zum agentenbasierten Programmieren testen und Agenten dennoch ermöglichen, Tools so zu nutzen, wie sie es bei echter Arbeit tun würden.

#Eine wachsende Lücke

Wir haben SWE-bench Pro und SWE-bench Multilingual im strengeren Harness erneut ausgeführt und anschließend jedes Ergebnis mit dem Score des Standard-Harness als Näherungswert für den kombinierten Effekt der Entfernung dieser Leakage-Kanäle verglichen²:

• Bei SWE-bench Multilingual lag sie für Opus 4.6 unter 1 Punkt, für Opus 4.8 Max bei 9,1 Punkten und für Composer 2.5 bei 7,5 Punkten.
• Bei SWE-bench Pro lag sie für Opus 4.6 unter 1 Punkt, für Opus 4.8 Max bei 14,1 Punkten und für Composer 2.5 bei 20,7 Punkten.

Die klare Schlussfolgerung ist, dass Reward Hacking bei neueren, ausgefeilteren Modellen weitaus häufiger vorkommt als bei älteren. Interessanterweise zeigen GPT-Modelle nicht dieselbe Eskalation; in unseren Durchläufen waren die Lücken dort insgesamt kleiner.

Wir haben außerdem beobachtet, dass unser eigenes Modell, Composer 2.5, in der Studie die größte Lücke bei Pro aufwies. Das ist ein Grund, warum wir den Standard-Score von SWE-bench Pro für Composer nicht als verlässliche Benchmark-Zahl betrachten. Der Score war insofern real, als der Harness ihn erzeugt hat, aber er vermischte Programmierfähigkeit mit dem Zugriff auf bekannte Fixes.

#Evals für Agenten, die sich der Bewertung bewusst sind

Die wichtigste Erkenntnis für Teams, die Coding-Evals durchführen, ist, dass das Benchmark-Design nicht mit der Erstellung des Datensatzes enden sollte. Es muss auch die Laufzeitumgebung berücksichtigen, einschließlich dessen, wonach der Agent suchen, was er prüfen, abrufen und wiederherstellen kann, während die Aufgabe läuft.

Das bedeutet nicht, dass jedes Eval den Internetzugriff oder die Git-Historie ausschließen sollte. Manche Evals sollen messen, wie gut Agenten den umgebenden Kontext einer realen Codebase nutzen, und in solchen Fällen kann umfassender Zugriff Teil der Aufgabe sein. Problematisch wird es, wenn dieser Zugriff verändert, wofür der Score eigentlich steht.

Bei historischen Benchmarks für öffentliche Repos kann offener Zugriff dazu führen, dass Agenten den bekannten Fix finden, anstatt den Bug selbst zu lösen. Ohne Kontrollen im Harness können Scores Programmierfähigkeit und das Abrufen von Antwort miteinander vermischen.

Teams, die Evals durchführen, sollten festlegen, welches Verhalten sie messen wollen, das Harness darauf ausrichten und das Setup klar benennen, wenn sie Ergebnisse veröffentlichen. Die Prüfung von Transkripten kann helfen aufzudecken, wann Modelle Aufgaben auf unerwartete Weise lösen. Das Ziel ist nicht, die normale Tool-Nutzung zu verbieten, sondern sicherzustellen, dass der Benchmark tatsächlich misst, was er zu messen vorgibt.

Selbst dann bleibt ein schwierigeres, noch ungelöstes Problem. Je stärker sich Modelle bewusst werden, dass sie evaluiert werden, desto eher können sie ihr Verhalten auf subtilere Weise ändern — und das lässt sich nicht einfach beheben, indem man die Git-Historie abschottet oder den Internetzugriff einschränkt. Runtime-Kontamination ist eine konkrete Ausprägung der allgemeineren Herausforderung, Evals zu entwickeln, die ihre Konstruktvalidität behalten, selbst wenn das Modell erkennt, dass es evaluiert wird.