Wat kost een AI-agent in productie echt en hoe houdt u de token cost onder controle

Toen we de eerste agent voor een klant uit de zware industrie uitrolden — taak: het automatisch samenstellen van wekelijkse rapporten uit vijf systemen — overschreed de totale token cost in de eerste maand de oorspronkelijke schatting vijfvoudig. Niet omdat de agent iets fout deed. Maar omdat we onvoldoende hadden doordacht hoeveel tokens elke stap van de loop verbruikt wanneer de geschiedenis groeit, wanneer een tool-aanroep herhaaldelijk wordt herbeproefd en wanneer de volledige conversatie bij elke aanroep aan de context wordt toegevoegd. Wat in het prototype een paar cent per query kostte, was in productie — met tientallen gebruikers en duizenden dagelijkse taken — een orde van grootte duurder.

Dit artikel gaat niet over hypothetische prijsstelling. Het gaat over waar het geld bij de uitrol van een agent werkelijk naartoe stroomt, waarom gangbare schattingen zo ver van de realiteit afliggen, en welke optimalisaties in de praktijk werken — van kortere context tot routing naar goedkopere modellen en prompt caching.

Waar de token cost van een agent ontstaat

Agents zijn duurder dan enkelvoudige LLM-aanroepen om één eenvoudige reden: elke stap van de loop is een nieuwe API-aanroep, waarbij de groeiende geschiedenis aan de context wordt toegevoegd. Vergelijk dit met klassieke RAG: één query, één aanroep, één antwoord. Een agent met tien stappen doet tien aanroepen — en elk ervan draagt de volledige voorafgaande context mee.

De concrete kostentopologie ziet er als volgt uit:

• Systeemprompt — herhaalt zich bij elke aanroep. Bij een systeemprompt van 2.000 tokens en 8 agentstappen betaalt u achtmaal voor dezelfde tekst.
• Conversatiegeschiedenis — elke Reason-Act-Observe-cyclus voegt extra tokens aan de context toe. Bij langdurige taken groeien de input-tokens kwadratisch.
• Tool-uitvoer — antwoorden van tools (databaseresultaten, API-responses, documenten) worden in de context ingevoegd en vergroten die. Uitgebreide RAG-retrieval vóór elke stap kan de input-tokens verdubbelen.
• Retry-loops — als een tool-aanroep mislukt, probeert de agent het opnieuw. Een retry rate van 10–15 % is in productiesystemen gewoon. Elke retry = een extra aanroep met de volledige context.
• Output-tokens — reasoning van agents (chain-of-thought, stap-voor-stap redeneren) genereert lange antwoorden. Output-tokens zijn doorgaans 3–5× duurder dan input.

Resultaat: een echte agent in productie verbruikt per taak ruwweg 5–50× meer tokens dan u op basis van een prototype zou schatten.

Orde-van-grootte voorbeelden — wat dit betekent in euro's

Modelprijzen veranderen elke 1–3 maanden; ik geef hier indicatieve ordes van grootte die golden op het moment van schrijven. Verifieer altijd de actuele prijs rechtstreeks bij de provider.

Frontier-modellen bewegen zich momenteel in de range van ~$0,10 tot ~$5 per miljoen input-tokens en van ~$5 tot ~$30 per miljoen output-tokens — een factor 50 tussen het goedkoopste en het duurste niveau. Dit is het kernpunt: de keuze van het model is de sterkste kostenhefboom, sterker dan welke andere optimalisatie ook.

Stel u hebt een agent die 100 taken per dag verwerkt:

• Goedkoop niveau (Flash/Haiku-equivalent, $0,10–0,30/1M input-tokens): zelfs bij 50.000 tokens per taak beweegt u zich in de orde van enkele euro's per dag. Maandelijks een paar honderd euro.
• Middenniveau (Sonnet-equivalent, ~$3–5/1M input-tokens): dezelfde belasting kan uitkomen op 1.000–3.000 euro per maand.
• Premiumtier (Opus-equivalent, ~$15+/1M input-tokens): dezelfde belasting kan 5–10× duurder zijn dan het middenniveau.

Als het systeem bovendien draait met een retry rate van 12 %, betaalt u effectief 1,12× per taak — wat bij grotere volumes snel oploopt.

Human escalation is een andere verborgen kost: als de agent 5 % van de taken niet afhandelt en elke escalatie naar een menselijke operator 2–10 euro kost (arbeidstijd), kan dit onderdeel hoger uitvallen dan de token cost zelf.

Vier plaatsen waar de kosten effectief te snijden zijn

1. Korter de context — systematisch, niet toevallig

De grootste besparing zit niet in een goedkoper model, maar in minder tokens per aanroep. Concrete stappen:

• Comprimeer de systeemprompt. Elke overbodige regel in de systeemprompt betaalt u honderd keer per dag terug. Controleer regelmatig wat er werkelijk in thuishoort.
• Vat de conversatiegeschiedenis samen. In plaats van de volledige geschiedenis in de context te voegen, laat u de agent na N stappen een samenvatting maken. LangGraph heeft hiervoor een ingebouwd summarization-node. U verliest enige granulariteit, maar voor de meeste taken maakt dat niet uit.
• Filter tool-uitvoer. Als RAG-retrieval vijf documenten teruggeeft maar de agent er slechts één nodig heeft, betaalt u onnodig voor vier. Stel reranking in en begrens het aantal fragmenten dat in de context wordt ingevoegd.
• Beperk de output-lengte. De reasoning-stroom hoeft niet altijd onbeperkt te zijn. Voor standaardstappen volstaat een kort antwoord; gedetailleerde chain-of-thought reserveert u voor werkelijk complexe beslissingspunten.

2. Routeer naar een goedkoper model voor eenvoudige stappen

Niet elke agentstap heeft een frontier-model nodig. Typische verdeling:

• Orkestratiestappen (wat te doen, welke tool aan te roepen): doorgaans afhandelbaar door een goedkoper model
• Retrieval en datafiltering: goedkoop model of zelfs deterministische logica
• Definitieve synthese van het antwoord voor de gebruiker: hier loont een sterker model
• Verificatie en self-consistency check: goedkoop model in een loop

LLM-routing — dynamische modelselectie op basis van de complexiteit van de stap — is een optimalisatie die we apart bespraken in het artikel over LLM-routing en cascading. In een agentcontext werkt hetzelfde principe: een dispatcher classificeert elke stap en stuurt die naar het goedkoopste model dat de stap aankan.

3. Prompt caching — betaal de systeemprompt één keer

Prompt caching is een technologie die Anthropic, OpenAI en Google aanbieden in hun API's. Het principe: als het begin van de context (doorgaans de systeemprompt of een lang statisch document) zich herhaalt over aanroepen heen, cachet de provider dat aan de serverzijde en rekent hergebruik slechts een fractie van de standaardprijs aan — ruwweg –90 % op het gecachete deel.

Voor een agent met een lange systeemprompt die in tientallen gelijktijdige sessies draait, is caching een van de snelst te implementeren besparingen. We gaan hier dieper op in het artikel over prompt caching en kosten.

Voorwaarde: caching werkt goed voor stabiele delen van de prompt. Als elke aanroep andere dynamische inhoud aan het begin bevat, zal de cache hit rate laag zijn en de besparing minimaal.

4. Stel limieten in — vóór uitrol, niet na een incident

Dit is het punt dat in technische literatuur als voetnoot wordt behandeld, maar in de praktijk een wet is: een agent zonder harde limieten is een financieel risico.

• max_steps (of equivalent): maximaal aantal loopstappen voor de agent stopt
• max_tokens_per_run: totaal tokenbudget per taak
• timeout: tijd waarna de agent stopt en een gedeeltelijk resultaat teruggeeft
• cost_budget_per_day: op systeemniveau, bewaakt door een alert

Een agent zonder max_steps-limiet kan bij onverwachte invoer of een tool-afhankelijkheidsprobleem vastlopen in een loop en 's nachts duizenden aanroepen genereren — met een factuur in de orde van duizenden euro's. Dat is niet hypothetisch. We zien het in productiesystemen, en het is altijd te voorkomen.

Agentic RAG: waar kosten ongemerkt escaleren

Agentic RAG — RAG waarbij de agent zelf beslist hoe vaak en wat te laden — is 5–10× duurder dan klassieke RAG. Niet omdat het slecht is, maar omdat het meer werk verzet.

Typische volgorde van agentic RAG voor één vraag:

1. 1.Bepalen welke retrieval-strategie te gebruiken (1 LLM-aanroep)
2. 2.Eerste zoekactie (retrieval + reranking)
3. 3.Beoordelen of de resultaten volstaan (1 LLM-aanroep)
4. 4.Eventueel een tweede zoekactie met aangepaste query (retrieval + reranking)
5. 5.Synthese van het antwoord (1 LLM-aanroep met de volledige verzamelde context)

Elke stap heeft een prijs. Als u bij elk van deze aanroepen bovendien een sterk model gebruikt, lopen de kosten snel op.

Optimalisatie: gebruik een goedkoop model voor de beslissingsstappen (1, 3) en een sterk model alleen voor de definitieve synthese (5). En stel een limiet op het aantal retrieval-iteraties — de meeste vragen worden opgelost in 1–2 rondes, niet in vijf.

Meer over de architectuur van agentic RAG vindt u in het artikel Agentic RAG — hoe het in de praktijk werkt.

Batch API: wanneer u het resultaat niet onmiddellijk nodig hebt

Als u taken hebt die geen real-time antwoord vereisen — offline documentverwerking, nachtelijke analytische runs, trainingsdata — is de Batch API een forse besparing. Anthropic (en andere providers) bieden –50 % op batch-aanroepen ten opzichte van de synchrone prijs, ten koste van verwerking met een vertraging van enkele uren.

Architectuur: het frontendsysteem verzamelt taken in een wachtrij, de batch-job draait 's nachts of bij lage belasting, resultaten worden naar de database geschreven en zijn 's ochtends beschikbaar. Voor veel industriële toepassingen — het samenvatten van rapporten, het categoriseren van documentatie, het extraheren van data uit PDF's — is deze aanpak financieel een orde van grootte voordeliger.

Kostenmeting: wat te volgen in productie

Token cost zonder observability is een black box. We raden aan minimaal de volgende metrics bij te houden:

• Cost per task type — verschillende taaktypen hebben een ander kostenprofiel. Zonder dit onderscheid weet u niet waar te optimaliseren.
• Retry rate per tool — welke tool veroorzaakt het vaakst een retry? Is het een toolfout of een zwakke tool description?
• Average steps per run — als het gemiddeld 8 stappen kost waar u 4 verwachtte, moet u naar de architectuur kijken.
• Cache hit rate — als u prompt caching gebruikt, welk percentage van de aanroepen cachet werkelijk? Onder 60 % is caching verkeerd ingesteld.
• Human escalation rate — welk percentage van de taken eindigt in escalatie? Als dit groeit, faalt de agent waarschijnlijk op scenario's waarvoor hij niet is ontworpen.

Tools als Langfuse (self-hostable, framework-agnostic) of LangSmith (diepe LangGraph-integratie) leggen deze metrics vast op het niveau van elke node en aanroep. Zonder observability tast u in het duister — meer hierover in het artikel over observability van AI-agents.

Open-weight modellen als kostenalternatief

Voor teams die voornamelijk de kostenkant willen aanpakken, zijn de huidige open-weight modellen een realistisch alternatief. Families als Qwen 3.x, DeepSeek of Llama 4 behalen op veel agentic benchmarks resultaten die vergelijkbaar zijn met frontier closed-source modellen — bij nul of minimale API-kosten als ze on-premises draaien.

U betaalt een GPU-server in plaats van een API. Bij grote volumes (tienduizenden dagelijkse aanroepen) ligt het break-evenpunt doorgaans binnen maanden. Voor gereguleerde omgevingen waar data het bedrijf niet mogen verlaten, is on-prem bovendien een compliance-vereiste, niet alleen een kostenkwestie.

Afweging: on-prem vereist engineering-capaciteit voor het beheer van de infrastructuur, de serving-stack (vLLM, SGLang), monitoring en modelupgrades. Niet elk team heeft die capaciteit.

Veelgestelde vragen

Waarom is mijn agent veel duurder dan ik oorspronkelijk schatte?

De meest voorkomende oorzaak is een combinatie van drie factoren: groeiende geschiedenis in de context bij elke loopstap, retry-aanroepen bij mislukte tools en lange systeemprompts die bij elke aanroep worden herhaald. Een prototype test doorgaans 1–2 stappen met statische invoer. Productie betekent echte invoer, echte toolfouten en gebruikers die de agent in onverwachte toestanden brengen. We raden aan de cost per run op te splitsen in componenten (systeemprompt, geschiedenis, tool-uitvoer, output) voordat u begint te optimaliseren.

Loont het om prompt caching te implementeren?

Als uw systeemprompt langer is dan 1.000 tokens en de agent tientallen of honderden sessies per dag draait, is het antwoord vrijwel altijd ja. De implementatie is doorgaans eenvoudig (een parameter bij de API-aanroep), de besparing op het gecachete deel bedraagt ruwweg –90 % bij Anthropic. Voorwaarde is de stabiliteit van het begin van de context — als de systeemprompt bij elke aanroep wijzigt, zal de cache hit rate laag zijn.

Wanneer loont het om van een API over te stappen op een on-prem model?

Dat hangt af van het volume en de compliance-vereisten. Als vuistregel: als de maandelijkse API-factuur de kosten van een dedicated GPU-server overtreft (inclusief beheer en HW-afschrijving) — doorgaans ergens in de orde van enkele duizenden euro's per maand — is een analyse zinvol. Voor gereguleerde sectoren (gezondheidszorg, recht, financiën) is on-prem bovendien een GDPR-compliance-vereiste, niet alleen een kostenvraag.

Hoe stel ik een verstandige max_steps-limiet in?

Begin met profileren — hoeveel stappen heeft uw typische taak werkelijk nodig? Als de mediaan 4 stappen is en het 95e percentiel 8, stel de limiet dan in op 12–15 met een veiligheidsmarge. De limiet moet hoog genoeg zijn om legitiem lange taken niet te onderbreken, maar laag genoeg om oneindige loops te vangen. De combinatie van max_steps + timeout + een monitoring-alert voor runs die meer dan 80 % van de limiet bereiken, is in de praktijk robuust.

Wat is een grotere kostenpost — tokens of human escalation?

Dat hangt af van de escalatierate. Als de agent 1–2 % van de taken escaleert en menselijke tijd 5 euro per incident kost, is dat bij 1.000 taken per dag 50–100 euro/dag aan escalaties — wat de token cost van een goedkoper model kan overstijgen. Voor systemen met hoge taakvolumes en een niet-verwaarloosbare escalatierate is het verlagen van de escalatie (betere agenttraining, duidelijkere guardrails) een betere investering dan besparen op tokens.

*De kosten van een agent in productie zijn meetbaar en beheersbaar — maar alleen als u ze daadwerkelijk meet. Bij MP Industrial Solutions helpen we bedrijven agentic systemen te ontwerpen met een helder kostenprofiel vanaf het begin, in plaats van achteraf te optimaliseren nadat de eerste maandfactuur een verrassing blijkt. Als u nadenkt over de uitrol van een agent en vooraf een realistisch kostenmodel wilt opstellen, praten we graag met u.*