GPT-5.5 verändert deine Model-Routing-Kalkulation

OpenAI hat diese Woche GPT-5.5 veröffentlicht — positioniert als bislang stärkstes Modell: schneller, besser auf Coding- und Research-Tasks, und gebaut für den Einsatz im Tool-Use-Kontext. Der erste Instinkt vieler CTOs: Upgrade-Frage. Ist es nicht. Es ist ein Anlass, jede Routing-Entscheidung zu überprüfen, die du getroffen hast, als GPT-4o oder o3 die Preis-Qualitäts-Baseline gesetzt haben — denn diese Baseline gilt nicht mehr.

Was sich mit GPT-5.5 geändert hat

OpenAI beschreibt GPT-5.5 als ihr bislang intelligentestes Modell, mit besonders deutlichen Gewinnen bei komplexen, mehrstufigen Tasks: Coding, Research-Synthese und Datenanalyse über Tool-Integrationen hinweg. Die Betonung von Tool Use ist kein Zufall — das hier ist kein reiner Benchmark-Lift auf isolierten Prompts. Das Modell ist explizit dafür ausgelegt, besser zu performen, wenn es in einem agentic Loop mit Retrieval, Code Execution oder externen APIs läuft.

Die Veröffentlichung folgt einem komprimierten Takt. GPT-4o kam vor etwa 12 Monaten; GPT-4.5 früher in diesem Jahr; GPT-5.5 ist bereits da. Dieses Tempo signalisiert: OpenAI fährt einen kontinuierlichen Capability-Upgrade-Zyklus, keinen 12-bis-18-Monate-Generationenrhythmus. Wer Routing-Entscheidungen in die Infrastruktur eingebaut hat und seit GPT-4o nicht neu gebenchmarkt hat, sollte diesen Rückstand als aktiv anwachsende Technical Debt behandeln.

Pricing-Details zum Zeitpunkt der Veröffentlichung findest du in der OpenAI-API-Dokumentation — aber das Muster aus früheren Releases gilt weiterhin: Flagship-Capability kommt zu Premium-Token-Kosten, während frühere Flaggschiffe in die Mid-Tier repriced werden. Genau da wird die Routing-Kalkulation interessant.

Warum das die Mathematik deines aktuellen Stacks zurücksetzt

Die meisten Production-AI-Stacks laufen nicht mit einem einzigen Modell — sie laufen mit einem Routing-Layer, auch wenn das informell ist. Ein Classification-Task geht an ein schnelleres, günstigeres Modell. Eine kundenseitige Zusammenfassung an etwas Mid-Tier. Eine Vertragsanalyse oder komplexe Code-Generierung ans Flagship. Dieses Tiering war sinnvoll, solange der Capability-Gap zwischen GPT-4o und einem kleineren Modell das Kostendelta rechtfertigte. GPT-5.5 verschiebt zwei Dinge gleichzeitig: was das Flagship kann, und was das vorherige Flagship jetzt kostet.

Was die meisten Artikel übersehen: Regressions-Risiko auf Prompt-Ebene. Prompts, die auf GPT-4o-Verhalten getunt wurden — seine Ausführlichkeit, seine Tendenz zu hedgen, sein Umgang mit mehrdeutigen Anweisungen — können auf GPT-5.5 andere Outputs liefern, selbst bei Tasks, bei denen die Qualität nominell steigt. Wenn deine Evals gegen GPT-4o-Outputs geschrieben wurden, bedeutet ein höherer BLEU-Score oder eine bessere LLM-as-Judge-Bewertung nicht automatisch, dass sich deine Downstream-Applikation wie erwartet verhält. Du musst deine Eval-Suite gegen repräsentative Production-Inputs durchlaufen lassen, bevor du Live-Traffic umroutest.

Dazu kommt ein Schwelleneffekt bei agentic Workloads. Wenn du Agents hast, die aktuell GPT-4o für Tool-Calling-Entscheidungen nutzen und für die Synthese auf ein günstigeres Modell zurückfallen, kann GPT-5.5's berichtetes Plus bei mehrstufigem Tool Use bedeuten, dass du konsolidieren kannst — weniger Hops, niedrigere Latency, potenziell niedrigere Gesamtkosten trotz höherem Per-Token-Preis. Das ist die Arbitrage, die sich diese Woche zu modellieren lohnt.

Sprich mit Domani AI darüber, wie wir das gemeinsam angehen →

Was ein CTO vor Freitag tun sollte

Die wertvollsten 4 Stunden dieser Woche: ein strukturiertes Prompt-Audit gegen GPT-5.5 auf deinen 10 produktionskritischsten Prompt-Templates durchführen. Kein Bauchgefühl-Check — ein gescortes Eval mit demselben Rubric, den dein Team bereits für Output-Qualität verwendet. Das Ziel ist eine Routing-Entscheidungsmatrix: Tasks, bei denen GPT-5.5 dein aktuelles Modell bei akzeptablen Kosten klar übertrifft; Tasks, bei denen es gleichwertig ist (Linie halten, Tokens sparen); und Tasks, bei denen der Behavior-Shift ein Regressions-Risiko erzeugt, das du vor jeder Migration adressieren musst.

Wenn du keine formale Eval-Suite hast, ist das der eigentliche Move für Montag — nicht das Model-Upgrade. Ein Production-AI-Workload ohne gescorte Evals fliegt blind. GPT-5.5 ist ein guter Forcing-Faktor, das zu beheben — denn das nächste Flagship kommt noch vor Jahresende, und das Problem potenziert sich.

Konkrete Schritte für die Woche:

• Zieh deine Top-10-Prompt-Templates aus den Production-Logs — nach Call-Volumen oder Business-Kritikalität, nicht nach deiner Intuition darüber, was wichtig ist
• Lauf jeden Prompt gegen dein aktuelles Modell und GPT-5.5 mit identischen Inputs; score die Outputs mit deinem bestehenden Rubric (oder bau in 30 Minuten einen 3-Punkte-Rubric, wenn du keinen hast)
• Markiere alle Outputs, bei denen GPT-5.5 Struktur oder Format so verändert, dass dein Downstream-Parsing davon abhängt — das sind deine Regressions-Risiken
• Modelliere das Token-Kostendelta für jeden Workload beim aktuellen Traffic-Volumen; identifiziere die 2–3 Workloads, bei denen eine Konsolidierung auf GPT-5.5 sowohl Qualität als auch Wirtschaftlichkeit verbessert
• Triff eine Routing-Entscheidung — migriere nicht alles auf einmal; beweise den Prozess zuerst an einem Workload

Was das kostet, und wo es spart

Das ehrliche Trade-off: Die Migration zu einem neuen Flagship-Modell mid-cycle kostet Engineering-Zeit, die du wahrscheinlich nicht budgetiert hast — 2 bis 4 Tage für einen disziplinierten Eval-und-Routing-Pass über einen mittelgroßen Stack, mehr, wenn dein Prompt-Layer mit Application-Logik verflochten statt sauber abstrahiert ist. Wenn du 6 Wochen wartest, verpasst du das Fenster, um Kosten-Arbitrage aus dem Repricing von GPT-4o in die Mid-Tier zu schöpfen — und deine Agents laufen weiter auf einem Modell, das bei Tool-Calling-Performance jetzt eine Generation hinterherhinkt.

Das Einsparpotenzial liegt konkret bei agentic Workloads. Wenn GPT-5.5 die Anzahl der nötigen Model-Calls pro Agent-Task reduziert — weniger Fallbacks, weniger Clarification-Loops — können die Per-Task-Kosten sinken, selbst wenn der Per-Token-Preis steigt. Diese Kalkulation ist workload-spezifisch, und du wirst sie nicht kennen, bis du das Audit durchgeführt hast. Das Risiko, es nicht zu tun: Ein Wettbewerber, der es tut, hat bis Q3 niedrigere Inference-Kosten und schnellere Response-Zeiten auf derselben Klasse von Tasks.