AI-uitgaven goedkeuren zonder elke run goed te keuren

Modelgebruik in CodeLynq betaal je met vooraf betaald tegoed. Het abonnement betaalt het platform; het tegoed betaalt wat de modellen kosten, en dat verschilt meer dan een factor tien tussen een dependency-update en het opzetten van een nieuwe service. Elke run wordt afgerekend als hij klaar is, omdat de kosten vooraf niet te weten zijn. Staat het tegoed op nul, dan worden nieuwe runs geweigerd en mogen runs die al bezig zijn afmaken.

We dachten dat dat een uitgavencontrole was. Dat is het niet. Hij gaat af als het geld op is. Een team dat een paar honderd euro opwaardeert, kan dat in een middag uitgeven, en het eerste signaal is het lege tegoed.

De twee voor de hand liggende antwoorden zijn allebei fout

Het eerste is elke run laten goedkeuren. Dat klinkt verantwoord en strandt binnen een week: als elke run iets vraagt, stopt degene die goedkeurt met lezen en klikt hij gewoon, en een goedkeuring die niemand leest, controleert niets. Het tweede is niets goedkeuren en naar de factuur kijken, en zo worden mensen bang voor hun eigen tools.

Wat iemand met een budget eigenlijk wil, is smaller: gewone runs gaan door, ongewone vragen eerst, en sommige dingen gebeuren nooit zonder dat iemand bewust van gedachten verandert.

Drie zones en een maandplafond

Een beheerder van de organisatie kan daarom onder Uitgavenlimieten drie bedragen instellen:

• Zonder goedkeuring tot. Onder deze schatting start een run zonder dat iemand iets hoeft te doen.
• Nooit meer dan, per run. Daarboven wordt de run geweigerd, met de suggestie om de taak op te splitsen of de limiet te verhogen.
• Per maand, voor alle projecten samen. Zodra wat deze maand in rekening is gebracht dat bedrag bereikt, worden nieuwe runs geweigerd tot het plafond omhoog gaat.

Tussen de eerste twee ligt de zone waar het om draait: de run wordt aangemaakt, geschat en tegengehouden. Hij staat niet in de wachtrij, dus geen worker kan hem oppakken, en hij is niet mislukt, want er ging niets mis. Beheerders van de organisatie krijgen een melding, en de runpagina toont de schatting, dat er nog niets is gestart en niets in rekening is gebracht, en twee knoppen.

Alle drie de limieten staan uit tot iemand ze instelt. Een plafond dat onverwacht opduikt, blokkeert werk dat niemand wilde blokkeren. Een organisatie die dit scherm nooit opent, werkt dus precies zoals voorheen.

Waar de schatting vandaan komt

De schatting is het 90e percentiel van wat vergelijkbare runs in hetzelfde project echt kostten: negen van de tien bleven eronder. Zodra er minstens drie runs van hetzelfde taaktype zijn, kijken we alleen naar die, want een chore kost zelden wat een feature kost. De omrekening is dezelfde als bij de afrekening achteraf, dus het bedrag dat een beheerder goedkeurt, heeft dezelfde basis als wat hij betaalt.

Het 90e percentiel is een bewuste keuze: voorzichtig genoeg om een echte uitschieter te vangen zonder gewoon werk tegen te houden. Het is een waarde uit echte runs, niet geïnterpoleerd, want een kleine steekproef aankleden met decimalen is schijnprecisie.

Zonder geschiedenis is er geen schatting, en dan mag de run door. Blokkeren op een bedrag dat we hebben verzonnen, zou elke eerste run op een nieuw project tegenhouden, en dat is het slechtste moment om iemand een muur voor te zetten.

Dezelfde geschiedenis voedt de prognose naast de knop om een run te starten, zodat je de gebruikelijke kosten van dit soort werk ziet voordat iemand erop drukt, tegengehouden of niet.

Details die ertoe bleken te doen

• Alleen beheerders van de organisatie keuren goed. Eigenaar van het project zijn is niet genoeg: elk lid kan een project aanmaken en er eigenaar van zijn, en zou dan zijn eigen tegengehouden run kunnen doorlaten. Dan is de drempel alleen nog decoratie.
• Bij goedkeuring worden de limieten opnieuw gecontroleerd. Een run die een nacht heeft gewacht, kan achter een maandplafond staan dat intussen is bereikt. Hem dan goedkeuren zou geld uitgeven waarvan de organisatie al heeft gezegd dat ze het niet wil uitgeven.
• Afwijzen is geen mislukking. Een afgewezen run wordt geannuleerd met een notitie wie hem afwees, en de taak blijft staan waar hij stond, zodat je hem kunt opsplitsen en opnieuw proberen.
• Runs zonder toezicht wachten niet. Een run die automatisch start vanuit een monitoringalert, wordt niet alleen door "weigeren" maar ook door "goedkeuring nodig" tegengehouden. Een run waarvan iemand de kosten zou moeten goedkeuren, is precies een run die niet om drie uur 's nachts moet starten.
• Self-hosted runs vallen erbuiten. Ze draaien op je eigen machines en gaan niet van het tegoed af, dus er valt niets goed te keuren.

Een valkuil in de kostenkolommen

Runs hadden al een kolom voor een kostenschatting. Daarin staat wat de modelprovider ons rekende, in dollars, berekend uit het aantal tokens. Het bedrag voor goedkeuring is wat de klant betaalt, in euro's, na omrekening. Als we de bestaande kolom hadden hergebruikt, zaten er ongemerkt twee valuta en het geld van twee partijen in één veld, en was elke vergelijking met een limiet stilletjes fout geweest. Het bedrag voor goedkeuring kreeg een eigen kolom, en we noemen elk kostenveld nu naar wiens geld het is en in welke valuta.

Wat het niet doet

• De schatting leest de taak niet. Twee features in hetzelfde project krijgen dezelfde schatting, wat er ook in hun specificatie staat.
• Een 90e percentiel is geen maximum. Eén op de tien gewone runs kost meer dan de schatting, en de limiet per run wordt getoetst aan de schatting, niet aan de uiteindelijke rekening.
• Het maandplafond is exact, omdat het telt wat in rekening is gebracht en niet wat is voorspeld, maar het kan alleen de volgende run stoppen. De run die over de grens ging, heeft al gedraaid.
• Alleen runs met gemeten kosten tellen mee in de schatting. Claude Code meldt die; runs op agents die geen kosten melden, horen niet bij de basis.

Een verstandige eerste instelling is een goedkeuringsbedrag per run iets boven wat je gebruikelijke run kost, af te lezen aan de prognose, en een maandplafond op het budget dat je niet graag zou moeten uitleggen. Meer over hoe runs worden geprijsd en gerouteerd, lees je bij kostenbeheersing en in Opus-tarieven voor een dependency-update.