GPT-5.4 endet in Codex: Was Nutzer jetzt umstellen müssen

Was seit dem 31. August offiziell gilt

OpenAI nennt den 31. August 2026 als Stichtag: GPT-5.4 und GPT-5.4 mini stehen in Codex nicht mehr zur Verfügung, wenn die Anmeldung über ein ChatGPT-Konto erfolgt. Das Help Center und die aktuelle Codex-Modellübersicht nennen denselben Termin und dieselbe Abgrenzung. Es handelt sich damit um eine heute wirksam werdende Änderung des Modellzugangs, nicht nur um eine später veröffentlichte Meldung über ein älteres Ereignis.

Der Hinweis betrifft nicht nur die manuelle Modellwahl. OpenAI fordert dazu auf, Workspace-Defaults, gespeicherte Modelleinstellungen, verwaltete Konfigurationen und Automationen anzupassen. Die Codex-Dokumentation nennt zusätzlich Custom Agents und Scheduled Tasks. Wo eine alte Modellkennung fest eingestellt ist, kann ein neuer Lauf deshalb scheitern oder eine manuelle Auswahl verlangen.

Stichtag ist der 31. August 2026. Entscheidend ist der Anmeldeweg: Die Einschränkung gilt für Codex mit ChatGPT-Anmeldung.

Terra ersetzt GPT-5.4, Luna ersetzt GPT-5.4 mini

Für gespeicherte Codex-Konfigurationen gibt OpenAI zwei konkrete Zuordnungen vor: GPT-5.4 soll durch GPT-5.6 Terra ersetzt werden, GPT-5.4 mini durch GPT-5.6 Luna. Terra positioniert OpenAI als ausgewogene Modellstufe für alltägliche Arbeit, Luna als schnelle und besonders effiziente Stufe. Beide gehören zur im Juli allgemein veröffentlichten GPT-5.6-Familie.

Diese Zuordnung bedeutet nicht, dass die Modelle in jedem Workflow identische Ergebnisse liefern. Planung, Werkzeugaufrufe, Laufzeit, Kontextverbrauch und Änderungsumfang können sich verschieben. Auch die Namen sind nicht austauschbar: Eine Konfiguration mit gpt-5.4 muss tatsächlich auf eine verfügbare Kennung wie gpt-5.6-terra geändert werden; ein unveränderter alter Wert wird durch die Ankündigung nicht automatisch gültig.

• gpt-5.4 wird in Codex mit ChatGPT-Anmeldung durch gpt-5.6-terra ersetzt
• gpt-5.4-mini wird durch gpt-5.6-luna ersetzt
• Gespeicherte Defaults und Automationen müssen ausdrücklich kontrolliert werden
• Die Ersatzempfehlung ist keine Zusage identischer Modellantworten

API und eigener API-Key bleiben laut OpenAI unberührt

OpenAI grenzt den Umfang ausdrücklich ein: Die Änderung betrifft weder die OpenAI API noch Codex, wenn es mit einem eigenen API-Key authentifiziert wird. Ein Modell kann daher aus dem über einen ChatGPT-Plan bereitgestellten Codex-Angebot verschwinden und zugleich über die API weiter verfügbar sein. Produktzugang und API-Verfügbarkeit sind zwei getrennte Ebenen.

Teams sollten deshalb nicht pauschal alle Vorkommen von GPT-5.4 ersetzen. Zuerst muss feststehen, ob ein Lauf ChatGPT-Credits beziehungsweise den planbasierten Codex-Zugang oder einen eigenen API-Key verwendet. Bei API-Integrationen gelten die aktuelle Modellseite, Preise und Deprecation-Hinweise der API. Bei Codex mit ChatGPT-Anmeldung ist dagegen die neue Codex-Modellliste maßgeblich.

Nicht betroffen sind laut OpenAI die API und Codex mit eigenem API-Key. Das ist keine allgemeine Abschaltung von GPT-5.4 auf allen OpenAI-Zugangswegen.

Diese Einstellungen sollten jetzt durchsucht werden

Die sichtbare Modellauswahl ist nur ein Teil der Umstellung. Lokale Codex-Clients verwenden für Standardwerte eine gemeinsame config.toml. Hinzu kommen Workspace-Vorgaben, verwaltete Anforderungen, Agentenprofile, gespeicherte Chats und zeitgesteuerte Aufgaben. Auch Befehle und Skripte können eine Modellkennung über einen Parameter festlegen.

Eine saubere Bestandsaufnahme erfasst nicht nur Dateien, sondern auch Einstellungen in der Codex-Oberfläche und zentral verwaltete Vorgaben. Besonders wichtig sind unbeaufsichtigte Abläufe: Ein interaktiver Nutzer bemerkt eine fehlende Modellauswahl sofort, während eine nächtliche Automation erst Stunden später als fehlgeschlagen auffällt. Änderungen sollten deshalb mit Verantwortlichem, Datum und Rückfalloption dokumentiert werden.

• Lokale config.toml und aktive Profile
• Workspace-Defaults und verwaltete Konfigurationen
• Custom Agents und gespeicherte Modellauswahl
• Scheduled Tasks und andere unbeaufsichtigte Automationen
• Skripte oder Befehle mit fest eingetragener Modellkennung

Der Wechsel braucht einen Vergleich mit echten Aufgaben

OpenAIs API-Migrationsleitfaden empfiehlt beim Wechsel von GPT-5.4 auf GPT-5.6, zunächst die bisherige Reasoning-Stufe beizubehalten und anschließend dieselbe sowie eine niedrigere Stufe mit repräsentativen Aufgaben zu testen. Dieser Grundsatz ist auch für Codex sinnvoll: Erst ein Vergleich am eigenen Repository zeigt, ob Qualität, Laufzeit und Umfang der Änderungen zum Einsatz passen.

Ein belastbarer Testsatz enthält kleine Fehlerkorrekturen, Refactorings, Testgenerierung, Code-Review und mindestens einen längeren Agentenlauf mit mehreren Werkzeugen. Beide Modelle beziehungsweise der bisherige Referenzlauf und das Ersatzmodell sollten denselben Repository-Stand und dieselben Anweisungen erhalten. Gemessen werden Testergebnis, unerwünschte Änderungen, Zahl menschlicher Eingriffe, Laufzeit und Verbrauch.

• Bisherige Modellwahl und Reasoning-Stufe als Referenz dokumentieren
• Terra oder Luna auf identischem Code und mit identischen Aufgaben testen
• Tool-Aufrufe, geänderte Dateien und Testresultate vergleichen
• Automationen zunächst kontrolliert und beobachtbar ausführen
• Erst nach bestandenem Vergleich den neuen Default ausrollen

Was OpenAI in der Mitteilung nicht festlegt

Die offiziellen Hinweise erklären nicht für jede Codex-Oberfläche, wie ein bereits gespeicherter GPT-5.4-Wert nach dem Stichtag dargestellt wird. Ebenso wenig wird zugesagt, dass laufende oder pausierte Aufgaben automatisch auf Terra oder Luna wechseln. Ob ein Client einen Fehler zeigt, auf einen empfohlenen Standard zurückfällt oder eine neue Auswahl verlangt, kann von Version und Oberfläche abhängen.

Auch eine vollständige Verhaltensgleichheit der Ersatzmodelle wird nicht behauptet. OpenAI beschreibt Terra und Luna als aktuelle GPT-5.6-Stufen und empfiehlt ihre Modellkennungen für die Migration. Aussagen zu besseren Ergebnissen in einem konkreten Projekt bleiben aber Herstellerangaben oder müssen durch eigene Tests belegt werden. Ein stiller Modellwechsel ohne Abnahme wäre für produktionsnahe Agenten deshalb riskant.

Ein kompakter Umstellungsplan für Teams

Zuerst werden alle planbasierten Codex-Zugänge und alle Vorkommen der alten Modellkennungen inventarisiert. Danach wird pro Workflow entschieden, ob Terra oder Luna die passendere Ausgangsbasis ist. Kritische Aufgaben erhalten einen Vergleichslauf und eine fachliche Freigabe. Erst dann werden lokale Defaults, Workspace-Einstellungen, Agenten und Zeitpläne aktualisiert.

Nach der Umstellung sollte mindestens der erste unbeaufsichtigte Lauf überwacht werden. Protokolle müssen zeigen, welches Modell tatsächlich verwendet wurde und ob Tests, Freigaben und Deployment-Schritte wie erwartet abgeschlossen wurden. Falls eine Aufgabe zwingend auf GPT-5.4 angewiesen ist, darf nicht automatisch angenommen werden, dass ein ChatGPT-Plan den Zugang weiterliefert; dann sind API-Verfügbarkeit, eigener API-Key und die dazugehörigen Bedingungen separat zu prüfen.

Die MindrAils-Einordnung

Das Ende von GPT-5.4 im planbasierten Codex-Zugang ist keine neue Modellveröffentlichung, aber eine relevante Plattformänderung. Sie zeigt, dass Modellverfügbarkeit vom Produkt, Tarif und Authentifizierungsweg abhängt. Wer nur einen Modellnamen dokumentiert, kennt seine tatsächliche Abhängigkeit noch nicht.

Die technische Umstellung ist überschaubar, sofern Modellkennungen auffindbar und Automationen beobachtbar sind. Das größere Risiko liegt in unbemerkten Verhaltensänderungen oder fest verdrahteten Aufgaben. Die richtige Reaktion ist daher ein gezieltes Update auf Terra oder Luna mit repräsentativen Tests und klarer Trennung zwischen ChatGPT-Plan und API-Zugang.