Claude Opus 4.7 vs. GPT-5.5 Spud: Was Benchmarks wirklich beweisen

Was ein Benchmark leisten kann — und was nicht

Ein Benchmark kann zeigen, wie ein Modell auf einem bestimmten Aufgabenset abgeschnitten hat: mit einem bestimmten Testaufbau, einer bestimmten Bewertungsmethode, definierten Tools, Zugriffseinstellungen und Wiederholungsregeln. Er beweist aber nicht automatisch, dass ein Modell grundsätzlich und überall überlegen ist.

Diese Einschränkung ist wichtig, weil die Forschung zu LLM-Evaluationen vor Problemen statischer Benchmarks warnt: Sättigungseffekte, Datenkontamination und begrenzte unabhängige Replikation können Ergebnisse verzerren. Besonders heikel wird das, wenn eine Seite des Vergleichs dokumentiert ist und die andere nicht über Primärquellen bestätigt wurde.

Für eine belastbare Aussage zu Claude Opus 4.7 vs. GPT-5.5 Spud wären mindestens nötig:

1. eine primäre OpenAI-Quelle, die Spud bestätigt,
2. eine stabile Modellkennung für Spud,
3. reproduzierbare Zugangsbedingungen für beide Modelle,
4. offengelegte Benchmark-Einstellungen, inklusive Prompts, Tools, Wiederholungen und Scoring,
5. unabhängige Replikation unter vergleichbaren Bedingungen.

Die hier vorliegenden Spud-Quellen erfüllen diesen Standard nicht.

Warum Kontamination Rankings verändern kann

Benchmark-Kontamination und Datenleckagen sind nicht nur akademische Fußnoten. Ein hoher Score kann auch dadurch entstehen, dass ein Modell Testmaterial, Lösungsmuster oder öffentlich diskutierte Benchmark-Artefakte bereits gesehen hat — statt durch robuste allgemeine Fähigkeit. Neuere Benchmark-Arbeiten weisen wiederholt auf dieses Risiko hin, besonders bei statischen oder öffentlich bekannten Datensätzen.

Eine spätere Übersicht zu LLM-Benchmarks nennt dynamische Benchmark-Designs wie LiveBench als Möglichkeit, das Risiko von Datenleckagen zu senken. Das macht kein einzelnes Leaderboard endgültig. Aber regelmäßig aktualisierte, kontaminationsarme Tests sind für Frontier-Modelle aussagekräftiger als alte statische Benchmarks.

LiveBench ist ein starkes Signal, aber kein Endurteil

LiveBench gehört in den vorliegenden Quellen zu den stärkeren öffentlichen Benchmark-Designs. Der Test setzt auf kontaminationsbegrenzte Aufgaben, häufig aktualisierte Fragen aus aktuellen Quellen, prozedurale Fragengenerierung und objektives Ground-Truth-Scoring. Die Website verlinkt außerdem Leaderboard, Details, Code, Daten und Paper, wodurch die Evaluation besser prüfbar ist als ein isoliertes Launch-Diagramm.

Trotzdem sollte LiveBench als starkes öffentliches Signal verstanden werden — nicht als alleinige Einkaufs- oder Architekturentscheidung. Ein öffentlicher Benchmark kann die Vorauswahl verbessern. Er ersetzt aber keine Tests mit den eigenen Prompts, dem eigenen Codebestand, realistischen Latenzgrenzen, Kostenrestriktionen und Fehlertoleranzen.

SWE-bench ist nützlich — aber schnell überinterpretiert

SWE-bench-artige Evaluationen sind wertvoll für Coding- und Software-Engineering-Agenten. Der Name allein reicht aber nicht. Variante, Harness, Toolzugriff, Zustand des Repositorys, Retry-Politik und Scoring-Setup können das Ergebnis deutlich verändern.

SWE-bench Live wurde entwickelt, um Pretraining-Kontamination zu reduzieren: Die Aufgaben sind auf Issues beschränkt, die zwischen dem 1. Januar 2024 und dem 20. April 2025 erstellt wurden; zugleich weisen die Autoren darauf hin, dass Leaderboard-Setups erheblich voneinander abweichen können. SWE-bench Pro wird als anspruchsvollerer, kontaminationsresistenter Benchmark für längerfristige Software-Engineering-Aufgaben vorgestellt.

Die Warnhinweise sind erheblich. SWE-Bench++ argumentiert, dass Open-Source-Software-Benchmarks ein kritisches Kontaminationsrisiko tragen und dass geleakte Lösungen Leaderboard-Rankings verzerren können. Eine Analyse der SWE-bench-Leaderboards aus dem Jahr 2026 berichtet zudem über aktuelle SWE-bench-Verified-Einreichungen mit Datenkontamination.

Hinzu kommt ein Sättigungsproblem. Ein Paper zu Benchmarking-Infrastruktur berichtet, dass Ergebnisse auf SWE-bench Verified bei SWE-bench Pro auf 23 % fallen können. SWE-ABS argumentiert außerdem, dass das SWE-bench-Verified-Leaderboard an Sättigung heranrückt und überhöhte Erfolgsraten zeigen kann, solange Aufgaben nicht adversarial verstärkt werden.

Eine praktische Leiter für Benchmark-Vertrauen

Öffentliche Benchmarks sollten Filter sein, keine endgültigen Urteile. Eine sinnvolle Gewichtung sieht so aus:

So sollten Teams vor einem Modellwechsel testen

Wer Claude Opus 4.7 mit einem Modell von OpenAI, Google, Anthropic oder einem offenen Modell vergleichen will, sollte mit Quellenqualität beginnen und mit der eigenen Arbeitslast enden.

1. Exakte Modellkennung prüfen. Für Claude Opus 4.7 dokumentiert Anthropic claude-opus-4-7 für die Claude API. Für GPT-5.5 Spud liefert diese Quellenlage keine primäre OpenAI-Modellkennung.
2. Für jedes Modell denselben Harness verwenden. SWE-bench Live weist ausdrücklich darauf hin, dass Leaderboard-Setups stark abweichen können; unterschiedliche Setups erzeugen leicht Scheingenauigkeit.
3. Aktuelle, private oder kontaminationsresistente Aufgaben bevorzugen. Dynamische Benchmarks und kontaminationsresistente Software-Engineering-Benchmarks sollen Leckagerisiken reduzieren.
4. Praktische Grenzen protokollieren. Dazu gehören Retries, Latenz, Kosten, Tool-Rechte, Fehlermodi und die Frage, ob das Modell eine Aufgabe sauber löst oder erst nach teuren Umwegen.
5. Evaluation wiederholen. Ein einzelner Leaderboard-Wert sollte als Hypothese gelten, bis interne Tests oder unabhängige Replikation ihn stützen.

Was das Urteil ändern würde

Das Fazit würde sich ändern, wenn die Quellenlage eine primäre OpenAI-Ankündigung, Modellkarte, Systemkarte oder API-Dokumentation zu GPT-5.5 Spud enthielte — plus stabile Modellkennung, reproduzierbaren Zugang und unabhängige Benchmark-Einträge mit vergleichbaren Harnesses und Tool-Rechten.

Noch stärker wäre die Evidenz, wenn diese Einträge in kontaminationsbegrenzten oder kontaminationsresistenten Evaluationen wie LiveBench, SWE-bench Live oder SWE-bench Pro auftauchten und unabhängige Teams die Ergebnisse reproduzieren könnten.

Wichtige Grenzen dieser Analyse

Diese Analyse ist auf die bereitgestellten Quellen beschränkt. Dass hier keine primäre OpenAI-Quelle für GPT-5.5 Spud vorliegt, beweist nicht, dass es anderswo keine gibt. Es bedeutet nur: In diesem Material ist die Behauptung nicht verifiziert.

Mehrere hier zitierte Arbeiten zur Benchmark-Methodik sind arXiv-, OpenReview- oder SSRN-Einträge und keine finalen Journalartikel. Sie sind nützlich, um Evaluationsdesign, Kontaminationsrisiken und Replikationsprobleme zu verstehen; ihr Publikationsstatus sollte aber mitgedacht werden.

Fazit

Claude Opus 4.7 ist in den vorliegenden Quellen belegt; GPT-5.5 Spud ist hier nicht durch primäre OpenAI-Dokumentation verifiziert. Ein Sieger im Vergleich Claude Opus 4.7 vs. GPT-5.5 Spud sollte deshalb nicht veröffentlicht werden, solange Spud nicht bestätigt, unter stabiler Modellkennung zugänglich und unter vergleichbaren Bedingungen getestet ist.

Für die Modellauswahl zählt am meisten: kontaminationsbegrenzte oder kontaminationsresistente Benchmarks mit prüfbaren Methoden, plus wiederholte Tests auf der eigenen Arbeitslast. LiveBench, SWE-bench Live und SWE-bench Pro sind informativer als statische oder reine Hersteller-Charts — aber auch sie ersetzen keine kontrollierte interne Evaluation.