GPT-5.5 vs. GPT-5.4 vs. Opus 4.7 – Benchmark-Vergleich von 56 realen Coding-Aufgaben

• Veröffentlicht wurden Benchmark-Ergebnisse, die die Patch-Qualität der drei Modelle GPT-5.5, GPT-5.4 und Opus 4.7 anhand von 56 realen Coding-Aufgaben vergleichen, die aus zwei Open-Source-Repositories (Zod, graphql-go-tools) extrahiert wurden
• GPT-5.5 erzielte die besten Ergebnisse bei allen Kennzahlen: Test-Bestehensquote, Gleichwertigkeit mit menschlichen Patches und Code-Review-Bestehensquote (clean pass)
• Opus 4.7 erzeugt die kleinsten Patches und hat ein geringes Footprint-Risiko, zeigt aber ein wiederkehrendes Fehlermuster mit unvollständigen Implementierungen durch fehlende Begleitaufgaben
• Das Bestehen von Tests allein reicht nicht aus, um die Patch-Qualität zu beurteilen; nötig ist eine mehrschichtige Bewertung, die auch die Akzeptanz durch Reviewer einbezieht
• Da sich das Ranking desselben Modells je nach Repository verändert, ist ein Benchmark auf Basis der eigenen Codebasis entscheidend für die Modellauswahl

---

Benchmark-Überblick und Ausführungsumgebung

• Verglichen wurden drei Modelle anhand von insgesamt 56 realen Coding-Aufgaben: 27 aus Zod und 29 aus graphql-go-tools
• Jedes Modell wurde mit Standardeinstellungen in seinem offiziellen Agent-Harness ausgeführt: Opus 4.7 mit Claude Code, GPT-5.4 und GPT-5.5 mit OpenAI Codex CLI
• Das Reasoning-Level wurde bei allen Modellen einheitlich auf high gesetzt
• Mit dem Evaluierungs-Framework Stet wurde nicht nur das Bestehen von Tests bewertet, sondern mehrschichtig auch Verhaltensäquivalenz, Akzeptanz im Code Review, Footprint-Risiko sowie Rubriken für Handwerksqualität (craft) und Disziplin (discipline)
• Pro Aufgabe gab es genau einen Lauf mit einem einzelnen Seed; für Äquivalenz- und Rubrik-Bewertungen wurde GPT-5.4 verwendet

Zusammenfassung der Gesamtergebnisse

• GPT-5.5 belegte bei allen Kennzahlen Platz 1: 38/56 bestandene Tests, 40/56 Gleichwertigkeit mit menschlichen Patches und 28/56 clean pass
• Opus 4.7 erreichte 33/56 bestandene Tests, 19/56 Gleichwertigkeit und 10/56 clean pass und hatte damit die niedrigsten Qualitätswerte
  • Allerdings war es mit einem durchschnittlichen Footprint-Risiko von 0,20 beim Patch-Umfang am besten
• GPT-5.4 kam auf 31/56 bestandene Tests, 35/56 Gleichwertigkeit und 11/56 clean pass
  • Mit Kosten von 2,39 US-Dollar pro Aufgabe war es am günstigsten, konnte den Rückstand bei clean pass aber nicht ausgleichen
• GPT-5.5 war auch bei der Effizienz führend: durchschnittliche Aufgabenzeit 6 Minuten 56 Sekunden, 201,8M Input-Tokens und 0,72M Output-Tokens

Analyse nach Repository

• Zod (27 Aufgaben): GPT-5.5 und Opus lagen mit jeweils 12 bestandenen Tests gleichauf, aber GPT-5.5 war bei der Review-Qualität vorn mit 10 clean pass gegenüber 5 bei Opus
  • Opus war bei der Diff-Größe überlegen, sodass es bei Zod einen realen Trade-off gibt
• graphql-go-tools (29 Aufgaben): GPT-5.5 war mit 26 bestandenen Tests und 18 clean pass klar überlegen
  • Opus bestand zwar 21 Tests, kam aber nur auf 5 clean pass; die Strategie kleiner Patches führte hier zu ausgelassenen Integrationsarbeiten

Detaillierte Qualitätskennzahlen

• Im Code Review bestanden: GPT-5.5 33/56, GPT-5.4 16/56, Opus 11/56
• Durchschnitt im Code Review (Korrektheit + Bug-Sicherheit): GPT-5.5 3,08, GPT-5.4 2,59, Opus 2,33
  • Nur Korrektheit (correctness): GPT-5.5 3,16 vs. GPT-5.4 2,60 vs. Opus 2,11
  • Sicherheit bezüglich eingeführter Bugs: GPT-5.5 3,04 vs. GPT-5.4 2,56 vs. Opus 2,55
• Durchschnitt benutzerdefinierter Bewerter (8 Rubriken): GPT-5.5 2,62, GPT-5.4 2,40, Opus 2,33
• Beim Handwerksqualitäts-Score (clarity/coherence/robustness) lag GPT-5.5 in allen drei Unterkategorien vorn
• Beim Disziplin-Score (scope discipline/diff minimality) lag GPT-5.5 mit 2,36 knapp vor Opus mit 2,20
  • Opus war beim rohen Footprint zwar besser, doch bei relativer Disziplin bezogen auf die Aufgabe lag GPT-5.5 vorn

Bestandene Tests sind kein endgültiger Maßstab

• In Zod lagen Opus und GPT-5.5 mit jeweils 12 bestandenen Tests gleichauf, bei clean pass aber stand es 10 zu 5 für GPT-5.5
• In graphql-go-tools verstärkte sich dasselbe Muster: GPT-5.5 mit 26 bestandenen Tests und 18 clean pass, Opus mit 21 bzw. 5
• Im Fall GraphQL PR #1001 bestanden alle drei Modelle die Tests und wurden als äquivalent bewertet, aber nur GPT-5.5 bestand auch das Code Review
  • Die beiden anderen Modelle erhielten Warnungen zu API-Form, Freilegung roher HTTP-Objekte und Robustheit an Hook-Grenzen

Konkrete Unterschiede aus dem Code Review

• Asynchrone Codecs und Default-Werte in Zod: Alle drei Modelle scheiterten an den Tests
  • Opus änderte 8 Dateien, ließ aber zentrale Semantik aus (Zulassen von undefined bei Default-Werten, Beibehaltung synchroner Codec-Definitionen)
  • GPT-5.4 erhielt mit einem Patch über 11 Dateien Äquivalenz, schränkte aber eine benachbarte API (prefault) zu stark ein
  • Auch GPT-5.5 bestand die Tests nicht, deckte aber Schema-/Build-Verhalten sauberer ab und erhielt die höchste Bewertung bei Korrektheit und Bug-Risiko
• GraphQL-Apollo-Kompatibilitätsvalidierung (PR #1169): Alle drei Modelle bestanden die Tests, aber nur GPT-5.5 bestand sowohl Äquivalenz als auch Review
  • Opus änderte 11 Dateien und ließ die Validierung von enum-/wrapped-scalar-Blättern aus
  • GPT-5.4 änderte 12 Dateien und weitete den Scope mit bedingungslosen Validierungs-Metadaten zu stark aus
  • GPT-5.5 änderte mit 10 Dateien (davon 6 Nicht-Test-Dateien) am wenigsten und implementierte das Zielverhalten dennoch präzise

Eigenschaften und Grenzen von Opus 4.7

• Erzeugt konservative, präzise und Footprint-arme Patches
• Spielt seine Stärken aus, wenn Aufgaben lokal sind und die Änderungsoberfläche klein bleibt
• Wiederkehrendes Fehlermuster: Die Kernfunktion wird implementiert, aber Begleitaufgaben (companion work) werden nicht abgeschlossen
  • Beispiel parallele Node/Deno-Tree-Struktur in Zod: Opus änderte nur 4 Dateien und bestand damit die Tests; GPT-5.5 änderte 11 Dateien einschließlich der parallelen Auslieferungsoberfläche und war damit dem menschlichen Patch äquivalent
• In graphql-go-tools war das Problem gravierender: Bei PR #1155 (mehrere Änderungen an Engine-Oberflächen wie wiederholte skalare Felder in gRPC-Datasources) konnte Opus überhaupt keinen Patch erzeugen, während nur GPT-5.5 Tests, Äquivalenz und Review bestand
• Der zentrale Unterschied: Kleine Patches von Opus bedeuten bei lokalen Aufgaben Disziplin, bei Integrationsaufgaben aber unvollständige Implementierung

Veränderungen von GPT-5.4 zu GPT-5.5

• GPT-5.4 findet oft die richtige Richtung, scheitert aber in der Ausführung
  • In Zod erreichte es 18 Äquivalenzen (gleich viel wie GPT-5.5), bestand aber nur 9 Tests
• GPT-5.5 erzeugt bei breiterem Integrationsverhalten weniger kaputte Patches
• Konkrete Fallvergleiche:
  • Schema→TypeScript-Generator: Opus und GPT-5.5 implementierten rekursive Visitoren, GPT-5.4 klassifizierte die Aufgabe falsch und erzeugte stattdessen eine Repository-Hinweisdatei
  • Fix für rekursiven Parser: Beide GPT-Modelle verfolgten den Ansatz über Besuchszählung, GPT-5.5 war aber durch Entfernen unnötigen Zustands kompakter
  • CIDR-Validierung: GPT-5.5 aktualisierte auch den Deno-Mirror, GPT-5.4 nicht, was zu Repository-Hygieneproblemen führte
• In graphql-go-tools PR #1232 (Deduplizierung identischer Single-Fetches + Umschreiben von Abhängigkeitsreferenzen) bestand nur GPT-5.5 Tests, Äquivalenz und Review vollständig
• Das Muster zusammengefasst: GPT-5.5 erledigt häufiger die langweilige Integrationsarbeit, um clevere lokale Änderungen in deploybare Repository-Änderungen zu überführen

Trade-off zwischen Patch-Größe und Kosten

• Durchschnittliche Patch-Größe in graphql-go-tools: GPT-5.5 etwa 33 KB, GPT-5.4 27 KB, Opus 19 KB
• Footprint-Score: Opus 0,19, GPT-5.4 0,32, GPT-5.5 0,34
• Größere Patches erhöhen den Review-Aufwand, die Wahrscheinlichkeit von Konflikten und das Risiko, sensible Pfade zu berühren
  • In Workflows mit Fokus auf Auditierbarkeit hat Opus daher weiterhin einen praktischen Vorteil
• Wird diff minimality jedoch relativ zur Aufgabe bewertet, liegt GPT-5.5 knapp vorn
  • Der Kernpunkt: Ein 5-KB-Patch, der notwendige Oberflächen auslässt, ist nicht minimaler als ein 20-KB-Patch, der die Aufgabe vollständig erledigt
• Kostenvergleich:
  • In Zod lagen Opus und GPT-5.5 nahe beieinander (Opus 45,53 US-Dollar vs. GPT-5.5 46,69 US-Dollar)
  • In graphql-go-tools hatte Opus 186,1M Input-Tokens / 934K Output-Tokens / 8,56h Agent-Zeit, GPT-5.5 dagegen 151,4M / 431K / 4,16h und war damit deutlich effizienter

Zusammenfassung der Modellcharakteristika

• Opus 4.7 — under-reach: konservativ, präzise, geringer Footprint, stark bei lokalen Aufgaben, aber schwach bei Begleitoberflächen, die von Tests nicht vollständig abgedeckt werden; typischer Fehlmodus: „Test bestanden, aber nicht dieselbe Änderung“
• GPT-5.4 — richtige Form, falsche Ausführung: Die Richtung stimmt, aber das Verhalten ist uneinheitlich; häufige Probleme sind veraltete Mirror-Dateien, unnötige Refactorings und Patches, die von Bewertungsmodellen besser eingeschätzt werden als von Tests
• GPT-5.5 — breiter, größerer Footprint: vollständiger auf Integrationsoberflächen, höhere Quote bei umgebenden Code-Updates, Review-Erfolg und tatsächlicher Umsetzung des beabsichtigten Verhaltens in produktiven Code; das Risiko liegt bei Fehlern in mehr Dateien gleichzeitig

Unterschiede im Agent-Verhalten

• In graphql-go-tools nutzte Opus durchschnittlich 3,17 explizite Planungsaufrufe pro Aufgabe, GPT-5.5 0
• Opus kam auf 10,2 Patch-Aufrufe pro Aufgabe, GPT-5.5 auf 9,9 und lag damit ähnlich
• GPT-5.5 führte etwa doppelt so viele Shell-Aufrufe und auch mehr Suchaufrufe aus; Opus verbrauchte mehr Budget für Planung und das Umschreiben von Patches
• In diesem Repository war eine breitere Erkundung des Repositories wirksamer als intensiveres Nachdenken über schmale Patches

Warum diese Ergebnisse wichtig sind

• Die Kernfrage ist nicht „Welches Modell ist das beste?“, sondern: „Welchem Modell kann man in diesem Repository, in diesem Harness und für die tatsächlich ausgelieferten Aufgabentypen vertrauen?“
• In Zod besteht zwischen GPT-5.5 und Opus ein Trade-off, in graphql-go-tools ist GPT-5.5 klar überlegen
• Öffentliche Benchmarks glätten Modellverhalten oft zu einer einzelnen aggregierten Zahl, während es im realen Code um Workflow-Entscheidungen nach konkreter Codebasis und konkreten Kriterien geht

Hinweise

• 56 Aufgaben sind weiterhin eine kleine Stichprobe; schon eine Aufgabe Unterschied kann die Repository-Quoten um mehrere Punkte verschieben
• Alle Modelle wurden pro Aufgabe nur einmal ausgeführt; einige knappe Ergebnisse könnten sich bei Wiederholungen umkehren
• Das Modell für Äquivalenz- und Rubrik-Bewertung war GPT-5.4, daher ist ein Bias innerhalb derselben Modellfamilie möglich
  • Allerdings liegt GPT-5.5 klar vor GPT-5.4, Opus behält seinen Footprint-Vorteil, und viele Äquivalenzfehler von Opus gehen auf konkret fehlende Dateien zurück; das erklärt das Gesamtergebnis also nicht allein
• Die Ergebnisse sind Harness-bedingt: Claude Code und Codex CLI unterscheiden sich bei System-Prompts, Planungsschleifen und Tool-Oberflächen
  • Würde Opus über die Codex API laufen und GPT-5.5 in Claude Code, könnten sich die Resultate ändern
  • Die Zahlen hier spiegeln das Modellverhalten in den Harnesses wider, die echte Engineers tatsächlich verwenden

Zentrale Schlussfolgerungen

• GPT-5.5 ist in diesen beiden Repositories das optimale Standardmodell für Deployments
• Opus 4.7 bleibt ein Modell mit geringem Footprint und kann bevorzugt werden, wenn ein schmaler Diff am wichtigsten ist
• GPT-5.4 ist zwar pro Aufgabe am günstigsten, reicht aber nicht aus, um die Lücke bei clean pass zu kompensieren
• Nur auf Tests zu schauen, verdeckt die wichtigsten Ergebnisse
• Dass sich das Modellranking je nach Repository verändert, ist der zentrale Grund für Benchmarks auf der eigenen Repository-Basis

[shakespeares]

Manchmal wirkt es fast, als hätten sie sich abgesprochen.