Agent-runtimebudget: houd retry's binnen hetzelfde plafond

Een retry is niet gewoon dezelfde aanroep nog een keer, en gratis is hij al helemaal niet. In de meeste agentopstellingen verstuurt hij opnieuw alles wat de agent tot dan toe heeft gelezen, en misschien is hij er een van tientallen die op elkaar gestapeld zijn.

Een runtimebudget voor een agent is het maximum dat één taak mag verbruiken voordat de agent moet stoppen en het werk teruggeeft: een plafond op tokens, geld, doorlooptijd en toolaanroepen. Of het werkt, hangt af van één keuze: de reikwijdte. Het plafond moet de hele taak dekken, inclusief elke retry, fallback, subagent en herstart. Krijgt elke poging een vers budget, dan heb je een budget per poging en niet per taak, en kost een taak die vijf keer mislukt vijf budgetten.

Eerst twee begrippen. Een AI-agent is een programma op basis van een taalmodel dat in meerdere stappen naar een doel toewerkt en onderweg tools aanroept, zoals een zoekopdracht, een database of een concept-e-mail. Een token is de eenheid die een taalmodel leest en schrijft, grofweg een stukje van een woord; volgens Anthropic is één Claude-token ongeveer 3,5 Engelse tekens (Anthropic). Aanbieders rekenen per token af, met aparte prijzen voor input (wat jij verstuurt) en output (wat het model schrijft) (prijzen van Anthropic).

Wat hoort er in een runtimebudget?

Vier meters per taak, ingesteld vóór de eerste run:

Meter	Wat hij begrenst	Waarom het telt
Tokens	Input plus output over alle aanroepen	De grondstof van de rekening
Geld	Diezelfde tokens tegen jouw prijzen, plus betaalde tools	Het getal dat de financiële afdeling ziet
Tijd	Seconden van start tot overdracht	Een vastgelopen run is geen trage run
Toolaanroepen	Aanroepen per tool, vooral tools die versturen, betalen of schrijven	Sommige acties mogen nooit twee keer gebeuren

AI-agents effectief inzetten behandelt zulke grenzen als onderdeel van het inrichten van een agent. Dit stuk gaat over wat ze ongemerkt doorbreekt: retry’s.

Waarom vermenigvuldigen retry’s de kosten?

Drie mechanismen, alle drie gedocumenteerd.

1. Elke aanroep verstuurt het hele gesprek opnieuw. Anthropic schrijft over zijn Messages API dat die “is stateless, which means that you always send the full conversational history to the API” (Anthropic). De API onthoudt niets; je stuurt elke keer de volledige gespreksgeschiedenis mee. Bij een retry in stap 12 betaal je dus opnieuw voor alles uit stap 1 tot en met 11. Wordt de foutmelding aan het gesprek toegevoegd voor de volgende poging, dan is elke retry ook nog groter dan de vorige.

2. Retry-lagen vermenigvuldigen het aantal pogingen. Het Site Reliability Engineering-boek van Google waarschuwt voor retry’s op meerdere niveaus van één systeem: “a single request at the highest layer may produce a number of attempts as large as the product of the number of attempts at each layer to the lowest layer.” Eén verzoek bovenaan kan dus evenveel pogingen opleveren als het product van de pogingen per laag. Het voorbeeld uit het SRE-boek: drie lagen die elk drie keer opnieuw proberen (vier pogingen), kunnen van één gebruikersactie 64 pogingen maken (SRE-boek van Google). Een agentopstelling heeft dezelfde lagen: de SDK van het model, een validator die opnieuw vraagt als de output niet te verwerken is, de agentlus en de takenwachtrij die mislukte taken opnieuw start. Sommige van die lagen heb je niet zelf geschreven. De officiële SDK’s van Anthropic bijvoorbeeld proberen het bij tijdelijke fouten, zoals rate limits en serverfouten, standaard twee keer opnieuw: “twice by default” (Anthropic).

3. Limieten beginnen vaak weer bij nul. Agentframeworks hebben wel limieten, dus kijk wat ze dekken. De OpenAI Agents SDK geeft een MaxTurnsExceeded-fout als een run over zijn max_turns-limiet gaat (OpenAI). De Claude Agent SDK van Anthropic heeft een plafond in dollars, maxBudgetUsd, dat “counts only the call’s own spend: totals restored from a resumed session don’t count against it, and a /clear starts the budget over” (Anthropic). Het telt alleen wat die ene aanroep uitgeeft; eerdere totalen uit een hervatte sessie tellen niet mee, en een /clear zet het budget weer op nul. Voor één aanroep is dat een heldere, gedocumenteerde afbakening. Het betekent ook dat het plafond weer bij nul begint als jouw code een taak opnieuw probeert met een nieuwe aanroep, tenzij je het lopende totaal zelf meeneemt.

Dezelfde pagina waarschuwt dat de kostencijfers van de SDK “client-side estimates, not authoritative billing data” zijn: schattingen, geen factuurgegevens. Leg ze naast de gebruiksrapporten van je aanbieder.

Hoe ziet dat eruit in euro’s? (hypothetische getallen)

Neem een hypothetische agent die inkoopfacturen leest en boekt. De prijzen zijn verzonnen ronde getallen, niet de prijslijst van een aanbieder: € 2 per miljoen inputtokens en € 10 per miljoen outputtokens. Elke taak telt 10 stappen. Stap 1 verstuurt 2.000 tokens, elke stap voegt 2.000 tokens aan het gesprek toe, en elke stap schrijft 1.000 tokens.

Een schone run kost € 0,32. Stap 10 kost alleen al € 0,05, omdat hij 20.000 tokens opnieuw verstuurt.

Nu komt de output van stap 10 niet door de validatie: een veld staat in het verkeerde formaat. Om de som eenvoudig te houden, voegen de retry’s hieronder de foutmelding niet aan het gesprek toe. In de praktijk gebeurt dat vaak wel, en dan wordt elke poging duurder.

Wat er gebeurt	Modelaanroepen	Kosten van de taak
Schone run	10	€ 0,32
Stap 10 mislukt; een validator vraagt tot 3 keer opnieuw binnen elk van 4 pogingen van de agentlus	25	€ 1,07
Idem, en de takenwachtrij start de hele taak twee keer opnieuw, elke run met een vers plafond van € 1,50	75	€ 3,21
Eén plafond van € 0,64 voor de hele taak, retry’s inbegrepen	16	€ 0,62, daarna overdracht
Zelfde plafond, retry’s alleen in de agentlus, hooguit 2	12	€ 0,42, daarna escalatie

De derde rij kost tien keer zoveel als de schone run, en geen enkel plafond werd bereikt, omdat elk plafond per run gold.

Reken het door. Bij 2.000 facturen per maand kost een schone maand € 640. Duwt een promptwijziging 30% van de taken in die fout, dan kost de maand € 2.374. Met de regel uit de laatste rij kost hij € 700, en komen 600 facturen met een trace terug bij een mens in plaats van ongemerkt geld te verbranden.

Is 30% overdreven? Het model-portfolio, het boek achter het ROUTE-framework hieronder, beschrijft een samengesteld geval waarin één promptwijziging ongeveer een derde van de output van een agent buiten het verwachte formaat duwde. De retry-lus zou de maandkosten van die route ruwweg hebben verdrievoudigd, als een meter per route het niet diezelfde ochtend had opgemerkt.

Hoe houd je retry’s onder één plafond?

1. Maak één budget per taak. Tokens, geld, seconden en toolaanroepen. Elke poging, retry, fallback en subagent put eruit. Geef het restant door; geef een deelstap nooit een vers budget.
2. Begrens de output van elke aanroep. Stel per aanroep een maximale outputlengte in. Dan ken je het ergste geval van de volgende aanroep al voordat je hem doet: de input die je gaat versturen plus het outputplafond.
3. Controleer vóór elke aanroep. Is er minder over dan dat ergste geval, stop dan.
4. Laat één laag de retry’s doen. Kies de agentlus of de client, niet allebei, en zet de rest op nul. Probeer het alleen opnieuw bij fouttypen die je als veilig hebt opgeschreven, zoals een time-out of een rate limit, en dan een vast aantal keren. Wacht na elke mislukking langer, met wat willekeur, zodat niet alle clients tegelijk opnieuw proberen. Het SRE-boek zegt het zo: “Always use randomized exponential backoff when scheduling retries.”
5. Stop bij het onbekende. Een fout die je nog niet eerder zag, beëindigt de run.
6. Geef terug, verstop niets. Is het plafond bereikt, geef dan het deelresultaat, de trace en het aantal retry’s terug aan een aangewezen persoon.
7. Tel je retry’s. Log per taak een retry-teller, en laat een alarm afgaan als het aantal aanroepen per taak stijgt terwijl het aantal binnenkomende taken gelijk blijft.

Een redelijk eerste plafond is ongeveer twee keer de kosten van een gemeten schone run. Bekijk de eerste weken elke taak die het plafond raakt, en stel het daarna bij op basis van wat je ziet.

Waar hoort deze regel thuis in ROUTE?

ROUTE is een framework om meerdere AI-modellen te beheren zoals een belegger een portefeuille beheert: elk model heeft een taak, een kostenklasse en een fallback, en niets draait zonder eigenaar. Het heeft vijf stappen:

1. Register. Leg van elk model vast wat zijn taak is, in welke kosten- en privacyklasse het valt en wanneer het uit bedrijf gaat.
2. Doel-typering. Benoem wat een taak nodig heeft (redeneerdiepte, formaat, snelheid, kwaliteit, privacy) voordat je een model kiest.
3. Uitvoeringsbeleid. Schrijf de routeringsregels, cascades en fallbacks die bepalen welk model welk verzoek afhandelt.
4. Tracken. Meet kosten, snelheid en kwaliteit per route, zodat een verspillingspatroon opvalt vóór de factuur.
5. Evolueren. Promoveer, degradeer en neem modellen uit bedrijf op een vast ritme, zodat het einde van een model gepland is en geen paniekactie.

ROUTE komt uit Het model-portfolio, een boek van de auteur van deze site, dat nu verkrijgbaar is. Je hebt het boek niet nodig om ermee te werken. De frameworkpagina geeft de korte versie, en Wat is modelroutering? legt uit wat een route is.

Voor de factuuragent hoort het runtimebudget in twee stappen:

• Uitvoeringsbeleid. De retry-regels horen bij de route, naast de fallback: bij welke fouten een retry mag, hoe vaak, in welke laag, en het ene taakplafond dat ze allemaal delen. Het boek vat de fout die dit voorkomt samen in drie korte zinnen: “De time-out per aanroep begrensde elke aanroep. Het retry-beleid begrensde elke poging. Niets begrensde de route.” Een modelcascade die naar een groter model escaleert, heeft hetzelfde plafond nodig.
• Tracken. Kosten per taak en een retry-teller per route. De totale maanduitgaven kunnen een lus dagenlang verbergen; een meter per route laat hem binnen enkele uren zien.

Neem voor de geldmeter de prijzen van de prijspagina van de aanbieder zelf. De auteur van deze site bouwde ook Undominated.ai, een onafhankelijke index van prijzen voor AI-inferentie; het is zijn eigen project, dus houd daar rekening mee.

Probeer het vandaag (15 minuten)

Kies één agent die je draait. Schrijf elke plek op waar een retry kan gebeuren: de instellingen van de SDK, een eventuele validator, de agentlus, de takenwachtrij, de planner. Zet bij elke plek het aantal pogingen en vermenigvuldig ze.

Beantwoord daarna één vraag: als de taak van voren af aan opnieuw wordt geprobeerd, begint het budget dan weer bij nul? Is het product hoger dan 10, of is het antwoord ja, wijs deze week dan één laag aan die de retry’s doet, en geef de taak één plafond.

Citeer deze pagina:Agent-runtimebudget: houd retry's binnen hetzelfde plafond.Len P. van der Hof. https://lenvanderhof.com/nl/blog/agent-runtimebudget/ · Gepubliceerd 3 oktober 2026.