GPT 5.5 vs Opus 4.7: Ich habe beide getestet – das ist der klare Sieger

GPT 5.5 vs Opus 4.7: Ich habe beide getestet – das ist der klare Sieger

Das Dashboard zeigte 250.000 Ausgabetokens an. Ich habe es zweimal aktualisiert. Immer noch die gleiche Zahl.

Opus 4.7 hatte gerade eine Simulation eines Sonnensystems in zwölf Minuten fertiggestellt. Gleicher Prompt, gleiche Aufgabe – GPT 5.5 hatte denselben Job in exakt zehn Minuten erledigt und dabei 70.000 Ausgabetokens verwendet. Nicht 200.000. Nicht 150.000. Siebzigtausend. Ein Unterschied von 3,5x bei einem Output, der auf den ersten Blick nahezu identisch wirkte. Beide simulierten anklickbare Planeten. Beide boten einstellbare Umlaufgeschwindigkeiten. Beide renderten beim ersten Lauf ohne Fehler.

Das war der Moment, in dem mir klar wurde: Die Diskussion GPT 5.5 vs Opus 4.7 wird nicht durch Benchmark-Ergebnisse oder Marketingfolien entschieden. Sie wird durch Token-Abrechnungen und Echtzeit gestoppt. Und die Antwort, um die jeder herumredet, ist spannender als „X ist besser als Y“ – denn sie hängt komplett davon ab, was man tatsächlich ausliefern möchte.

Die letzte Woche habe ich beide Modelle mit vier produktionsnahen Builds getestet: einer persönlichen Brand-Website, einer Sonnensystem-Simulation, einem 3D-Weltraum-Shooter und einer Ökosystem-Simulation, die wirkliches One-Shot-Reasoning auf die Probe stellt. Echte Prompts. Echtes Kosten-Tracking. Echte, ausführbare Ergebnisse. In diesem Beitrag teile ich, was ich gelernt habe, was mich überrascht hat und zu welchem Modell ich morgen früh greifen würde, wenn ich bis zum Mittag etwas liefern müsste.

Bleib dabei bis zum dritten Experiment. Dort wurde meine Erwartung, welches Modell wirklich „gewinnt“, in Echtzeit pulverisiert.

Warum dieser Vergleich gerade jetzt wirklich zählt

Die Veröffentlichungszyklen sind völlig aus dem Ruder gelaufen. GPT 5.4 kam im Februar heraus. Opus 4.7 folgte kurz darauf. Jetzt steht GPT 5.5 — in den Leaks unter dem Codenamen „Spud“ — etwa sechs Wochen nach seinem Vorgänger bereit, mit einer Preiserhöhung, einem Token-Effizienz-Versprechen und einem Benchmark-Ergebnis, das es auf dem Terminal Bench 2.0 mit 13,3 Punkten Vorsprung vor Opus 4.7 platziert (82,7 vs. 69,4).

Wenn du Solo-Entwickler bist oder einen Agenten-Stack betreibst, der nach Token abgerechnet wird, zwingt dich jeder Modellwechsel zu einer Überprüfung deiner Unit-Economics. Den Input-Preis von $2,50 auf $5,00 pro eine Million Token zu verdoppeln ist keine Fußnote – das ist ein Kostenpunkt, der direkt auf deiner Monatsabrechnung durchschlägt. Das Argument von OpenAI: GPT 5.5 benötigt pro Aufgabe weniger Output-Token, sodass sich die Kosten pro Aufgabe ausgleichen oder sogar senken. Das ist die Behauptung. Ich wollte wissen, was sich in der echten Praxis tut, nicht nur auf synthetischen Benchmarks.

Das unterscheidet diese Vergleichsrunde von meinem GPT 5.4 vs. Opus 4.6 Test vor ein paar Monaten: GPT 5.5 bewirbt keine rohe Intelligenz mehr. Stattdessen wirbt das Modell mit autonomer Dekomposition — der Fähigkeit, eine vage Aufgabe zu nehmen, Mehrdeutigkeiten zu erkennen und die nächsten Schritte selbständig auszuführen, ohne dich mit fünfzehn Nachfragen zu bombardieren. Das ist eine Verhaltensänderung, keine reine Fähigkeitsänderung. Und Verhaltensänderungen lassen sich bekanntlich nur schwer anhand eines Presse-Statements bewerten.

Wer in den letzten sechs Monaten bei Claude Code unterwegs war, kennt den Charakter von Opus 4.7 bereits: Es schreibt ausführlicheren Code, erklärt sich ständig und liefert Ausgaben, die oft visuell sauber wirken, aber eben viele Token kosten. Die Frage, mit der ich diese Woche in den Test gegangen bin: Kann GPT 5.5 mit dem Motto „mehr mit weniger“ wirklich liefern, oder ist das nur ein Marketingspruch, der eine Preisverdopplung kaschiert?

Bevor ich auf die Ergebnisse komme, musst du wissen, wie ich den Test aufgebaut habe – denn die Headline-Zahlen sagen auf den ersten Blick weniger aus, als es scheint.

Das Test-Setup: Vier Builds, identische Prompts, ehrliche Zahlen

Jeder Vergleichstest, den ich je gelesen habe, leidet unter demselben Problem: cherry-gepickte Aufgaben. Jemand führt drei Prompts aus, postet die Screenshots, die seinem bevorzugten Modell schmeicheln, und nennt das einen Vergleich. Ich wollte es anders machen.

Ich habe vier Aufgaben ausgewählt, die tatsächlich die Bandbreite dessen abdecken, was ich mit diesen Modellen an einer normalen Woche baue:

1. Eine Personal-Brand-Website — designlastig, erfordert Urteilsvermögen, mehrere Iterationen erwartet
2. Eine Sonnensystem-Simulation — Physik, Animation, Mathematik, interaktive Steuerung
3. Ein 3D-Weltraum-Shooter-Spiel — Gameplay-Logik, Steuerungsgefühl, Echtzeit-Rendering
4. Eine Ökosystem-Simulation — komplexes emergentes Verhalten, das schwierigste One-Shot

Für jede Aufgabe schrieb ich einen Prompt. Derselbe Prompt für beide Modelle. Kein Iterieren, keine Nachfragen, kein „Könntest du das eigentlich nochmal anpassen?“. Einfach der Prompt, das Ergebnis und die Rechnung.

Ich habe bei jedem Durchlauf vier Kennzahlen erfasst:

• Laufzeit: Die reale Zeitspanne vom Abschicken des Prompts bis zum finalen Output
• Input-Tokens: Was das Modell konsumiert hat (Prompts + abgerufener Kontext)
• Output-Tokens: Was das Modell zurückgeliefert hat
• Geschätzte Kosten: Input × $5/M + Output × $30/M für GPT 5.5, Input × $5/M + Output × $25/M für Opus 4.7

Preisreferenz zum Vergleich: GPT 5.4 lag bei $2.50/$15. GPT 5.5 kostet $5.00/$30 — exakt das Doppelte. Opus 4.7 liegt bei etwa $5.00/$25, was die Output-Tokens pro Million ungefähr $5 günstiger macht als bei GPT 5.5. Wenn das Token-Effizienz-Versprechen von GPT 5.5 also wahr ist, muss es diese Preisdifferenz durch deutlich weniger Output-Tokens ausgleichen. Die Rechnung ist gnadenlos und ehrlich.

Noch ein Hinweis zum Setup: GPT 5.5 lief über Codex (OpenAIs Coding-Umgebung mit Tool-Integration, Multi-Agent-Ausführung und den neuen wiederverwendbaren Workflows). Opus 4.7 lief über Claude Code. Beide sind die Standardumgebungen ihrer jeweiligen Modelle. Ein Vergleich der blanken APIs wäre für beide unfair gewesen — diese Modelle sind darauf ausgelegt, innerhalb ihrer Harnesses genutzt zu werden.

Jetzt zu den Ergebnissen. Beginnen wir mit dem Build, bei dem der Unterschied am peinlichsten war.

Experiment 1: Der Personal Brand Website Build

Der Prompt: „Erstelle eine dynamische Personal Brand-Website mit animiertem Hero-Bereich, verifizierter Berufshistorie inklusive Kontextkarten, Projekt-Showcase und Kontaktformular. Verwende moderne Designkonventionen. Mache sie produktionsreif.“

Absichtlich vage gehalten. Genau bei solchen Prompts soll autonome Dekomposition glänzen – oder eben scheitern.

GPT 5.5 (Codex) war nach etwa vier Minuten fertig. Das Modell stellte eine Seite bereit, bei der die Berufshistorie durch Verifikationsschleifen ergänzt war (ein Klick auf jede Funktion öffnete eine Kontextkarte mit zugehörigen Projekten), bot eine interaktive Zeitleiste und ein Kontaktformular mit korrekter Validierung. Das Design hätte keinen Preis gewonnen, war aber stimmig und lieferfertig. Geschätzte Kosten: circa 1 $.

Opus 4.7 (Claude Code) benötigte etwa vierzehn Minuten. Die Seite war hübscher – weichere Animationen, eine ansprechendere typografische Hierarchie und bewusstere Farbauswahl. Es gab jedoch kleinere UI-Bugs: ein Hover-Zustand, der nicht zurücksprang, ein Kontaktformular-Button, der auf Mobilgeräten das Containerfeld überlagerte. Alles behebbar, aber eben vorhanden. Geschätzte Kosten: circa 5 $.

Das ergibt eine 3,5-fache Differenz bei der Laufzeit. Eine 5-fache Differenz bei den Kosten. Bei einem Output, der nach fünfzehn Minuten QA im Hinblick auf Lieferfähigkeit im Wesentlichen gleichwertig war.

Hier kam die eigentliche Überraschung: GPT 5.5 nutzte deutlich weniger Output-Tokens – nicht, weil weniger Code generiert wurde, sondern weil der Code komprimierter war. Im direkten Vergleich der Diffs zeigte Opus 4.7 mehr Kommentare, mehr Leerzeilen und mehr „Erklärtexte“ innerhalb des Codes selbst. GPT 5.5s Output las sich wie von einem Senior Engineer, dem man gesagt hat, er solle maximale Klarheit statt ausführlicher Selbst-Dokumentation anstreben. Weniger Prosatext, mehr Substanz.

Bisher habe ich „weniger Output-Tokens“ mit „weniger detailliertem Output“ gleichgesetzt. Stimmt nicht. Es bedeutet einen anderen Codestil – bei gleichem Funktionsumfang. Diese Unterscheidung ist wichtig, denn GPT 5.5s Effizienz resultiert nicht aus Unvollständigkeit, sondern aus Kompression.

Profi-Tipp: Wenn du Kundenstunden für KI-unterstützte Builds abrechnest, hat schon dieses einzelne Experiment mein Codex-Abo für den Monat gerechtfertigt. Dreieinhalbmal schneller bei Standardaufträgen ist keine bloße Benchmark-Verbesserung – das ist ein echter Workflow-Wechsel.

Aber das war der einfache Build. Beim nächsten gab es eine Wendung.

Experiment 2: Sonnensystem-Simulation — Wo Opus zurückschlug

Der Prompt: „Erstelle eine interaktive Sonnensystem-Simulation mit anpassbarer Umlaufgeschwindigkeit, anklickbaren Planeten mit Infopanels und genauer relativer Skalierung.“

Hier erwartete ich erneut, dass GPT 5.5 beim Tempo siegt. Das tat es. Knapp. Vielleicht 30 Sekunden schneller bei einer Aufgabe, die insgesamt etwa 8 Minuten dauerte.

Doch die Aufschlüsselung wurde schnell interessant.

GPT 5.5 benötigte mehr Eingabe-Tokens, weil Codex’ Tool-Calling-Funktion breiter gefächert war — mehrere Dateizugriffe, mehrere Suchanfragen, mehr Kontext-Wechsel. Das Harness von Opus 4.7 war bei der Informationsbeschaffung wesentlich zurückhaltender. Das Ergebnis: GPT 5.5 war minimal schneller, aber auch geringfügig teurer, während Opus 4.7 sichtbar bessere Umlaufproportionen und eine ansprechendere Farbpalette bot.

Dieses Experiment widerlegte meine These, dass „GPT 5.5 beim Preis gewinnt“. Ausgabe-Tokens sind nur die halbe Rechnung. Eingabe-Tokens zählen auch, und durch Codex’ aggressivere Tool-Nutzung kann GPT 5.5 bei den Input-Kosten verlieren, selbst wenn es bei der Ausgabe gewinnt. Die Gesamtkosten hängen am Harness — nicht nur am Modell.

Müsste ich für einen Kunden ein Sonnensystem-Widget liefern, würde ich auf Opus 4.7s Version setzen. Es sah mehr nach etwas aus, das ein Designer abnicken würde. Das ist keine Kennzahl, die man messen kann. Das ist eine Ermessensfrage. Und bei Urteilen über visuelle Proportionen hat Opus 4.7 weiterhin einen Vorsprung, den GPT 5.5 noch nicht ganz eingeholt hat.

Ich will aber ehrlich sein: Die $1 Kostendifferenz ist für die meisten Projekte nur Rundungsfehler. Wenn Sie einmalige Prototypen bauen, ist dieses Experiment nicht ausschlaggebend für Ihre Modellwahl. Das nächste schon.

Experiment 3: 3D Space Shooter — Das Ergebnis, das meine Meinung geändert hat

Ich ging in dieses Experiment mit der Erwartung, dass Opus 4.7 gewinnen würde. Spiel-Logik, Echtzeit-Steuerung, Soundeffekte — das schien eine Domäne, in der Opus’ tiefere Reasoning-Fähigkeiten punkten würden.

Dem war nicht so.

Das Prompt: "Erstelle einen spielbaren 3D-Weltraum-Shooter mit flüssiger Spielersteuerung, feuernden Feind-Schiffen, Partikeleffekten bei Treffern, Soundeffekten und einem Punktesystem. Sorge dafür, dass es wirklich Spaß macht."

GPT 5.5 war nach etwa vier Minuten fertig. Die Steuerung fühlte sich flüssig an. Die Physik war präzise — Projektile bewegten sich auf natürlichen Flugbahnen, Feindschiffe wichen auf glaubwürdige Weise aus, die Kamera folgte ohne zu ruckeln. Ich spielte etwa zehn Minuten, bevor mir wieder einfiel, dass ich eigentlich testen wollte. Es hat tatsächlich Spaß gemacht. Geschätzte Kosten: unter 3 $.

Opus 4.7 war nach etwa sechs Minuten fertig. Die Soundeffekte waren besser — abwechslungsreicher, besser abgemischt, die Explosionen klangen dramatischer. Aber die Steuerung war unausgereift. Die Spielerbewegung hatte Input-Lag. Die Schuss-Abklingzeit war schlecht abgestimmt. Bei der KI der Feinde gab es einen Bug, durch den die Schiffe kurz einfrieren, wenn man sich hinter sie bewegt. Geschätzte Kosten: etwa 4,50 $.

Ich habe beide Versionen zweimal getestet, um sicherzugehen, dass ich nicht voreingenommen war. Das Ergebnis war identisch. GPT 5.5s Spiel war in den wichtigsten Aspekten eines Spiels besser — beim Spielgefühl von Moment zu Moment — und Opus 4.7 überzeugte eher beim Feinschliff, der aber wertlos ist, wenn das Gameplay nicht stimmt.

Hier musste ich mein mentales Modell davon, worin diese beiden Modelle wirklich stark sind, überarbeiten. Früher habe ich Opus 4.7 bei „besser im komplexen Reasoning“ eingeordnet und GPT 5.5 (bzw. Codex insgesamt) bei „besser in schneller Iteration“. Das passt heute nicht mehr ganz. GPT 5.5 trifft Game-Feel-Entscheidungen besser, weil das Modell bei Timing, Reaktionskurven und Feedback-Loops mutiger voreingestellte Entscheidungen trifft. Opus 4.7 ist vorsichtiger — es baut mehr Konfigurierbarkeit ein, mehr „möchte der User das noch abstimmen?“ — und liefert dadurch flexibeleren Code, der jedoch mit schlechteren Standardwerten kommt.

Für Game Prototyping ist das ein Problem. Defaults sind wichtig. Spieler passen keine Slider an, bevor sie entscheiden, ob ein Spiel Spaß macht.

Wenn du bis hierhin gelesen hast, bekommst du schon die Version dieses Vergleichs, die reine Benchmark-Posts nicht liefern. Die tatsächliche Erfahrung beim Einsatz dieser Modelle in echten Projekten deckt sich kaum mit den Ranglisten. Was mich zum letzten Experiment bringt, bei dem beide Modelle mich überrascht haben.

Experiment 4: Ökosystem-Simulation — Wo beide Modelle an ihre Grenzen stoßen

Der Prompt: "Erstelle eine interaktive Ökosystem-Simulation mit Raubtieren, Beute und Pflanzen. Inklusive Fortpflanzung, Hunger, Alterung und Tod. Die Population sollte ohne manuelles Eingreifen ein stabiles Gleichgewicht erreichen."

Das ist der One-Shot-Prompt, an dem jedes KI-Codierungsmodell scheitert. Ich weiß, dass es scheitert. Ich habe ihn trotzdem aufgenommen, weil es aufschlussreicher ist zu sehen, wie ein Modell scheitert, als bloß zu beobachten, wie es erfolgreich ist.

GPT 5.5 lief etwa zehn Minuten lang. Das Modell generierte eine funktionierende Simulation mit allen geforderten Entitäten. Die Populationsdynamik war jedoch defekt — die Raubtiere starben innerhalb von dreißig Sekunden aus, weil ihr Hunger schneller stieg, als sie sich fortpflanzen konnten. Verbrauchte ungefähr doppelt so viele Input-Tokens wie Opus, aber deutlich weniger Output-Tokens. Gesamtkosten: leicht höher als bei Opus.

Opus 4.7 benötigte etwa zwölf Minuten. Hier war der Fehler umgekehrt: Die Beute reproduzierte sich zu schnell und der Bildschirm war nach vierzig Sekunden von ihnen überflutet, woraufhin die Framerate einbrach. Weniger Input-Tokens, mehr Output-Tokens. Insgesamt etwas günstiger.

Keines der Modelle erreichte ein Gleichgewicht. Keine Simulation war ohne Nachbearbeitung brauchbar. Doch die Art des Scheiterns verriet mir bei beiden Modellen etwas Nützliches.

Der Fehler von GPT 5.5 war mathematisch. Die Simulationslogik war strukturell korrekt — lediglich die Parameter mussten angepasst werden: Die Hungerkurve, die Fortpflanzungsrate, die Alterungsformel. Werte, die ich in fünf Minuten ändern könnte.

Der Fehler von Opus 4.7 war struktureller Natur. Die Simulation enthielt einen logischen Fehler bei der Auslösung der Fortpflanzung — jede Entität mit Fitness oberhalb eines Schwellenwerts reproduzierte sich in jedem Tick, anstatt nur alle N Ticks. Um das zu korrigieren, müsste ich die Schleife refaktorieren. Mindestens zwanzig Minuten Arbeit.

Das passt zu einem Muster, das ich die ganze Woche gesehen habe. Wenn GPT 5.5 scheitert, sind die Fehler meist durch simples Finetuning behebbar. Wenn Opus 4.7 bei komplexen One-Shots versagt, sind die Fehler häufig fundamentaler Architektur-Natur. Das gilt nicht immer, aber oft genug, dass ich es mittlerweile in meine Modellwahl einbeziehe. Abstimmungsfehler lassen sich günstig korrigieren. Strukturfehler kosten echte Entwicklungszeit.

In diesem Experiment liegt eine dritte Lektion verborgen. Beide Modelle haben für eine defekte Simulation ungefähr 3 bis 5 $ verbrannt. Wer diese Tools für wirklich komplexe Forschungsaufgaben nutzt, muss mit zwei bis drei Iterationen kalkulieren — nicht mit einer. Wer Ihnen „One-Shot to Production“ verkauft, verkauft die Demo, nicht den Workflow.

Die Gesamtergebnisse aller vier Experimente

Hier sind die Gesamtergebnisse aller vier Builds.

GPT 5.5 absolvierte dieselben vier Builds in etwa der halben Echtzeit. Verwendete 3,5-mal weniger Ausgabetokens. War trotz des doppelten Preises pro Token minimal günstiger. Das ist das zentrale Ergebnis – und es ist substanziell.

Aber hier kommt der Teil, den diese Headline-Zahlen verschleiern: Der Verbrauch an Eingangstokens bei GPT 5.5 war höher. Falls dein Workload inputlastig ist – lange Kontextfenster, große Codebaseloads, Dokumentenanalyse – ist dieser Unterschied entscheidend. Opus 4.7 bietet zudem mit seinem 1-Million-Token-Kontextfenster einen deutlich größeren Arbeitsbereich als GPT 5.5 mit seinem Limit von 400.000 Tokens. Für Codebase-weite Refactorings in produktiven Anwendungen hat Opus 4.7 weiterhin den größeren Arbeitsspeicher.

Ich habe das Freischalten der Millionen-Token-Kontextgrenze ausführlich in meinem GPT 5.4-Review von Anfang des Jahres behandelt – und das meiste, was ich damals zum Umgang mit Kontextfenstern gesagt habe, gilt bei GPT 5.5 mit dem 400K-Limit sogar noch stärker. Du kannst keinen 800K-Token-Laravel-Monolithen in GPT 5.5 laden. In Opus 4.7 ist das möglich. Für manche Teams entscheidet allein dieser Fakt den Vergleich.

Die vier Dinge, die GPT 5.5 wirklich verbessert hat

OpenAI bewirbt mit dem Release von 5.5 vier zentrale Vorteile. Nach einer Woche intensiven Testens zeigt sich, was davon tatsächlich hält.

Token-Effizienz. Echt. Bestätigt. Über vier völlig verschiedene Builds hinweg verbrauchte GPT 5.5 nur einen Bruchteil der Output-Tokens, die Opus 4.7 für vergleichbare funktionale Ergebnisse benötigt hat. Das ist die größte ökonomische Verbesserung – und kein Marketing: Sie taucht direkt auf der Rechnung auf.

Autonome Dekomposition. Teilweise echt. Bei vagen Prompts trifft GPT 5.5 selbstbewusstere Standardentscheidungen und stellt weniger Rückfragen. Beim Personal-Brand-Site-Experiment sparte das spürbar Zeit. In der Ecosystem-Simulation hingegen traf es falsche Standardentscheidungen, was Zeit kostete. Unterm Strich: nützlich, aber bei wirklich neuartigen Aufgaben sollte man weniger Vertrauen haben.

Codex-Upgrades. Echt. Multi-Agent-Parallelisierung innerhalb von Codex läuft sichtbar schneller als in der Vorgängerversion. Wiederverwendbare Workflows sind ein echtes Quality-of-Life-Upgrade, wenn man eine persönliche Pattern-Bibliothek aufgebaut hat. Die Tool-Calls sind zuverlässiger als in GPT 5.4.

Cybersecurity-Fokus. Das ließ sich in einer Woche nicht umfassend prüfen. Sowohl Anthropic als auch OpenAI behaupten, die adversariale Robustheit ihrer Flaggschiff-Modelle weiter verbessert zu haben. Wer auf dieses Thema Wert legt, sollte selbst Red-Team-Prompts testen. Verlassen Sie sich hierbei nicht auf Marketingversprechen. Einige der grundlegenden Spannungsfelder zwischen Security und KI habe ich bereits Anfang des Jahres im Beitrag zur AI-Zero-Day-Discovery-Debatte analysiert — lohnt sich, wenn Model-Security für den eigenen Stack relevant ist.

Die ehrlichen Kompromisse, über die niemand spricht

Zeit für den Teil, bei dem ich erzähle, was ich einem Freund beim Kaffee sagen würde.

Die Preisverdopplung von GPT 5.5 ist relevanter, als es das Marketing gerne hätte. Ja, die Effizienz pro Ausgabetoken macht es für einige Workloads aufgabenbezogen wettbewerbsfähig. Aber wenn du direkt über die API abrechnest und nicht Codex’ smarteres Kontextmanagement nutzt, kannst du am Ende definitiv höhere Rechnungen haben als bei GPT 5.4. Das Versprechen „mehr mit weniger“ hat Einschränkungen. Die größte Einschränkung: Es hängt davon ab, dass das Framework auch wirklich funktioniert.

Opus 4.7s Millionen-Token-Kontext ist immer noch ein Burggraben. Für alle, die mit großen Codebasen arbeiten – also keine Spielereien, sondern echte produktive Systeme mit hunderten Dateien – verändert das Kontextfenster von Opus 4.7 die Art der Fragen, die du stellen kannst. Ich habe ausführlich darüber geschrieben, als ich die ersten Builds von Opus 4.7 im Vergleich zu meinem eigenen Workflow getestet habe, und das Fazit gilt immer noch. Kontextgröße ist eine Fähigkeit, kein Feature. Die 400K von GPT 5.5 reichen für die meisten Aufgaben aus. Für Aufgaben, bei denen 400K nicht ausreichen, brauchst du Opus 4.7. Es gibt keine Abkürzung.

Das Release-Tempo ist anstrengend. Sechs Wochen zwischen großen Modellen bedeuten, dass der Workflow, den du letzten Monat optimiert hast, diesen Monat vielleicht schon wieder suboptimal ist. Dafür habe ich keine Lösung. Mittlerweile teste ich einfach jedes neue Modell an drei praxisnahen Aufgaben, die ich bereits mit dem vorherigen Modell erledigt habe, und entscheide dann. Alles Komplexere verschlingt Stunden, die ich nicht habe. Wer versucht, bei jedem Release in Echtzeit mitzuhalten, ist ausgebrannt, bevor irgendwas Produktives entsteht.

Die Benchmarks sind nützlich, aber begrenzt. GPT 5.5 liegt beim Terminal Bench 2.0 um 13 Punkte vor Opus 4.7. Es liegt auch bei Frontier Math und Cyber Gym vorne. Das sind echte Indikatoren. Aber „X gewinnt im Benchmark“ bedeutet nicht automatisch, dass es besser für deinen Workflow ist. Mein Space-Shooter-Experiment ist das klarste Beispiel – GPT 5.5 hat den Playability-Test gewonnen, und das hätte kein Benchmark vorhergesehen.

Wenn du einen tieferen Einblick in das breitere Codex-Ökosystem und den Vergleich mit dem Claude-Code-Workflow willst, habe ich sowohl den Vergleich des Zwei-Agenten-Workflows als auch die Aborechnung Codex vs. Claude Code bereits in früheren Beiträgen durchleuchtet. Die Schlussfolgerungen gelten auch für GPT 5.5 weiter – sie sind nur ein wenig interessanter geworden.

Was man wann verwendet: Der Entscheidungsbaum, dem ich tatsächlich folge

Nach dieser Woche intensiven Testens hier das grobe Framework, mit dem ich meine eigenen Projekte durchfiltere.

Verwende GPT 5.5 (über Codex), wenn:

• Du schnell ausliefern musst und das Projekt in 400K Token Kontext passt
• Game-Feel, Mikrointeraktionen oder unmittelbares Feedback relevant sind
• Du autonomes Verhalten auch auf vage Prompts wünschst
• Die Abrechnung auf eingesparte Stunden statt auf verbrauchte Token erfolgt
• Die Aufgabe von wiederverwendbaren Workflow-Mustern profitiert

Verwende Opus 4.7 (über Claude Code), wenn:

• Der Codebase zu groß für GPT 5.5s Kontextfenster ist
• Visuelle Proportionen, Design-Geschmack oder typografische Sorgfalt entscheidend sind
• Du lieber flexiblen, konfigurierbaren Code statt voreingestellter Meinungen willst
• Du vom Modell ausführliche Erklärungen seines Vorgehens benötigst
• Du mit langlaufenden Agenten-Sitzungen arbeitest, bei denen Kontextbeibehaltung wichtig ist

Verwende beide parallel, wenn:

• Die Aufgabe wirklich komplex ist und du zwei konkurrierende Lösungen vergleichen willst
• Du nicht sicher bist, welches Modell das bessere Standardergebnis liefert und du dir die Kosten leisten kannst
• Du Agenten-Workflows baust, bei denen verschiedene Teilaufgaben an unterschiedliche Modelle geroutet werden

Gerade der letzte Punkt beschreibt meiner Meinung nach die eigentliche Entwicklung im kommenden Jahr des AI Codings. Nicht: „Welches Modell ist das beste?“ — sondern Routing-Logik, die pro Subtask im größeren Workflow das jeweils passendste Modell auswählt. Ich habe damit schon experimentiert; es sieht vielversprechend aus, ist aber noch ganz am Anfang. Ein Thema für einen eigenen Beitrag.

Häufig gestellte Fragen

Ist GPT 5.5 besser als Opus 4.7 für das Programmieren?

GPT 5.5 ist schneller, beim Output token-effizienter und bei den meisten Programmieraufgaben etwas günstiger. Opus 4.7 bietet ein größeres Kontextfenster (1 Mio. vs. 400.000 Token) und erzeugt ausgabeorientiertere, designbewusstere Ergebnisse. Für Projekte, die in 400K Token passen, hat GPT 5.5 die Nase vorn. Bei großen Codebases bleibt Opus 4.7 Sieger.

Wie viel kostet GPT 5.5 im Vergleich zu GPT 5.4?

GPT 5.5 hat die Preise von GPT 5.4 verdoppelt — $5/M Input und $30/M Output statt $2,50/M Input und $15/M Output. Das Argument: Weniger Output-Token pro Aufgabe gleichen den höheren Einzelpreis aus. In meinen Tests hat das für die meisten Workloads gestimmt.

Wie groß ist das Kontextfenster von GPT 5.5?

GPT 5.5 unterstützt ein Kontextfenster von 400.000 Token. Opus 4.7 unterstützt 1 Million Token. Für die meisten Programmieraufgaben reichen 400K aus. Für Refactoring ganzer Codebases in großen Produktivsystemen bleibt das größere Kontextfenster von Opus 4.7 die bessere Wahl.

Kann GPT 5.5 Claude Code mit Opus 4.7 ersetzen?

Für manche Workflows ja — insbesondere beim schnellen Prototyping, in der Spieleentwicklung oder bei Aufgaben, bei denen das Game-Feeling zählt. Für langlaufende Agentensitzungen, große Codebases oder designlastige Arbeiten bietet Opus 4.7 innerhalb von Claude Code weiterhin Vorteile. Ich nutze beide parallel und steuere Aufgaben per Entscheidungsbaum (siehe oben) zu.

Funktioniert die autonome Dekomposition von GPT 5.5 wirklich?

Sie ist tatsächlich vorhanden, aber mit wechselnder Qualität. Bei vagen Prompts zu bekannten Problemen (Websites, Standard-Simulationen) trifft das Modell selbstbewusste Standardentscheidungen, die Zeit sparen. Bei wirklich neuen Aufgaben wie Ökosystem-Simulationen setzt es jedoch oft falsche Standards und kostet Zeit. Verlassen Sie sich bei vertrautem Terrain mehr darauf, bei Neuland weniger.

Was ich nächsten Montagmorgen mache

Hier ist die praktische Antwort.

Ich lasse Opus 4.7 weiterhin als Standard für den Agenten, der ein Cross-Codebase-Refactoring auf einem großen Laravel-Projekt durchführt, das ich betreue. Der 1M-Token-Kontext leistet hier Arbeit, zu der sonst nichts in der Lage ist – und das ändert sich diese Woche nicht.

Für meinen Prototyping-Workflow steige ich auf GPT 5.5 über Codex um. Schon allein der 3,5-fache Geschwindigkeitsvorteil beim Experiment mit der Personal-Branding-Seite rechtfertigt diesen Wechsel für Kundenprojekte, bei denen Geschwindigkeit wichtiger ist als visueller Feinschliff. Für die Feinschliff-Phase hole ich Opus 4.7 dann wieder dazu.

Ich richte in den nächsten zwei Wochen einen A/B-Test ein, bei dem ich jeden neuen Prompt parallel durch beide Modelle laufen lasse und verfolge, welche Ergebnisse ich tatsächlich deploye. Bis Mitte Mai habe ich dann echte Daten anstatt nur ein Bauchgefühl. Wenn du den Follow-up-Artikel lesen willst, findest du ihn auf mejba.me, sobald ich ihn veröffentliche.

Was ich nach dieser Testwoche nicht erwartet hatte: Erleichterung. Nicht, weil eines der Modelle einen klaren Sieg errungen hätte. Sondern, weil beide Modelle jetzt so gut sind, dass die Wahl zwischen ihnen eine Workflow-Optimierung ist – und kein qualitativer Kompromiss mehr. Die Zeit ist vorbei, in der man das beste Modell nehmen musste und mit dessen Schwächen leben musste. Jetzt wählst du das passende Modell zur Aufgabe. Das ist ein deutlich angenehmeres Problem.

Die eigentliche Frage ist nicht „GPT 5.5 vs Opus 4.7“. Es ist: „Zu welchem Modell greifst du morgen früh um 9 Uhr, wenn bis 17 Uhr etwas gebaut werden muss?“ Beantworte das für dich selbst anhand des Vier-Experimente-Rahmens oben und du wirst mehr sparen, als dir irgendein Benchmark-Zettel verraten kann.

Also, geh und führe deine eigenen vier Experimente durch. Vertraue nicht meinen. Vertraue niemandem. Mach deine eigenen.

Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsservices): xcybersecurity.io