Update — Sommer 2026: Für mich funktionierte das nicht mehr
Bis zum Sommer 2026 funktionierte dieser Workflow für mich nicht mehr zuverlässig. In meinem Konto verschwand die Anzeige für das 5-Stunden-Nutzungsfenster, während das Wochenlimit sichtbar blieb. Damit fiel praktisch das kürzere Reset-Fenster weg, an dem ich diesen Ablauf zuvor ausgerichtet hatte.
Wichtiger war das Verhalten langer Aufgaben. Wenn eine umfangreiche Codex-Aufgabe mein Wochenlimit erreichte, habe ich erlebt, dass die Arbeit stoppte, statt noch bis zum Abschluss weiterzulaufen. Damit verlor meine alte Regel „bei den letzten 3–5 % die schwerste Aufgabe starten“ viel von ihrem Nutzen: Ich konnte nicht mehr darauf bauen, dass eine bereits laufende Aufgabe das Ende des Wochenlimits übersteht.
Dabei muss ich Beobachtung und dokumentierte Produktregel trennen. Ich kann nur bestätigen, was ich in meinem Konto und Workflow gesehen habe; ich kann nicht belegen, dass OpenAI das 5-Stunden-Fenster für alle Nutzer dauerhaft entfernt hat. Die aktuelle Codex-Dokumentation von OpenAI erwähnt weiterhin sowohl 5-Stunden- als auch Wochenfenster und sagt, dass ein aktiver Turn nach Erreichen eines Limits unter Fair-Use-Bedingungen weiterlaufen kann. Deshalb beschreibe ich die Änderung im Sommer 2026 als reales Verhalten in meinem Fall, nicht als universelle Regel für jedes Konto.
Der restliche Artikel bleibt als Beschreibung des Workflows erhalten, der vor dieser Änderung bei mir funktioniert hat. Das Update oben hat Vorrang vor den Präsens-Empfehlungen im ursprünglichen Text.
Wenn der Codex-Nutzungszähler meines ChatGPT-Plus-Plans auf ungefähr 3–5 % fällt, nutze ich den Rest nicht mehr für kleine Prompts. Ich mache das Gegenteil: Ich starte die größte Engineering-Aufgabe, die ich bereits vorbereitet habe.
Bei mir sind das typischerweise eine vollständige TypeScript-Migration, ein ESLint-Cleanup über das gesamte Repository, ein tiefes Bug-Review einer Codebase oder ein großes strukturelles Refactoring. Häufig halte ich mehrere Projekte vorbereitet, damit die letzte Nutzungsreserve in die schwerste Aufgabe fließen kann, die tatsächlich startklar ist.
Der Grund ist eine wiederholte Beobachtung. Mehr als einmal habe ich nahe am sichtbaren Limit umfangreiche Arbeit gestartet und anschließend gesehen, dass Codex weiterarbeitete, obwohl das Limit bereits erschöpft wirkte. Manchmal lief die Aufgabe weit genug weiter, um fertig zu werden. Das ist oft genug passiert, um meine Planung zu verändern — aber nicht genug, um daraus eine garantierte Produkteigenschaft zu machen.
Die Beobachtung, die meinen Workflow verändert hat
Nahe an einem Nutzungslimit ist der natürliche Reflex, konservativ zu werden: lieber kleine Anfragen stellen, weil eine große Aufgabe unterbrochen werden könnte. Ich behandle die letzten 3–5 % inzwischen anders. Für mich sind sie ein Startfenster.
Die relevante Frage lautet nicht mehr: „Wie viele kleine Prompts bekomme ich noch unter?“ Sondern: „Welche wertvollste vorbereitete Aufgabe kann ich noch starten, solange inkludierte Nutzung verfügbar ist?“
Das funktioniert nur, weil Projekt und Aufgabe schon vorbereitet sind. Ich verwende die letzten Prozent nicht dazu herauszufinden, was überhaupt getan werden soll. Ich verwende sie, um mit der Ausführung zu beginnen.
Eine wichtige Klarstellung zu Name und Limits
Ich habe dafür ursprünglich den Ausdruck „Codex Plus“ verwendet. Das ist jedoch nur Kurzsprache, kein offizieller Produktname. OpenAI beschreibt Codex als Bestandteil von ChatGPT Plus. Die Korrektur ist wichtig, damit es nicht so klingt, als wäre Codex Plus ein eigener Tarif oder ein separates Produkt.
Die aktuelle Codex-Dokumentation von OpenAI weist außerdem darauf hin, dass der Verbrauch von Größe und Komplexität der Arbeit, vom Modell und davon abhängt, wo die Aufgabe ausgeführt wird. Dokumentiert sind Nutzungsfenster einschließlich eines 5-Stunden- und eines Wochenfensters. Mit „3–5 %“ meine ich daher den verbleibenden Prozentsatz in der Nutzungsanzeige — nicht 3–5 % reale Zeit, Tokens oder eine garantierte Menge Engineering-Arbeit.
Berechtigte Plus-Nutzer können Codex nach Erreichen des inkludierten Limits inzwischen auch mit Credits weiterverwenden. Das widerspricht meinem Workflow nicht. Es macht nur klarer, dass ich die Verteilung meiner inkludierten Nutzung beschreibe und keinen Weg, ein Limit zu umgehen.
Was ich in den letzten 3–5 % starte
Für diesen Moment reserviere ich vor allem breite Engineering-Aufgaben:
- vollständige TypeScript-Migrationen
- repository-weite ESLint-Bereinigung
- tiefe Bug-Reviews großer Codebasen
- große strukturelle Refactorings
Solche Arbeiten starte ich lieber als zusammenhängende, substanzielle Aufgabe, statt die verbleibende Nutzung in eine Folge kleiner Anfragen zu zerlegen. Bei ihnen sind ein vorbereitetes Repository und ein klares Ziel wichtiger als besonders raffinierte Prompt-Formulierungen.
Mehrere vorbereitete Projekte helfen aus demselben Grund. Wenn ein Repository noch Entscheidungen oder Setup braucht, verschwende ich das letzte Fenster nicht mit der Vorbereitung, sondern starte eine Aufgabe in einem anderen Projekt, das bereits bereit ist.
Vorbereitung ist die eigentliche Begrenzung
Der Trick lautet nicht: „Bis 3 % warten und dann einen riesigen Prompt einfügen.“ Ist eine Aufgabe unklar, kann ein knappes Budget in Exploration, Rückfragen oder Arbeit in der falschen Richtung verschwinden. Mein Muster ist nur dann sinnvoll, wenn das Projekt ausführungsbereit und die Aufgabe sauber abgegrenzt ist.
Für einen ähnlichen Workflow hilft ein einfacher Preflight: Was soll sich ändern? Was darf sich nicht ändern? Welche Constraints gelten? Wie wird das Ergebnis validiert? Welches Ergebnis soll der Agent liefern? Das sind allgemeine Engineering-Sicherungen und kein Beleg dafür, dass ein bestimmtes Prompt-Format zusätzliche Nutzung freischaltet.
Eine solche Vorbereitung macht große Aufgaben außerdem leichter fortsetzbar, wenn das Limit sie tatsächlich unterbricht. Eine teilweise abgeschlossene Migration oder ein Review lässt sich deutlich besser weiterführen, wenn Scope und Validierungskriterien von Anfang an klar waren.
Was ich bestätigen kann — und was nicht
Aus meiner eigenen Nutzung kann ich nur etwas Enges bestätigen: Mehrfach hat eine bereits gestartete Aufgabe weiter Fortschritt gemacht, nachdem das sichtbare Nutzungslimit erschöpft aussah, und manchmal wurde sie abgeschlossen.
Den Mechanismus kann ich nicht bestätigen. Ich kann nicht behaupten, OpenAI gebe jeder laufenden Aufgabe eine versteckte Gnadenfrist, die letzten 3–5 % reichten garantiert für beliebig große Aufgaben, das Verhalten sei stabil oder es handle sich um einen Weg am Limit vorbei. Die OpenAI-Dokumentation verspricht nichts davon.
Diese Trennung ist entscheidend. Ich plane mit einem Verhalten, das ich wiederholt gesehen habe, aber ich verlasse mich nicht darauf. Wenn eine Aufgabe am Limit stoppt, ist das kein Hinweis auf einen Defekt. Die Strategie hat ihren Zweck trotzdem erfüllt, wenn die verbleibende inkludierte Nutzung in eine wichtigere Aufgabe geflossen ist als in ein paar Mini-Prompts.
Eine abgeschlossene Aufgabe ist noch nicht verifiziert
Mit wachsender Aufgabengröße wird eine zweite Unterscheidung wichtiger: Fertig ist nicht gleich korrekt. Eine TypeScript-Migration, die baut, beweist kein korrektes Runtime-Verhalten. Ein sauberer ESLint-Lauf beweist keine korrekte Business-Logik. Ein Bug-Review, das ein verdächtiges Muster meldet, hat noch nicht zwingend einen echten Bug gefunden. Selbst ein Refactoring mit grünen Tests ist nur so belastbar wie die Tests und Checks, die es abdecken.
Dieser Workflow ändert den Zeitpunkt, zu dem ich Arbeit starte. Er senkt nicht den Prüfstandard. Große agentische Änderungen brauchen weiterhin die zum Risiko passenden Kontrollen: Diff-Review, Typecheck, Tests, Build, Runtime-Checks oder projektspezifische Verifikation.
Wann dieses Muster nicht gut passt
Nicht jede große Aufgabe eignet sich als End-of-Limit-Task. Schwächer ist der Ansatz, wenn die Arbeit noch unklar ist, laufend Produktentscheidungen benötigt, destruktive oder produktionskritische Operationen enthält oder das Repository bei einem Abbruch in einem riskanten Zwischenzustand bleibt.
Dann ist eine kleinere, klar begrenzte Aufgabe oder ein frisches Nutzungsfenster meist die bessere Engineering-Entscheidung. Ziel ist nicht der dramatischste letzte Prompt, sondern knappe inkludierte Nutzung in Arbeit zu investieren, die sicher nützlichen Fortschritt erzeugen kann.
Meine Regel heute
Wenn meine inkludierte Codex-Nutzung in ChatGPT Plus auf ungefähr 3–5 % fällt, optimiere ich nicht mehr die Zahl der verbleibenden Prompts. Ich schaue auf die vorbereiteten Projekte und starte die schwerste klar umrissene Engineering-Aufgabe, die es wert ist.
Arbeitet Codex nach dem sichtbaren Nullpunkt weiter, behandle ich das als nützliche Beobachtung, nicht als Anspruch. Stoppt es, überrascht mich das nicht. Ich habe keinen Weg um das Limit gefunden. Ich habe einen besseren Weg gefunden zu entscheiden, was ich starten will, bevor ich es erreiche.