Codex-gebruik en limieten: lees eerst wat er op is

Loopt Codex tegen een limiet aan, controleer dan eerst welke grens je account aangeeft. Gaat het om inbegrepen gebruik, een credittegoed of een limiet van je werkruimte? Zonder dat onderscheid kun je de verkeerde oplossing kiezen.

Ik zou de melding vastleggen, de actuele status bekijken en pas daarna de volgende taak plannen. Deze gids gebruikt de officiële documentatie zoals gecontroleerd op 27 oktober 2026. Je eigen account is de plek om de huidige resterende ruimte en resetmomenten te bekijken.

Volgens de prijzendocumentatie kun je tijdens een actieve CLI-sessie /status gebruiken. Het gebruiksdashboard toont de actuele accountlimieten. Neem de daar getoonde grens en het resetmoment over; een getal uit een oude handleiding kan voor jouw account onjuist zijn.

Schrijf bij een onverwachte melding kort op welke taak liep, welke interface je gebruikte en welke account of werkruimte actief was. Bewaar geen geheimen in die notitie. Met alleen 'Codex doet het niet' kan een beheerder moeilijk bepalen of het om toegang, gebruik of een technische fout gaat.

Een lege lijst of een ontbrekend percentage is geen bewijs dat je onbeperkt kunt werken. Zoek uit wat je account werkelijk toont en vraag zo nodig de beheerder om uitleg over de betreffende grens.

Een vraag van één zin kan een omvangrijke opdracht zijn. 'Controleer alle facturen en herstel de fouten' vraagt iets heel anders dan 'leg uit waar deze ene afronding wordt berekend'. Kijk daarom naar het werk dat de opdracht oproept, niet alleen naar het aantal woorden in je prompt.

Als zelfbedacht voorbeeld neem ik een inschrijfapp. Je wilt weten waarom een deelnemer twee bevestigingen ziet. Een gerichte opdracht wijst op het aanmeldpad, vraagt om de relevante bestanden en eindigt met een vermoedelijke oorzaak. Een brede opdracht die tegelijk de hele app wil opschonen maakt het moeilijker te beoordelen wat noodzakelijk is.

Dit is een afweging in taakontwerp. Het is geen garantie op een bepaalde besparing of extra aantal berichten. Je wilt vooral dat iedere uitgevoerde stap bijdraagt aan de vraag die je werkelijk probeert te beantwoorden.

De modeldocumentatie beschrijft reasoning effort als de hoeveelheid denkwerk die het model aan de vraag besteedt. Hogere effort kan helpen bij complexe analyse, maar gebruikt meer tokens. In de CLI kun je via /model de beschikbare model- en effortkeuzes bekijken.

Begin bij de standaardinstelling en beoordeel of de taak meer analyse vraagt. Een eenvoudige tekstwijziging hoeft niet dezelfde keuze te krijgen als onderzoek naar een fout met meerdere mogelijke oorzaken. Verlaag de zorgvuldigheid van een controle niet alleen omdat een limiet nadert.

Daarnaast bestaan snelheidsmodi. De officiële snelheidspagina vermeldt dat snellere modi bij ondersteunde modellen meer gebruik vergen. Een snellere reactie is dus geen vanzelfsprekende oplossing voor een krap gebruiksbudget. Controleer de voorwaarden van de gekozen modus.

Formuleer een duidelijk resultaat en een stopmoment. Voor de inschrijfapp kan dat zijn: 'zoek de twee plekken die de bevestiging veroorzaken, toon de relevante paden en stel één regressietest voor; verander nog niets'. Daarna beslis je of een reparatie volgt.

Geef relevante context mee, zoals de foutmelding en het betrokken scherm. Vermijd een dump van allerlei bestanden zonder uitleg waarom ze nodig zijn. Vraag de agent juist om gericht te onderzoeken wat ontbreekt. Een bruikbare opdracht maakt onderscheid tussen noodzakelijk bewijs en interessante zijpaden.

Deel een samenhangend probleem niet kunstmatig op in tientallen losse vragen. Dan moet je telkens reconstrueren wat al bekend is. Mijn voorkeur is een afgeronde onderzoeksvraag met een korte, controleerbare uitkomst. De gids over prompt engineering helpt bij het formuleren daarvan.

Lees de opties die het account op dat moment aanbiedt. Als wachten nodig is, bewaar dan eerst de bereikte stand: welke bestanden zijn veranderd, welke controles zijn uitgevoerd en wat moet nog gebeuren? Volg daarbij de versiebeheerafspraken van het project. Dat voorkomt dat de volgende sessie begint met raden.

Kunnen er extra kosten ontstaan, laat dan de bevoegde budgethouder beslissen. Bij zakelijke werkruimtes zijn gebruikersgrenzen en bestedingsgrenzen verschillende instellingen; de documentatie over gebruik en kosten licht dat onderscheid toe.

Accounts wisselen, inloggegevens kopiëren of beveiliging uitschakelen zijn geen werkwijze voor limietbeheer. Een nieuwe taak moet dezelfde projectafspraken en toegangsgrenzen respecteren. Gebruik een andere toegestane route alleen na een bewuste keuze over toegang en facturering.

Houd voor een paar representatieve taken bij wat je vroeg, welke omvang het werk had en of het resultaat bruikbaar was. Een taak die weinig gebruikt maar een verkeerde conclusie oplevert, is geen goede referentie. Noteer daarom ook of de relevante test of controle echt is uitgevoerd.

Vergelijk soortgelijke taken en benoem verschillen in model, effort en omgeving. Trek geen algemene conclusie uit één ongewone sessie. Je zoekt een aanpak die past bij jouw project en kwaliteitsgrens.

De basis van het product staat in de uitleg over Codex. Wil je leren hoe je werk afbakent en de uitkomst beoordeelt, bekijk dan de Vibe Coding Training. Een leesbare status en een heldere volgende taak helpen meer dan een onbewezen limiettruc.