Update — zomer 2026: voor mij werkte dit niet meer
Tegen de zomer van 2026 werkte deze workflow voor mij niet meer betrouwbaar. De teller voor het 5-uursvenster verdween uit mijn account, terwijl de weeklimiet zichtbaar bleef. Daarmee verdween in de praktijk het kortere resetvenster waarop ik deze aanpak had afgestemd.
Belangrijker was wat er met langlopende taken gebeurde. Wanneer een zware Codex-taak het einde van mijn weeklimiet bereikte, zag ik het werk stoppen in plaats van doorlopen tot voltooiing. Daardoor verloor mijn oude regel — “start de zwaarste taak in de laatste 3–5%” — veel van zijn nut: ik kon er niet meer op rekenen dat een al lopende taak het einde van de weeklimiet zou overleven.
Ik wil mijn observatie wel strikt scheiden van een officiële productregel. Ik kan bevestigen wat ik in mijn account en workflow zag, maar niet bewijzen dat OpenAI het 5-uursvenster permanent voor alle gebruikers heeft verwijderd. De huidige Codex-documentatie noemt nog steeds zowel 5-uurs- als weekvensters en zegt dat een actieve turn na het bereiken van een limiet soms kan doorgaan, onder fair-usebeperkingen. Daarom beschrijf ik de verandering in de zomer van 2026 als echt gedrag dat ik zelf heb ervaren, niet als een universele regel voor ieder account.
De rest van het artikel blijft staan als beschrijving van de workflow die vóór die verandering voor mij werkte. De update hierboven gaat voor op de aanbevelingen in de tegenwoordige tijd in de oorspronkelijke tekst.
Wanneer de Codex-gebruiksteller van mijn ChatGPT Plus-abonnement tot ongeveer 3–5% daalt, besteed ik het restant niet meer aan kleine prompts. Ik doe het tegenovergestelde: ik start de grootste engineeringtaak die ik al heb voorbereid.
In mijn geval gaat het meestal om een volledige TypeScript-migratie, repositorybrede ESLint-opruiming, een diep bugreview van een codebase of een grote structurele refactor. Ik heb vaak meerdere projecten vooraf klaarstaan, zodat het laatste stuk gebruik naar de zwaarste taak kan gaan die echt uitvoerbaar is.
De reden is een terugkerende observatie. Meer dan eens heb ik vlak voor het zichtbare limiet substantieel werk gestart en daarna gezien dat Codex doorging terwijl dat limiet al opgebruikt leek. Soms ging de taak ver genoeg door om af te ronden. Dat gebeurde vaak genoeg om mijn planning te veranderen, maar niet om er een productgarantie van te maken.
De observatie die mijn workflow veranderde
Vlak bij een gebruikslimiet is de natuurlijke reactie om conservatief te worden: gebruik het laatste beetje voor kleine verzoeken, want een grote taak kan worden onderbroken. Ik behandel die laatste 3–5% nu anders. Voor mij is het een startvenster.
De nuttige vraag is niet langer: “Hoeveel kleine prompts passen er nog in?” maar: “Welke waardevolle, voorbereide taak kan ik nog starten zolang inbegrepen gebruik beschikbaar is?”
Dat werkt alleen omdat het project al klaarstaat en de taak duidelijk is afgebakend. Ik gebruik de laatste procenten niet om uit te zoeken wat er moet gebeuren. Ik gebruik ze om de uitvoering te starten.
Een belangrijke nuance over naam en limieten
Ik noemde dit aanvankelijk “Codex Plus”, maar dat is shorthand en niet de officiële productnaam. OpenAI beschrijft Codex als inbegrepen bij ChatGPT Plus. Die correctie voorkomt dat Codex Plus klinkt als een apart abonnement of product.
De huidige OpenAI-documentatie over Codex-gebruik zegt ook dat verbruik afhangt van de omvang en complexiteit van het werk, het model en waar de taak draait. Er zijn gebruiksvensters gedocumenteerd, waaronder een venster van 5 uur en een wekelijks venster. Met “3–5%” bedoel ik dus het resterende percentage dat de usage-interface toont, niet 3–5% van kloktijd, tokens of een gegarandeerde hoeveelheid engineeringwerk.
In aanmerking komende Plus-gebruikers kunnen Codex na het inbegrepen limiet ook met credits blijven gebruiken. Dat maakt deze workflow niet ongeldig; het maakt de afbakening juist duidelijker. Ik beschrijf hoe ik mijn inbegrepen gebruik verdeel, niet hoe ik een quota omzeil.
Wat ik in de laatste 3–5% start
De taken die ik voor dit moment bewaar zijn brede engineeringoperaties:
- volledige TypeScript-migraties
- repositorybrede ESLint-opruiming
- diepe bugreviews van grote codebases
- grote structurele refactors
Ik start liever één van deze taken als substantieel blok werk dan het restant te verdelen over een reeks kleine verzoeken met weinig waarde. Bij dit soort taken zijn een voorbereid repository en een helder doel belangrijker dan bijzonder slimme promptformulering.
Meerdere projecten klaar hebben helpt om dezelfde reden. Als één repository nog beslissingen of setup nodig heeft, verspil ik het laatste venster niet aan voorbereiding; ik kan starten in een ander project dat al klaarstaat.
Voorbereiding is de echte beperking
De truc is niet “wacht tot 3% en plak dan een enorme prompt”. Als de taak ambigu is, kan een beperkt budget verdwijnen in verkenning, verduidelijking of werk in de verkeerde richting. Mijn patroon is alleen nuttig als het project uitvoeringsklaar en de taak goed begrensd is.
Voor developers die iets vergelijkbaars proberen, is een praktische preflight om de scope expliciet te maken: wat moet veranderen, wat niet, welke constraints gelden, hoe het resultaat wordt gevalideerd en welke output je van de agent verwacht. Dat zijn algemene engineeringwaarborgen, geen bewijs dat een bepaald promptformaat meer gebruik vrijspeelt.
Zo’n voorbereiding maakt een grote taak ook makkelijker hervatbaar als het limiet haar werkelijk stopt. Een gedeeltelijke migratie of review is veel eenvoudiger voort te zetten wanneer scope en validatiecriteria vanaf het begin duidelijk waren.
Wat ik kan bevestigen — en wat niet
Wat ik uit mijn eigen gebruik kan bevestigen is smal: meerdere keren bleef een al gestarte taak voortgang maken nadat het zichtbare usage-limiet opgebruikt leek, en soms werd ze afgerond.
Het mechanisme kan ik niet bevestigen. Ik kan niet stellen dat OpenAI elke lopende taak een verborgen grace period geeft, dat de laatste 3–5% genoeg is voor willekeurig groot werk, dat dit gedrag stabiel is of dat het een manier is om het limiet te omzeilen. De documentatie van OpenAI belooft geen van die dingen.
Dat onderscheid is belangrijk. Ik plan rond gedrag dat ik herhaaldelijk heb gezien, maar ik vertrouw er niet op als garantie. Als een taak stopt bij het limiet, is dat geen teken dat er iets kapot is. De strategie heeft nog steeds gewerkt als ik het laatste inbegrepen gebruik aan belangrijker werk heb besteed dan een paar mini-prompts.
Een afgeronde taak is nog niet geverifieerd
Naarmate de taak groter wordt, wordt een tweede onderscheid belangrijker: afgerond is niet hetzelfde als correct. Een TypeScript-migratie die buildt bewijst geen correct runtimegedrag. Een schone ESLint-run bewijst geen correcte businesslogica. Een bugreview die een verdacht patroon markeert heeft niet per se een echte bug gevonden. Zelfs een refactor met groene tests is slechts zo sterk als de tests en checks die haar dekken.
Deze workflow verandert wanneer ik werk start. Hij verlaagt de validatiestandaard niet. Grote agentic changes hebben nog steeds controles nodig die bij het risico passen: diff review, typecheck, tests, build, runtime checks of projectspecifieke verificatie.
Wanneer dit patroon slecht past
Niet elke grote taak is een goede end-of-limit-taak. De aanpak is zwakker wanneer het werk nog onduidelijk is, regelmatig productbeslissingen vereist, destructieve of productiegevoelige handelingen bevat, of het repository in een risicovolle tussenstaat achterlaat als het halverwege stopt.
In die situaties is een kleinere, goed begrensde taak of een nieuw gebruiksvenster meestal een betere engineeringkeuze. Het doel is niet de laatste prompt zo dramatisch mogelijk te maken, maar schaars inbegrepen gebruik te investeren in werk dat veilig nuttige voortgang kan opleveren.
Mijn regel nu
Wanneer mijn inbegrepen Codex-gebruik in ChatGPT Plus tot ongeveer 3–5% daalt, optimaliseer ik niet meer voor het aantal resterende prompts. Ik kijk naar de projecten die ik vooraf heb klaargezet en start de zwaarste, duidelijk afgebakende engineeringtaak die de moeite waard is.
Als Codex doorgaat nadat de zichtbare teller nul bereikt, behandel ik dat als nuttig waargenomen gedrag, niet als een recht. Als het stopt, ben ik niet verrast. Ik heb geen manier gevonden om het limiet te omzeilen. Ik heb een betere manier gevonden om te beslissen wat ik moet starten vóór ik het bereik.