Das Experiment
Ich habe 10 echte Programmieraufgaben genommen – die Art, die Entwickler tatsächlich jeden Tag erledigen – und genau denselben Prompt sowohl an GPT-5.4 als auch an Claude Opus 4.6 gesendet. Derselbe System-Prompt, derselbe Kontext, dieselben Bewertungskriterien.
Keine synthetischen Benchmarks. Keine handverlesenen Beispiele. Nur reale Aufgaben, bewertet in drei Dimensionen:
- Korrektheit (funktioniert es ohne Modifikationen?)
- Code-Qualität (Lesbarkeit, Typen, Fehlerbehandlung, Edge Cases)
- Effizienz (Token-Nutzung, Antwortzeit, Anzahl der benötigten Folge-Prompts)
Jede Dimension wird mit 1-10 Punkten bewertet. Maximal mögliche Punktzahl pro Aufgabe: 30.
Der Zugriff auf die Modelle erfolgte über ihre jeweiligen APIs zu Standardpreisen: GPT-5.4 bei $2.50/$15 per million tokens und Claude Opus 4.6 bei $15/$75 per million tokens.
Hier sind die 10 Aufgaben und was genau passiert ist.
Aufgabe 1: Erstellen eines REST API Endpunkts
Prompt: "Erstelle einen POST /api/users Endpunkt in Express.js mit TypeScript. Validiere das E-Mail-Format und die Passwortstärke (mind. 8 Zeichen, 1 Großbuchstabe, 1 Zahl). Hashe das Passwort mit bcrypt. Speichere es in PostgreSQL via Prisma. Gib den Benutzer ohne das Passwort-Feld zurück. Behandle doppelte E-Mails mit einem 409-Status."
GPT-5.4 Ergebnis
Sauberer, produktionsreifer Code. Das Zod-Validierungsschema war präzise. Das bcrypt-Hashing verwendete eine korrekte Konstante für die Salt-Runden. Die Prisma-Abfrage nutzte select, um das Passwort-Feld bereits auf Datenbankebene auszuschließen, anstatt es erst aus dem Antwortobjekt zu löschen – eine subtile, aber wichtige Sicherheitspraxis. Die TypeScript-Typen waren exakt.
Claude Opus 4.6 Ergebnis
Ebenfalls sauber und korrekt. Verwendete einen ähnlichen Zod-Validierungsansatz, fügte jedoch eine Rate limiting Middleware für den Endpunkt hinzu und enthielt einen Kommentar, der dies erklärte. Der Passwort-Ausschluss nutzte die omit-Funktion von Prisma. Fügte einen try/catch-Block mit spezifischen Fehlertypen für Prisma-Verletzungen von Unique Constraints hinzu.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 10 | 10 |
| Code-Qualität | 9 | 9 |
| Effizienz | 9 | 8 |
| Gesamt | 28 | 27 |
Gewinner: GPT-5.4 (knapp, aufgrund von Geschwindigkeit und Prägnanz)
Beide Ausgaben waren exzellent. GPT-5.4 war schneller und verbrauchte weniger tokens. Opus fügte ungefragt die Rate limiting Middleware hinzu – nützlich, aber nicht angefordert. Für klar definierte API-Aufgaben sind die Modelle im Wesentlichen austauschbar.
Aufgabe 2: Erstellen einer React-Komponente
Prompt: "Erstelle eine React-Komponente namens DataTable, die generische typisierte Daten akzeptiert, sortierbare Spalten, Pagination (clientseitig), einen Suchfilter und Zeilenauswahl mit Checkboxen unterstützt. Verwende TypeScript-Generics. Keine UI-Bibliothek – nur HTML/CSS mit CSS modules. Füge korrekte ARIA-Attribute hinzu."
GPT-5.4 Ergebnis
Lieferte eine gut strukturierte generische Komponente. TypeScript-Generics wurden korrekt für die Spaltendefinition und Datentypen verwendet. Die Sortierlogik war sauber mit einem extrahierten benutzerdefinierten useSortable Hook. Die Pagination nutzte useMemo für die Performance. Die ARIA-Attribute waren korrekt – role="grid", aria-sort auf sortierbaren Headern, aria-selected auf Checkboxen.
Claude Opus 4.6 Ergebnis
Ähnliche Struktur, aber mit ein paar Unterschieden. Opus erstellte einen useDataTable Hook, der die Sortier-, Pagination- und Filterlogik kapselte – eine sauberere Trennung, aber mehr Abstraktion. Die TypeScript-Generics waren gleichermaßen korrekt. Es fehlte aria-sort auf den Header-Zellen. Das CSS module enthielt ein responsives Layout, das auf Mobilgeräten in eine Kartenansicht wechselte, was nicht angefordert war, aber eine durchdachte Ergänzung darstellte.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 10 | 9 |
| Code-Qualität | 9 | 9 |
| Effizienz | 9 | 8 |
| Gesamt | 28 | 26 |
Gewinner: GPT-5.4
Die ARIA-Implementierung von GPT-5.4 war vollständiger, was für eine Komponente, die anwendungsweit eingesetzt wird, wichtig ist. Wie im Vergleich von MindStudio angemerkt, glänzt GPT-5.4 bei der Generierung von Boilerplate, einschließlich React-Komponenten und TypeScript-Interfaces.
Aufgabe 3: Schreiben einer komplexen SQL-Abfrage
Prompt: "Schreibe eine PostgreSQL-Abfrage, welche die Top 10 Kunden nach Lifetime Value (Gesamtbestellwert) zurückgibt, die in den letzten 12 Monaten mindestens 3 Bestellungen aufgegeben haben, einschließlich ihres letzten Bestelldatums, des durchschnittlichen Bestellwerts und der prozentualen Änderung ihrer Ausgaben im Vergleich zum vorherigen 12-Monats-Zeitraum. Verwende CTEs für die Lesbarkeit."
GPT-5.4 Ergebnis
Drei CTEs: eine für die Aggregation des aktuellen Zeitraums, eine für den vorherigen Zeitraum und eine für die Prozentberechnung. Sauber, korrekt und gut formatiert. Verwendete COALESCE für die Behandlung von Kunden ohne Daten im vorherigen Zeitraum. Fügte einen Kommentar mit einem Index-Hinweis hinzu.
Claude Opus 4.6 Ergebnis
Vier CTEs mit einer etwas anderen Struktur: Die Berechnung des "letzten Bestelldatums" wurde in eine eigene CTE ausgelagert, um eine korrelierte Unterabfrage zu vermeiden. Fügte ein NULLIF hinzu, um eine Division durch Null bei der Prozentberechnung zu verhindern – ein echter Edge Case, den GPT-5.4 übersehen hat. Enthielt eine Alternative mit Window Functions in einem Kommentarblock.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 9 | 10 |
| Code-Qualität | 8 | 9 |
| Effizienz | 9 | 8 |
| Gesamt | 26 | 27 |
Gewinner: Claude Opus 4.6
Der Edge Case der Division durch Null war der entscheidende Faktor. In produktivem SQL führt ein solcher Bug zu stiller Datenkorruption. Opus bringt konsequent Edge Cases ans Licht, die in realen Daten-Pipelines von Bedeutung sind.
Aufgabe 4: Debuggen einer Race Condition
Prompt: Ich habe 3 Dateien (~200 Zeilen insgesamt) aus einer Node.js-Anwendung mit einem zeitweiligen Testfehler bereitgestellt. Der Bug war eine Race Condition in einer Caching-Ebene, bei der gleichzeitige Cache-Misses doppelte Datenbankabfragen und einen inkonsistenten Zustand auslösen konnten. "Finde den Fehler, erkläre, warum er nur sporadisch auftritt, und liefere einen Fix."
GPT-5.4 Ergebnis
Identifizierte den korrekten Codepfad für den Cache-Miss. Schlug vor, eine Mutex-Sperre mit async-mutex hinzuzufügen. Der Fix war korrekt, behandelte aber eher das Symptom als die Ursache – er serialisierte alle Cache-Zugriffe, was die Performance unter Last beeinträchtigen würde.
Claude Opus 4.6 Ergebnis
Identifizierte denselben Codepfad, verfolgte die Zustandsinkonsistenz jedoch bis zu einem zweiten Problem zurück: Das Cache-Update war nicht atomar – es gab ein Fenster zwischen der Lese-Prüfung und dem Schreiben, in dem sich eine andere Anfrage dazwischenschieben konnte. Opus schlug ein "single-flight"-Muster vor (Zusammenfassen gleichzeitiger identischer Anfragen) anstelle eines globalen Mutex. Der Fix war präziser und bewahrte die Nebenläufigkeit für nicht kollidierende Cache-Keys.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 7 | 10 |
| Code-Qualität | 7 | 9 |
| Effizienz | 8 | 8 |
| Gesamt | 22 | 27 |
Gewinner: Claude Opus 4.6
Ein deutlicher Unterschied. Opus verstand das Concurrency-Modell tief genug, um einen gezielten Fix vorzuschlagen. Dies deckt sich mit dem 80.8% Score von Claude Opus 4.6 auf SWE-bench Verified, der genau diese Art der Fehlerbehebung in der Praxis testet.
Aufgabe 5: Code-Review
Prompt: Ich habe einen 350 Zeilen langen Pull Request für ein neues Zahlungsverarbeitungsmodul bereitgestellt. "Prüfe diesen PR auf Bugs, Sicherheitsprobleme, Performance-Probleme und Code-Qualität. Priorisiere die Ergebnisse nach Schweregrad."
GPT-5.4 Ergebnis
Fand 5 Probleme: einen fehlenden Null-Check bei der Zahlungsantwort, eine unbehandelte Promise-Rejection, ein fest kodiertes Timeout, das konfigurierbar sein sollte, einen fehlenden Idempotenz-Key und den Vorschlag, Magic Numbers in Konstanten zu extrahieren. Organisiert nach Schweregrad. Klar und umsetzbar.
Claude Opus 4.6 Ergebnis
Fand 8 Probleme: die gleichen 5 wie GPT-5.4 plus drei weitere – eine TOCTOU-Schwachstelle (time-of-check-time-of-use) bei der Betragsvalidierung, ein potenzielles Informationsleck in der Fehlerantwort, das interne Stack Traces preisgab, und ein subtiles Problem, bei dem die Retry-Logik zu Doppelabbuchungen führen konnte, wenn die erste Anfrage erfolgreich war, aber die Antwort verlorenging. Jeder Befund enthielt die spezifische Zeilennummer und einen Lösungsvorschlag.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 8 | 10 |
| Code-Qualität | 8 | 10 |
| Effizienz | 9 | 8 |
| Gesamt | 25 | 28 |
Gewinner: Claude Opus 4.6
Die drei zusätzlichen Befunde waren alle sicherheitskritisch. Allein der Bug mit der Doppelabbuchung könnte ein Unternehmen viel Geld und Ansehen kosten. Die 76% von Opus auf MRCR v2 (Argumentation über mehrere Dateien) führen direkt zu einem besseren Code-Review bei komplexen Modulen.
Aufgabe 6: Schreiben einer Test-Suite
Prompt: "Schreibe umfassende Tests für diese Authentifizierungs-Middleware mit Vitest. Decke ab: gültige tokens, abgelaufene tokens, falsch formatierte tokens, fehlende Authorization-Header, revozierte tokens, Rate Limiting und gleichzeitige Authentifizierungsanfragen." Ich habe die Quelldatei der Middleware (~120 Zeilen) bereitgestellt.
GPT-5.4 Ergebnis
Generierte 18 Testfälle, organisiert in sauberen describe-Blöcken. Jedes Szenario aus dem Prompt wurde abgedeckt. Fügte drei zusätzliche Edge Cases hinzu: Leerstring-token, token mit falschem Algorithmus und Authorization-Header, der nur aus Leerzeichen besteht. Mocks waren gut strukturiert mit vi.mock. Die Testbeschreibungen waren klar und folgten dem Muster "should X when Y".
Claude Opus 4.6 Ergebnis
Generierte 15 Testfälle. Alle angeforderten Szenarien wurden abgedeckt. Die Teststruktur verwendete eine Helper-Factory zum Erstellen von tokens mit unterschiedlichen Eigenschaften – clever, erhöhte aber die Komplexität. Der explizit angeforderte Test für "gleichzeitige Authentifizierungsanfragen" fehlte. Die Mocks waren sauberer, aber die Anzahl der Tests war geringer.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 10 | 8 |
| Code-Qualität | 9 | 9 |
| Effizienz | 9 | 8 |
| Gesamt | 28 | 25 |
Gewinner: GPT-5.4
GPT-5.4 folgte dem Prompt gewissenhafter und fügte sinnvolle Edge Cases hinzu. Wie mehrere Vergleiche feststellen, gehört die Testgenerierung von GPT-5.4 zu den besten und liefert umfassende Suites mit starker Abdeckung von Randfällen.
Aufgabe 7: Refactoring eines monolithischen Moduls
Prompt: Ich habe ein 500 Zeilen langes Python-Modul für die Benutzerverwaltung bereitgestellt – Registrierung, Authentifizierung, Profilaktualisierungen, Passwort-Resets und E-Mail-Benachrichtigungen, alles in einer Datei. "Refaktoriere dies in eine saubere Modulstruktur nach SOLID-Prinzipien. Behalte die Abwärtskompatibilität mit der bestehenden öffentlichen API bei."
GPT-5.4 Ergebnis
Aufgeteilt in 5 Module: auth.py, registration.py, profile.py, password.py, notifications.py. Fügte eine __init__.py hinzu, welche die ursprünglichen öffentlichen Funktionen für die Abwärtskompatibilität re-exportierte. Saubere Trennung. Jedes Modul war in sich abgeschlossen.
Allerdings wurde die zirkuläre Abhängigkeit zwischen registration.py und notifications.py nicht behoben – die Registrierung sendet eine Willkommens-E-Mail, und das Benachrichtigungsmodul benötigte eine Referenz zurück auf die Benutzerdaten. Der Code würde beim Import abstürzen.
Claude Opus 4.6 Ergebnis
Aufgeteilt in 6 Module mit der gleichen Aufteilung plus einer types.py für gemeinsam genutzte Datenklassen. Entscheidend war, dass es das Problem der zirkulären Abhängigkeit identifizierte und durch die Einführung eines event-basierten Musters löste – die Registrierung löst ein "user_created"-Event aus, und das Benachrichtigungsmodul abonniert dieses. Die abwärtskompatible __init__.py war identisch im Ansatz.
Opus fügte außerdem einen kurzen Kommentar am Anfang jedes Moduls hinzu, der erklärte, was dorthin gehört und was nicht – eine Orientierungshilfe für zukünftige Entwickler.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 6 | 10 |
| Code-Qualität | 8 | 10 |
| Effizienz | 8 | 7 |
| Gesamt | 22 | 27 |
Gewinner: Claude Opus 4.6
Der Fehler mit der zirkulären Abhängigkeit hätte zu einem Produktionsausfall geführt. Dies ist die Art von Argumentation über mehrere Dateien, in der Opus glänzt – es versteht dateiübergreifende Abhängigkeiten und architektonische Auswirkungen, bevor es Code generiert.
Aufgabe 8: Schreiben technischer Dokumentation
Prompt: "Schreibe eine API-Dokumentation für dieses Zahlungsverarbeitungs-SDK. Enthalten sein müssen: Übersicht, Authentifizierung, Rate Limits, Fehlercodes, 5 Endpunktbeschreibungen mit Request/Response-Beispielen, ein Webhook-Abschnitt und ein Migrationsleitfaden von v1 zu v2." Ich habe den SDK-Quellcode bereitgestellt.
GPT-5.4 Ergebnis
Umfassende Dokumentation, die alle angeforderten Abschnitte abdeckt. Die Endpunktbeschreibungen waren detailliert mit curl-Beispielen und Response-Schemas. Der Abschnitt über Fehlercodes war gut als Tabelle organisiert. Der Migrationsleitfaden war klar mit Vorher/Nachher-Codebeispielen. Saubere Markdown-Formatierung.
Claude Opus 4.6 Ergebnis
Ebenfalls umfassend, mit einer etwas anderen Struktur – es begann mit einem "Quick Start"-Abschnitt vor den detaillierten Dokumenten, was ein gutes Muster für Entwicklerdokumentationen ist. Der Webhook-Abschnitt war detaillierter und enthielt Retry-Verhalten, Code zur Signaturprüfung und Testanleitungen. Der Migrationsleitfaden enthielt einen Zeitplan für die Deprecation, der nicht im Quellcode stand – dies wurde aus Versionierungsmustern abgeleitet.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 9 | 9 |
| Code-Qualität | 9 | 9 |
| Effizienz | 9 | 8 |
| Gesamt | 27 | 26 |
Gewinner: Unentschieden (GPT-5.4 mit einem Punkt Vorsprung bei der Effizienz)
Beide lieferten exzellente Dokumentationen. Der Qualitätsunterschied ist vernachlässigbar. GPT-5.4 war etwas schneller. Für Dokumentationsaufgaben eignen sich beide Modelle gut – dies deckt sich mit Berichten von Entwicklern, dass die Dokumentationsqualität bei Frontier-Modellen vergleichbar ist.
Aufgabe 9: Entwurf einer Systemarchitektur
Prompt: "Entwirf die Architektur für einen kollaborativen Echtzeit-Dokumenteneditor, der 10.000 gleichzeitige Benutzer unterstützt. Decke ab: Datenmodell, Strategie zur Konfliktlösung (CRDTs vs OT), WebSocket-Infrastruktur, Storage-Ebene, Presence-System und Deployment-Topologie. Erstelle ein Diagramm in Mermaid-Syntax."
GPT-5.4 Ergebnis
Wählte OT (Operational Transformation) mit einem zentralen Server. Vernünftige Architektur mit Redis für Presence, PostgreSQL für die Dokumentenspeicherung und einem WebSocket-Gateway hinter einem Load Balancer. Das Mermaid-Diagramm war sauber. Die Analyse war kompetent, folgte aber einem Standard-Schema – die Abwägungen zwischen CRDTs und OT für diese spezifische Skalierung wurden nicht tiefgehend analysiert.
Claude Opus 4.6 Ergebnis
Begann mit einer Klärungsfrage zum Dokumentenmodell (Rich-Text vs. Plain-Text vs. strukturierte Daten), die ich mit "Rich-Text" beantwortete. Empfahl dann CRDTs (speziell Yjs) gegenüber OT, mit einer detaillierten Erklärung, warum CRDTs bei dieser Skalierung überlegen sind – Eventual Consistency ohne einen zentralen Sequencer eliminiert den Single Point of Failure.
Die Architektur enthielt ein neuartiges Detail: eine "Document Gateway"-Ebene, die CRDT-Merge-Operationen handhabt und sowohl als WebSocket-Terminator als auch als State-Persistence-Ebene fungiert. Das Mermaid-Diagramm enthielt Datenfluss-Pfeile mit Protokoll-Annotationen. Der Deployment-Abschnitt empfahl eine spezifische Partitionierungsstrategie (Sharding nach Document ID) mit Begründungen zu Hot Partitions.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 8 | 10 |
| Code-Qualität | 7 | 10 |
| Effizienz | 8 | 7 |
| Gesamt | 23 | 27 |
Gewinner: Claude Opus 4.6
In der Architektur wird die Lücke in der Argumentationstiefe zwischen diesen Modellen am deutlichsten. Opus überlegt expliziter über das Problem nach, bevor es eine Ausgabe generiert, arbeitet sich durch Edge Cases und stellt klärende Fragen, wenn Anforderungen wirklich mehrdeutig sind.
Aufgabe 10: Schreiben eines DevOps Deployment-Scripts
Prompt: "Schreibe einen GitHub Actions Workflow, der: ein Docker-Image baut, Tests ausführt, nach ECR pusht, nach ECS Fargate mit Blue-Green-Deployment deployt, einen Smoke-Test gegen das neue Deployment ausführt und automatisch ein Rollback durchführt, falls der Smoke-Test fehlschlägt. Verwende OIDC für die AWS-Authentifizierung – keine fest kodierten Anmeldedaten."
GPT-5.4 Ergebnis
Eine vollständige Workflow-Datei mit allen angeforderten Schritten. Die OIDC-Konfiguration war korrekt unter Verwendung von aws-actions/configure-aws-credentials mit der Role-ARN. Das Blue-Green-Deployment nutzte das ECS-Service-Update mit dem CODE_DEPLOY Deployment-Controller. Der Smoke-Test war ein curl-basierter Health-Check. Das Rollback wurde durch den Exit-Code des Smoke-Tests ausgelöst. Gut kommentiert, produktionsreif.
Claude Opus 4.6 Ergebnis
Ebenfalls vollständig und korrekt. Verwendete denselben OIDC-Ansatz. Der Hauptunterschied lag im Smoke-Test – Opus erstellte einen gründlicheren Test, der nicht nur den Health-Endpunkt prüfte, sondern auch verifizierte, dass das Deployment die richtige Version auslieferte, indem ein /version-Endpunkt geprüft wurde. Das Rollback enthielt einen Schritt für eine Slack-Benachrichtigung. Allerdings war der Workflow deutlich wortreicher – 40% mehr Zeilen für eine ähnliche Funktionalität.
Punkte
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrektheit | 10 | 10 |
| Code-Qualität | 9 | 9 |
| Effizienz | 9 | 7 |
| Gesamt | 28 | 26 |
Gewinner: GPT-5.4
Bei DevOps-Scripting ist die Prägnanz von GPT-5.4 ein Vorteil. Der Workflow ist einfacher zu warten und zu modifizieren. Die Ergänzungen von Opus (Slack-Benachrichtigung, Versionsprüfung) sind nett, wurden aber nicht angefordert und erhöhten die Komplexität. GPT-5.4 führt bei Terminal-bench (75.1% vs 65.4%), und dieser Vorteil zeigt sich in terminalorientierten Aufgaben.
Die finale Punktetafel
| Aufgabe | GPT-5.4 | Opus 4.6 | Gewinner |
|---|---|---|---|
| 1. REST API Endpunkt | 28 | 27 | GPT-5.4 |
| 2. React-Komponente | 28 | 26 | GPT-5.4 |
| 3. SQL-Abfrage | 26 | 27 | Opus 4.6 |
| 4. Debugging Race Condition | 22 | 27 | Opus 4.6 |
| 5. Code-Review | 25 | 28 | Opus 4.6 |
| 6. Test-Suite | 28 | 25 | GPT-5.4 |
| 7. Refactoring Modul | 22 | 27 | Opus 4.6 |
| 8. Dokumentation | 27 | 26 | Unentschieden |
| 9. Architektur-Entwurf | 23 | 27 | Opus 4.6 |
| 10. DevOps-Script | 28 | 26 | GPT-5.4 |
| Gesamt | 257 | 266 | Opus 4.6 |
Endergebnis: Claude Opus 4.6 gewinnt mit 266 zu 257 Punkten.
Aber die Gesamtpunktzahl verbirgt die eigentliche Geschichte.
Das Muster, das wichtiger ist als die Punktzahl
Schauen Sie sich an, wo jedes Modell gewinnt:
GPT-5.4 gewinnt bei:
- API-Endpunkten (klar definierte, abgegrenzte Aufgaben)
- React-Komponenten (Boilerplate mit klaren Spezifikationen)
- Schreiben von Tests (umfassende Abdeckung nach Vorgabe)
- DevOps-Scripts (terminalorientierte, prägnante Ausgabe)
Claude Opus 4.6 gewinnt bei:
- SQL-Edge-Cases (Aufspüren subtiler Datenfehler)
- Debugging (Verstehen von Ursachen in komplexen Systemen)
- Code-Review (Finden von Sicherheits- und Korrektheitsproblemen)
- Refactoring (Umgang mit dateiübergreifenden Abhängigkeiten)
- Architektur (tiefe Abwägung von Kompromissen)
Das Muster ist klar: GPT-5.4 ist das schnellere, günstigere und bessere Modell für klar definierte Programmieraufgaben. Claude Opus 4.6 ist das tiefgründigere, sorgfältigere Modell für Aufgaben, die logisches Denken über Komplexität hinweg erfordern.
Dies deckt sich mit der Analyse von DataCamp: GPT-5.4 ist das beste Allround-Modell, während Opus 4.6 speziell bei agentenbasierten und tiefgehenden Programmieraufgaben glänzt.
Der Kostenfaktor
Der Punkteabstand (9 Punkte) ist relativ gering. Der Kostenunterschied ist es nicht.
| Metrik | GPT-5.4 | Claude Opus 4.6 |
|---|---|---|
| Preise für Input | $2.50/MTok | $15/MTok |
| Preise für Output | $15/MTok | $75/MTok |
| Geschwindigkeit | 73.4 tok/s | 40.5 tok/s |
| Kontextfenster | 1M (Aufschlag >272K) | 1M (Flat-Pricing) |
| Einsparungen durch Tool Search | ~47% Token-Reduktion | N/A |
Für diesen Test mit 10 Aufgaben betrugen die gesamten API-Kosten etwa $4.20 für GPT-5.4 und $31.50 für Opus 4.6. Das ist ein 7,5-facher Kostenunterschied für einen Qualitätsunterschied von 3,5%.
Für ein Team, das täglich hunderte KI-gestützte Programmieraufgaben ausführt, spricht die Rechnung stark für GPT-5.4 für den Großteil der Arbeit, wobei Opus für die entscheidenden 10-20% reserviert bleibt, in denen seine Argumentationstiefe einen wesentlichen Unterschied macht.
Die intelligente Strategie: Beide nutzen
Die meisten arbeitenden Entwickler im Jahr 2026 wählen nicht ein Modell – sie entscheiden, wann sie welches Modell einsetzen. Das Muster, das sich aus diesem Test ergeben hat, entspricht dem, was wir bei ZBuild verwenden:
Täglicher Begleiter: GPT-5.4 (via Codex CLI oder API)
- Schreiben neuer Endpunkte, Komponenten und Scripts
- Generieren von Tests aus Spezifikationen
- Schnelles Debugging isolierter Probleme
- Automatisierung von DevOps und CI/CD
Für das Grobe: Claude Opus 4.6 (via Claude Code oder API)
- Dateiübergreifendes Refactoring mit komplexen Abhängigkeiten
- Review von sicherheitskritischem Code
- Architektur-Design-Sessions
- Debugging nicht offensichtlicher Probleme in großen Codebases
Dieser Zwei-Modell-Ansatz nutzt 95% der Stärken beider Modelle und hält gleichzeitig die Kosten überschaubar. Der Leitfaden von Portkey zur Wahl zwischen diesen Modellen empfiehlt denselben hybriden Ansatz.
Was die Benchmarks sagen (als Kontext)
Die obigen Einzelergebnisse stimmen mit den formalen Benchmarks überein:
| Benchmark | GPT-5.4 | Opus 4.6 | Was gemessen wird |
|---|---|---|---|
| SWE-bench Verified | ~80% | 80.8% | Lösung echter GitHub-Probleme |
| SWE-bench Pro | 57.7% | ~46% | Härtere, strengere Programmieraufgaben |
| Terminal-bench 2.0 | 75.1% | 65.4% | Terminal- und Systemaufgaben |
| HumanEval | 93.1% | 90.4% | Code-Generierung auf Funktionsebene |
| GPQA Diamond | 92.0-92.8% | 87.4-91.3% | Argumentation auf Expertenniveau |
| ARC-AGI-2 | 73.3% | 68.8-69.2% | Neuartige Argumentation |
Quellen: MindStudio Benchmarks, Evolink Analyse, Anthropic
GPT-5.4 führt bei den meisten Benchmarks. Opus 4.6 führt bei SWE-bench Verified – dem Benchmark, der am engsten mit der Fehlerbehebung in der Praxis verknüpft ist – was seinen Vorteil beim Debugging und Refactoring in meinen Tests erklärt.
Das Fazit
Wenn Sie nur ein Modell wählen können: GPT-5.4. Es bewältigt 80% der Programmieraufgaben in gleicher oder besserer Qualität, kostet 6-7x weniger und ist 80% schneller. Die 20% der Aufgaben, bei denen Opus besser ist (Debugging, Refactoring, Architektur), können oft durch detaillierteres Prompting bei GPT-5.4 gelöst werden.
Wenn Sie beide nutzen können: Tun Sie es. GPT-5.4 für das tägliche Programmieren, Opus 4.6 für komplexe Arbeiten. Dies ist kein Kompromiss – es ist die optimale Strategie.
Wenn Kosten keine Rolle spielen und Sie bei jeder Aufgabe maximale Qualität wollen: Claude Opus 4.6. Es hat die Gesamtwertung gewonnen, und seine Siege lagen bei den Aufgaben, bei denen Qualität am wichtigsten ist (Bugs kosten mehr als Boilerplate).
Die Ergebnisse entsprachen nicht meinen Erwartungen, da ich davon ausging, dass das teurere Modell dominieren würde. Das tat es nicht. Die beiden Modelle haben genuinely unterschiedliche Stärken, und die beste Strategie ist zu wissen, welche Stärke man für die jeweilige Aufgabe benötigt.
Quellen
- OpenAI — Einführung von GPT-5.4
- OpenAI — API Preise
- Anthropic — Einführung von Claude Opus 4.6
- Anthropic — Claude Preise
- MindStudio — GPT-5.4 vs Claude Opus 4.6 vs Gemini 3.1 Pro Benchmarks
- MindStudio — Welches KI-Modell ist das richtige für Ihren Workflow
- Portkey — GPT-5.4 vs Claude Opus 4.6 Leitfaden
- DataCamp — GPT-5.4 vs Claude Opus 4.6 für agentenbasierte Aufgaben
- Artificial Analysis — GPT-5.4 vs Claude Opus 4.6
- Bind AI — GPT-5.4 vs Claude Opus 4.6 zum Programmieren
- Evolink — SWE-bench Verified 2026: Claude vs GPT
- DEV Community — ChatGPT vs Claude zum Programmieren 2026
- Claude 5 — Opus 4.6 Benchmark-Analyse