GPT-5.5: Was Sie jetzt tun können, statt zu warten

GPT-5.5: Was Sie jetzt tun können, statt zu warten

Vor drei Tagen hätte ich beinahe einen völlig anderen Beitrag geschrieben. Der Entwurf, der in meinem Obsidian-Vault lag, trug einen Titel wie „GPT-5.5 First Look“ und enthielt einen Platzhalter für Benchmarks, die ich sofort einfügen wollte, sobald OpenAI ausliefert. Jeden Morgen habe ich Polymarket beobachtet, den OpenAI-Blog zu seltsamen Uhrzeiten aktualisiert und mich generell so verhalten, als würde ich auf ein Paket warten, das ich schon bezahlt habe.

Dann schickte mir ein Freund am Sonntag um 23:47 Uhr einen Screenshot von einem weiteren „GPT-5.5 CONFIRMED APRIL 15“-YouTube-Thumbnail. Er wollte wissen, ob er seine Produktionsmigration auf GPT-5.4 verschieben und „einfach ein paar Wochen auf 5.5 warten“ sollte.

Ich habe diese Nachricht lange angestarrt.

Denn die ehrliche Antwort ist: Niemand weiß, wann 5.5 erscheint. Niemand weiß, ob es als 5.5 oder unter einem anderen Namen veröffentlicht wird. Und die Entwickler, die seit GPT-4 auf OpenAI aufbauen, wissen genau, was passiert, wenn man echte Arbeit pausiert, um auf ein noch nicht veröffentlichtes Modell zu warten – man verliert den Vorsprung, zahlt die Opportunitätskosten und dann kommt das Release mit Migrationshürden, auf die man nicht vorbereitet war.

Also habe ich den Entwurf gelöscht und stattdessen diesen Beitrag geschrieben. Das ist der Post, den ich mir für meinen Freund um 23:47 Uhr gewünscht hätte. Es ist der aktuelle GPT-5.5-Status in klarem Deutsch – bestätigte Fakten, fundierte Schlussfolgerungen und deutlich gekennzeichnete Spekulationen – und es ist genau das Playbook, das ich aktuell mit GPT-5.4 fahre, damit beim nächsten Modellwechsel die Migration ein Konfigurationswechsel und kein Rewrite wird.

Heute ist der 15. April 2026. Legen wir los.

Was ist derzeit tatsächlich über GPT-5.5 bestätigt?

Bevor ich Ihnen sage, was Sie bauen sollten, muss ich Ihnen sagen, was real ist. Die Informationshygiene zu diesem Thema war in den letzten Wochen wirklich schlecht, und ich habe beobachtet, wie Ingenieure auf Basis von TikTok-Thumbnails Planungsentscheidungen getroffen haben. Lassen Sie mich das Signal vom Nebel trennen.

Hier ist, was sich zum 15. April 2026 anhand von Primärquellen tatsächlich verifizieren lässt.

GPT-5.5 wurde weder offiziell angekündigt noch veröffentlicht. Es gibt keinen OpenAI-Blogpost, der es vorstellt. Keine Model Card. Kein Preisblatt. Kein API-Endpunkt, den Sie ansprechen könnten. Wenn Sie diese Woche von einem „GPT-5.5 Benchmark-Leak“ lesen, handelt es sich entweder um jemanden, der einen Pre-Release-Gateway testet, auf den er keinen Zugriff haben sollte, oder – weitaus häufiger – um jemanden, der 5.4 nutzt und es falsch etikettiert.

Das aktuelle Produktions-Flaggschiff ist GPT-5.4, das am 5. März 2026 gestartet ist. Das ist das Modell, auf dem Sie heute aufbauen sollten, Punkt. Alles im zweiten Teil dieses Artikels geht davon aus, dass Sie auf 5.4 sind oder den Umstieg planen.

Es gibt tatsächlich ein OpenAI-Modell in der Safety-Evaluierung mit dem internen Codenamen „Spud“. Dies wurde von mehreren Medien mit OpenAI-Quellen bestätigt, und Sam Altman hat öffentlich erklärt, dass das Pre-Training am 24. März 2026 abgeschlossen wurde. Greg Brockman beschreibt es in Podcasts mit ungewöhnlich aufgeladener Sprache – „zwei Jahre Forschung“, „Big Model Feel“ – was historisch auf Sprunginnovationen und nicht auf inkrementelle Updates hindeutet.

Ob Spud als GPT-5.5 oder GPT-6 veröffentlicht wird, ist öffentlich nicht entschieden. OpenAI hat erklärt, dass das Branding davon abhängt, wie signifikant der Leistungssprung gegenüber 5.4 ausfällt. Das ist die mit Abstand wichtigste Einschränkung in der gesamten Diskussion. Die Hälfte der Inhalte im Internet setzt „Spud“ und „GPT-5.5“ gleich, als wären sie austauschbar. Das sind sie nicht. Spud ist ein Codename. GPT-5.5 ist ein hypothetischer Produktname, der verwendet werden kann oder auch nicht.

Polymarket-Händler geben aktuell eine Wahrscheinlichkeit von ca. 78 % für einen Release bis zum 30. April an und über 95 % bis zum 30. Juni 2026. Das ist ein Marktsignal, keine Tatsache, aber ein nützlicher Kontext für Ihre Planungsfenster.

Das ist die bestätigte Faktenlage. Jetzt gebe ich Ihnen meine Einschätzung zu den drei wirklich entscheidenden Fragen.

Frage 1: Existiert „Spud“ als reales Modell, das sich derzeit in der Safety-Evaluierung befindet?
Mein Vertrauen: mittel-hoch. Die Quellenlage ist solide, das Pre-Training-Datum ist belegt, und das Verhalten von OpenAI (Sora am selben Tag abschalten, um Rechenleistung umzuschichten) passt zu einer ernsthaften Launch-Vorbereitung.

Frage 2: Wird es explizit als „GPT-5.5“ veröffentlicht?
Mein Vertrauen: niedrig-mittel. Das ist wirklich ein Münzwurf. Ist der Benchmark-Sprung gegenüber 5.4 inkrementell, ist 5.5 wahrscheinlich. Ist es ein echter Generationssprung, wird GPT-6 als Branding plausibler. Gehen Sie nicht vom Namen aus.

Frage 3: Kommt es heute – oder genau diese Woche – heraus?
Mein Vertrauen: niedrig. „Wochen entfernt“ bedeutet in Altman-Sprache historisch vier bis acht Wochen, nicht fünf bis zehn Tage. Das wahrscheinlichste Zeitfenster ist Ende April bis Ende Mai. Wer Ihnen jetzt ein konkretes Datum nennt, rät.

Wenn Sie Ihre Roadmap auf „Spud = GPT-5.5 = 15. April“ aufgebaut haben, haben Sie auf Nebel gebaut. Lassen Sie uns auf etwas Solideres setzen.

Warum Warten die Schlechteste Strategie Ist

Hier ist das, was die meisten Entwickler übersehen, wenn ein neues Frontier-Modell angekündigt wird. Die richtige Frage ist nicht: „Wann erscheint 5.5?“ Die richtige Frage lautet: Wie viel Wert lasse ich jeden Tag liegen, an dem ich 5.4 nicht voll ausnutze?

Denn 5.4 ist tatsächlich ein bedeutendes Modell. Ich habe es jetzt seit sechs Wochen intensiv im Einsatz. Lassen Sie mich Ihnen die Zahlen nennen, die wirklich zählen.

Beim GDPval – dem Knowledge-Work-Benchmark, der die Modellleistung mit Branchenprofis an realen Aufgaben misst – erzielt GPT-5.4 83,0 %, gegenüber 70,9 % bei 5.2. Das ist ein absoluter Sprung von zwölf Punkten in einer einzigen Minor-Version. Es ist das größte GDPval-Delta zwischen zwei aufeinanderfolgenden GPT-5.x-Releases.

Beim OSWorld-Verified, dem Benchmark für Computeranwendungen, erreicht 5.4 einen Wert von 75 % und übertrifft damit den Human-Expert-Baseline von 72,4 %. Von 47,3 % bei 5.2 ist das ein Quantensprung. Das ist die Art von Delta, die nicht nur Prozesse beschleunigt, sondern grundlegend neue Möglichkeiten in Automatisierungspipelines eröffnet.

Die faktische Fehlerquote ist bei Standard-Prompts um 33 % gegenüber 5.2 gesunken und bei Thinking-Mode-Prompts um 18 %. In meiner tatsächlichen Nutzung bedeutet das: Ich entdecke weniger Halluzinationen beim Post-Editing, verbringe weniger Zeit mit der Überprüfung von Zitaten und kann den Tool-Call-Argumenten des Modells mehr vertrauen.

Und die Features, die mit 5.4 ausgeliefert wurden, unterscheiden sich grundlegend von allem, was zuvor kam: ein Kontextfenster mit 1 Mio. Tokens (128K Output-Limit), Tool Search mit Deferred Loading, sodass Agents nicht an riesigen Tool-Manifests ersticken, native Computerbedienung, die Screenshots interpretiert und Maus/Tastatur steuert, sowie native Kompaktierung, die langlaufende Kontexte verwaltet, ohne dass Sie selbst Zusammenfassungen bauen müssen.

Also die Frage an Ihr Team: Nutzen Sie das alles schon wirklich aus?

Bei den meisten Teams, mit denen ich gesprochen habe, lautet die Antwort nein. Sie haben den model-Parameter migriert und das Thema damit abgehakt. Sie betreiben 5.4 exakt so wie 5.2. Das heißt, sie zahlen für 5.4 und schöpfen nur 60 % des Werts ab.

Der eigentliche strategische Schritt ist jetzt nicht, auf 5.5 zu warten. Es geht darum, den vollen Wert aus 5.4 zu ziehen und gleichzeitig Ihre Infrastruktur so vorzubereiten, dass Sie am Tag des 5.5-Releases – wann immer das sein mag, wie immer es heißen wird – mit einem einzigen Pull Request umsteigen können.

Darum geht es im Rest dieses Beitrags.

Die Multimodalitätsfrage (Und Warum Ich Sie Deutlich Markiere)

Bevor ich den Playbook-Ansatz vorstelle, muss ich die Spekulationen rund um Multimodalität gezielt ansprechen – denn hier sehe ich das meiste unbegründete Selbstvertrauen.

Was 5.4 tatsächlich kann: Text und Bild als Eingabe. Text als Ausgabe. Keine native Audioverarbeitung. Keine native Videogenerierung. Kein Echtzeit-Voice direkt in 5.4 – Sprache wird von separaten Modellen im OpenAI-Stack verarbeitet.

Was über 5.5 spekuliert wird: Umfangreichere Multimodalität – irgendeine Kombination aus Audio-Ein-/Ausgabe, Videoverständnis, möglicherweise sogar einheitliches multimodales I/O in einem einzigen Modell.

Hier meine ehrliche Einschätzung: Eine gewisse multimodale Erweiterung ist wahrscheinlich, aber die Details sind völlig unbestätigt. Ich habe keinerlei direkte Hinweise darauf, was Spud mit nicht-textbasierten Modalitäten macht. Die strategische Ausrichtung von OpenAI deutet klar auf multimodale Agenten hin, und Brockmans Formulierung vom „big model feel“ könnte durchaus eine Erweiterung der Fähigkeiten über verschiedene Modalitäten hinweg implizieren. Sie könnte aber genauso gut rein textbasierte Verbesserungen im Reasoning meinen.

Wenn Ihr Produkt-Plan aktuell davon ausgeht, dass „5.5 bis Q3 natives Videoverständnis haben wird“ – bauen Sie auf Sand. Tun Sie das nicht. Planen Sie mit den Fähigkeiten im Stil von 5.4 und betrachten Sie jede multimodale Erweiterung als Bonus, nicht als Standard.

Kommen wir nun zu dem, worauf Sie heute tatsächlich aufbauen können.

Die echte Preismathematik, die Sie in Ihrer Tabelle brauchen

Jedes Migrations-Playbook, das ich Ihnen gleich vorstelle, hängt davon ab, dass Sie ein realistisches Kostenmodell haben. Die meisten Teams haben das nicht. Also machen wir das konkret, bevor wir über Architektur sprechen.

Hier ist die aktuelle GPT-5.4-Preisstruktur, die Sie in Ihrem Kostenrahmen abbilden müssen:

• Input: $2,50 pro 1 Mio. Tokens
• Gecachter Input: $0,25 pro 1 Mio. Tokens (das sind 90 % Rabatt — und gilt automatisch, wenn aufeinanderfolgende Anfragen ein gemeinsames Präfix haben)
• Output: $15,00 pro 1 Mio. Tokens

Jetzt kommt der Teil, der Teams oft überrascht. Für Prompts mit mehr als 272.000 Input-Tokens überschreiten Sie eine Schwelle, bei der die Preise auf 2x Input und 1,5x Output für die gesamte Session steigen. Das gilt für Standard-, Batch- und Flex-Tarife. Wenn Sie also einen kompletten Codebase-Kontext einspielen — was, um das klarzustellen, oft sinnvoll ist — zahlen Sie den Premium-Tarif, nicht den Basispreis. Modellieren Sie Ihre Tabelle entsprechend.

Dann gibt es noch die Service-Tiers, die fast niemand, mit dem ich spreche, strategisch nutzt:

• Batch: ~50 % Rabatt auf Standard, 24 Stunden asynchrone Verarbeitung. Ideal für Offline-Workloads — Massenklassifizierung, Datenanreicherung, rückwirkende Analysen. Wenn Ihr Workload eine Übernacht-Bearbeitung verkraftet, verschenken Sie jeden Tag 50 %, wenn Sie ihn nicht über Batch laufen lassen.
• Flex: Günstigere Preise für Responses oder Chat Completions, langsamere Antwortzeiten, gelegentliche Ressourcenknappheit. Für nicht-produktive, Hintergrund- oder Low-Priority-Jobs. Noch ein großer Rabatt gegenüber Standard, wenn Latenz keine Rolle spielt.
• Priority: Premium-Preise für deutlich niedrigere und konsistentere Latenz. Für nutzerorientierte Echtzeitanwendungen, bei denen p99-Latenz ein Business-Metrik ist.
• Standard: Der ausgewogene Standard-Tarif.

Eine einfache Regel, die ich befolge: Kategorisieren Sie jeden Workload, den Sie betreiben, als einen von {nutzerorientiertes Echtzeit, Hintergrundjobs, Offline-Bulk} und routen Sie ihn in den passenden Tier. Führen Sie nicht alles standardmäßig über Standard aus. Das ist die mit Abstand einfachste Kostenreduktion, die die meisten Teams übersehen.

Noch ein Hinweis zur API-Oberfläche. Wenn Sie noch nicht auf die Responses API umgestellt haben, tun Sie es jetzt. Die Responses API erhält Response-IDs so, dass sinnvolles Conversation Threading möglich ist und ist die Zieloberfläche für die meisten neuen OpenAI-Funktionen in Zukunft. Wer 2026 noch neuen Code gegen Chat Completions schreibt, bereitet sich aktiv auf spätere Migrationsarbeit vor. Für einen tieferen Einblick, wie ich das in einem echten Kundenprojekt strukturiert habe, lesen Sie meinen vollständigen GPT-5.4 Coding Model Review.

Das ist das Fundament. Jetzt zur Architektur.

Die Config-Flip-Architektur — Damit Sie 5.5 mit einem PR übernehmen können

Das ist das Herzstück des Playbooks. Alles in diesem Abschnitt verfolgt ein Ziel: Wenn OpenAI das nächste Frontier-Modell veröffentlicht, ist Ihre Migration eine Konfigurationsänderung, kein Refactoring.

1. Modell-IDs hinter einem Config-Flag isolieren

Der mit Abstand häufigste Fehler, den ich sehe, sind hartkodierte Modell-Strings im gesamten Codebase. Sie finden "gpt-5.4" in siebzehn Dateien – jede für sich ein kleiner Aufwand, aber in Summe ein riesiger, wenn Sie sie austauschen müssen.

Stellen Sie jede Modellreferenz hinter einen Config-Key. Zum Beispiel so:

# config.py
MODELS = {
    "primary": os.getenv("MODEL_PRIMARY", "gpt-5.4"),
    "fast": os.getenv("MODEL_FAST", "gpt-5.4-mini"),
    "reasoning": os.getenv("MODEL_REASONING", "gpt-5.4-thinking"),
}

Jede Aufrufstelle liest dann aus MODELS["primary"]. Wenn 5.5 erscheint und Sie es auf Ihren Reasoning-Workloads testen wollen, ändern Sie eine Environment-Variable. Kein PR, der siebzehn Dateien anfasst.

Gehen Sie noch einen Schritt weiter: Unterstützen Sie per-Umgebung-Overrides, damit Sie neue Modelle im Staging testen können, ohne die Produktion zu berühren, und per-Workload-Routing, sodass Sie für verschiedene Aufgaben unterschiedliche Modelle einsetzen können, statt ein globales Modell für alles.

2. Bauen Sie Ihre Evals, bevor Sie sie brauchen

Das ist der Punkt, den alle überspringen und später bereuen.

Bevor das nächste Modell erscheint, brauchen Sie eine Testsuite mit echten Aufgaben aus Ihrer Anwendung und bewerteten Ausgaben. Keine synthetischen Benchmarks – Ihre tatsächlichen Workloads. Die Fragen, die Ihre echten Nutzer stellen. Der Code, den Ihr tatsächlicher Codebase benötigt. Die Tool-Calls, die Ihre echten Agents machen.

Sie wollen innerhalb einer Stunde nach Release von 5.5 beantworten können: Übertrifft 5.5 die 5.4 auf unseren spezifischen Workloads, und wenn ja, um wie viel? Ohne Evals ist die Antwort ein Gefühl. Mit Evals ist es eine Zahl.

Das Setup muss nicht aufwendig sein. Zwanzig bis fünfzig echte Aufgaben mit bewerteten Ausgaben (menschlich, nach Rubrik oder durch LLM-Judge bewertet, je nach Aufgabe) reichen aus, um ein echtes Signal zu bekommen. Das OpenAI Evals-Framework ist in Ordnung. Ein selbstgebautes Pytest-Harness ist in Ordnung. Was nicht in Ordnung ist: nichts zu haben und einen Monat nach der Migration festzustellen, dass das neue Modell für Ihren Use Case schlechter ist – und Sie nicht beweisen können, warum.

3. Response-IDs in der Responses API speichern

Wenn Sie die Responses API nutzen (was Sie sollten), erhalten Sie Response-IDs, mit denen Sie auf vorherige Modell-Turns in zukünftigen Requests referenzieren können. Das ist die Grundlage für sinnvolles Conversation-Threading, Agent-Handoffs und langlaufenden Task-State.

Speichern Sie diese Response-IDs in Ihrer Datenbank neben dem User-Turn. Speichern Sie nicht nur den Text – speichern Sie die ID. Wenn 5.5 mit möglicherweise erweitertem State-Management erscheint, können die Teams, die Response-IDs aufbewahrt haben, reibungslos migrieren. Die Teams, die sie verworfen haben, werden ihre Conversation-Memory-Layer neu aufbauen müssen.

4. Nutzen Sie wirklich Caching — das ist ein 90%-Rabatt, der auf dem Tisch liegt

Gecachter Input zu $0.25/M statt $2.50/M Standard-Input ist keine kleine Optimierung. Es ist ein 90%-Rabatt, den OpenAI automatisch anwendet, wenn Ihre aufeinanderfolgenden Requests ein gemeinsames Prefix haben. Systemprompts. Referenzdokumente. Few-Shot-Beispiele. Ihr Tool-Manifest.

Strukturieren Sie Ihre Prompts so, dass der stabile Inhalt zuerst kommt und die variablen User-Inhalte zuletzt. Stellen Sie dann sicher, dass Ihre Requests das gleiche Endpoint in kurzer Zeit erreichen, damit der Cache warm bleibt. In Workloads, bei denen ich von null Cache-Hits auf eine 60%-Cache-Hitrate gewechselt bin, haben sich meine Input-Kosten insgesamt etwa halbiert. Das ist ein echter Posten in meiner Gewinn- und Verlustrechnung.

5. Guardrails für autonome Tool-Nutzung

Native Computer-Nutzung auf 5.4 ist mächtig – und gefährlich im Verhältnis zu dem Maß an Autonomie, das Sie dem Agenten geben. Mein Playbook:

• Jede Session auf ein spezifisches Ziel mit expliziter Abbruchbedingung begrenzen
• Erlaubte Aktionen whitelisten statt gefährliche zu blacklisten
• Pro Session ein Action-Audit-Log führen, das nachträglich überprüfbar ist
• Maximale Turns und maximale Kosten pro Session deckeln – harte Limits, die der Agent nicht überschreiten kann
• Menschliche Bestätigung verlangen für zustandsverändernde Operationen auf externen Systemen

Wenn 5.5 mit noch stärkerer Autonomie erscheint, sind diese Guardrails nicht optional – sie sind der Unterschied zwischen einem Agenten, der hilft, und einem, der einen Slack-Thread erzeugt, den Sie nicht lesen wollen.

6. Explizite Privacy- und Retention-Einstellungen

Verlassen Sie sich nicht auf Defaults. Konfigurieren Sie explizit Data Retention, Training Opt-Out und – falls benötigt – Regional Processing Endpoints. Beachten Sie, dass Regional Processing für alle nach dem 5. März 2026 veröffentlichten Modelle einen Aufschlag von 10% auf Input und Output kostet, also für die gesamte GPT-5.4-Familie und jedes zukünftige 5.5. Wenn Sie es aus Compliance-Gründen brauchen, kalkulieren Sie es in Ihr Budget ein. Wenn nicht, zahlen Sie nicht dafür.

7. Kostenmodellierung, bevor Sie skalieren

Modellieren Sie Ihre Unit Economics auf Ihrem aktuellen Scale und bei 10x Ihres aktuellen Scale. Nutzen Sie die echten 5.4-Preise mit dem >272K-Token-Multiplikator für Workloads, die diesen überschreiten. Vergleichen Sie Standard vs. Batch vs. Flex für jeden Workload. Bauen Sie ein Dashboard, das den täglichen Token-Verbrauch pro Workload und Ihre Cache-Hitrate anzeigt.

Wenn 5.5 erscheint und die Preise bekanntgegeben werden, wollen Sie das Team sein, das innerhalb eines Nachmittags sagen kann: „Unsere Kosten pro Nutzer steigen von $X auf $Y, unsere Marge ändert sich um Z Prozent, und unsere Entscheidung ist A.“ Nicht das Team, das erst zwei Wochen ein Kostenmodell bauen muss, bevor es eine Entscheidung treffen kann.

Die Realität des Fine-Tunings

Ein weiteres Thema, das ständig aufkommt: „Werde ich 5.5 feinabstimmen können?“

Kurze Antwort: Wahrscheinlich nicht so, wie du es dir vorstellst.

Hier ist der aktuelle Stand des Fine-Tunings bei OpenAIs Spitzenmodellen. Überwachtes Fine-Tuning am eigentlichen Frontier — 5.4 — ist nicht verfügbar. Es gibt den Distillations-Ansatz, bei dem du das Frontier-Modell nutzt, um Trainingsdaten für ein kleineres Modell zu generieren, das du dann feinabstimmst. Das ist jedoch grundsätzlich etwas anderes, als das Frontier-Modell selbst zu fine-tunen. Reinforcement Fine-Tuning (RFT) ist verfügbar, aber es ist auf die O-Serie der Reasoning-Modelle beschränkt — aktuell nur o4-mini — und nicht auf die 5.x-Reihe.

Wenn man das weiterdenkt, ist die realistische Erwartung, dass 5.5 ohne überwachtes Fine-Tuning für das Flaggschiff-Modell starten wird. Wenn deine Produktarchitektur auf Fine-Tuning des Frontier-Modells setzt, arbeitest du gegen die Richtung, in die OpenAI steuert.

Die richtige Frage ist nicht „Wie tune ich das Frontier-Modell fein?“, sondern „Wie nutze ich das Frontier-Modell als Lehrer für ein kleineres, anpassbares Modell, oder wie ersetze ich Fine-Tuning durch besseres Prompting, Retrieval und Agenten-Design?“ Das sind die nachhaltigen Fähigkeiten.

Worauf ich als Nächstes wirklich achte

Einige Signale, die ich beobachte und die mir verraten, dass 5.5 kurz bevorsteht, noch bevor der Blogpost erscheint:

1. Änderungen auf der OpenAI-Statusseite — Neue Modell-IDs tauchen manchmal kurz auf, bevor sie offiziell angekündigt werden
2. Nicht angekündigte Codex- oder ChatGPT-UI-Experimente — Veränderungen in den Fähigkeiten nachgelagerter Produkte gehen API-Releases oft um 48 bis 72 Stunden voraus
3. Updates in den Entwicklerdokumentationen — Preisübersichten, Modellseiten und Seiten zu Rate Limits werden angepasst, ohne dass es eine Ankündigung gibt
4. Sam Altmans Aktivität auf X — Das „in wenigen Wochen“-Muster war historisch gesehen innerhalb von ±10 Tagen ziemlich treffsicher

Keines dieser Signale ist ein unfehlbares Gesetz. Aber sie sind bessere Indikatoren als YouTube-Thumbnails.

Häufig gestellte Fragen

Wann wird GPT-5.5 veröffentlicht?

GPT-5.5 wurde bis zum 15. April 2026 nicht offiziell angekündigt. Das Modell mit dem internen Codenamen „Spud“ hat das Pre-Training am 24. März 2026 abgeschlossen, und Polymarket gibt eine Wahrscheinlichkeit von etwa 78 % für eine Veröffentlichung bis zum 30. April 2026 und über 95 % bis zum 30. Juni 2026 an. OpenAI hat nicht bestätigt, ob Spud als GPT-5.5 oder GPT-6 erscheinen wird. Eine vollständige Übersicht zu den Release-Signalen finden Sie im Abschnitt „Bestätigt“ oben.

Ist GPT-5.5 dasselbe wie Spud?

Nicht unbedingt. „Spud“ ist der interne Codename für das nächste Frontier-Modell von OpenAI, das sich derzeit in der Sicherheitsbewertung befindet. Ob es als GPT-5.5 oder GPT-6 veröffentlicht wird, hängt davon ab, wie groß der Leistungssprung gegenüber GPT-5.4 ausfällt, und wurde öffentlich noch nicht entschieden. Bis OpenAI das finale Branding bekannt gibt, sollten Sie beide als verwandt, aber unterschiedlich betrachten.

Sollte ich auf GPT-5.5 warten, bevor ich auf GPT-5.4 umsteige?

Nein. GPT-5.4 hat einen Sprung von 12 Punkten im GDPval erzielt (von 70,9 auf 83 %) und die menschliche Experten-Benchmark auf OSWorld überschritten. Der Mehrwert, den Sie durch Warten verpassen, ist real, und die Migrationsarbeit, die Sie für 5.4 leisten, ist identisch mit der für 5.5 — setzen Sie Modell-IDs hinter Konfigurations-Flags, bauen Sie Evals, nutzen Sie die Responses API. Machen Sie es jetzt.

Wie sind die API-Preise für GPT-5.4?

GPT-5.4 kostet $2,50 pro 1 Mio. Input-Tokens, $15,00 pro 1 Mio. Output-Tokens und $0,25 pro 1 Mio. gecachte Input-Tokens. Für Prompts mit mehr als 272 K Input-Tokens verdoppeln sich die Input-Kosten und die Output-Kosten steigen auf das 1,5-fache für die gesamte Session. Batch- und Flex-Tarife bieten erhebliche Rabatte für nicht-echtzeitkritische Workloads. Die vollständige Preisübersicht finden Sie im Abschnitt „Preise“ oben.

Kann ich GPT-5.4 oder GPT-5.5 feinabstimmen?

Überwachtes Fine-Tuning ist bei den GPT-5.x-Flaggschiffmodellen nicht verfügbar. Reinforcement Fine-Tuning (RFT) ist auf die O-Series-Reasoning-Modelle beschränkt, derzeit nur o4-mini. Der realistische Ansatz ist Distillation — das Frontier-Modell generiert Trainingsdaten für ein kleineres, anpassbares Modell — nicht das Fine-Tuning des Frontier-Modells selbst.

Die Maßnahme dieser Woche

Erinnerst du dich an meinen Freund, der mich am Sonntag um 23:47 Uhr fragte, ob er seine 5.4-Migration für 5.5 verschieben sollte?

Hier ist, was ich ihm gesagt habe. Und es ist genau das, was ich auch dir rate.

Warte nicht. Setze die 5.4-Migration diese Woche um. Baue es richtig auf — Modell-IDs hinter Konfigurations-Flags, Responses-API von Anfang an, Evals auf deiner echten Workload, Caching strukturiert in deinen Prompts, Service-Tiers passend zu den Workload-Typen, Guardrails für autonome Tools, explizite Datenschutzeinstellungen, echtes Kostenmodell.

Wenn du das tust, wird die Migration auf das nächste Frontier-Modell von OpenAI — egal ob es 5.5, 6 oder ganz anders heißt — nur noch ein Pull Request sein, der eine Umgebungsvariable umlegt und deine Eval-Suite neu startet. Ein Nachmittag Arbeit, kein Sprint.

Die Teams, die beim nächsten Modellwechsel gewinnen, sind diejenigen, die die heutige Arbeit als Infrastruktur für das Modell von morgen begreifen — nicht als Festlegung auf das heutige. Das Modell, das du nutzt, ist temporär. Die Architektur drumherum ist das, was sich verzinst.

Setze jetzt die langweilige Infrastruktur um. Lass den großen Launch nur eine Konfigurationsänderung sein.

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 Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io