Wat kost een AI-agent nou echt? Een maand meten in plaats van gokken

De rekening van je AI-provider is een van de weinige facturen waar bijna niemand een onderbouwd verhaal bij heeft. Er staat een bedrag, het bedrag klopt met het verbruik, en verder is het een zwarte doos. Vraag aan een team welk onderdeel van hun systeem het leeuwendeel opsnoept en je krijgt zelden een antwoord met een getal erin. Meestal krijg je een vermoeden.

Het probleem: een maandbedrag is geen meetgegeven

Een maandbedrag is een optelsom, en een optelsom verbergt precies datgene wat je zoekt. Als je twintig workflows draait en er is er één die per uitvoering vier keer zoveel kost als de rest, dan zie je dat niet terug in het totaal. Je ziet alleen dat het totaal hoger is dan vorige maand. Vervolgens ga je iets doen — een model downgraden, een limiet instellen, een feature uitzetten — zonder te weten of je aan de juiste knop draait.

Erger nog: de reflex is bijna altijd om te sturen op wat zichtbaar is. Antwoorden korter maken. Een goedkoper model kiezen voor alles. Minder vaak draaien. Dat zijn maatregelen die je verzint als je geen data hebt, en ze pakken zelden de werkelijke oorzaak. Bij agent-werk zit die oorzaak namelijk vrijwel altijd aan de invoerkant, en dat is precies het deel dat je niet ziet als je alleen naar de output kijkt.

Een gemiddelde over je hele maandrekening verbergt precies de uitschieter die je wilt vinden.

Wat je precies moet loggen — per call

De oplossing is niet ingewikkeld. Je hebt geen observability-platform nodig en geen dashboardsuite. Je hebt een tabel nodig waarin elke AI-aanroep één regel wordt. Wij houden dat bij in een eigen kostenregister — een SQLite-database, meer is het niet — en er staan op dit moment ruim 3.300 calls in. Dat is genoeg om patronen te zien die je in een maandtotaal nooit had opgemerkt.

Dit zijn de velden die per call vastgelegd worden. Het is een lijst die je vandaag kunt overnemen:

• Provider — welke leverancier de call afhandelde.
• Model — welk exact model, niet de familie. "Het grote model" is geen meetgegeven.
• Tokens in — het aantal input-tokens. Dit is het veld dat het meeste verklaart.
• Tokens uit — het aantal output-tokens.
• Kosten in euro — berekend op het moment van de call, niet achteraf gereconstrueerd.
• Latency — hoe lang de call duurde. Kosten en traagheid hangen vaker samen dan je denkt.
• Correlatie-id — het veld dat losse calls terugvoert naar één workflow of één taak.

Dat laatste veld is het belangrijkste en wordt het vaakst vergeten. Zonder correlatie-id heb je een lijst met dure calls maar geen idee bij welk proces ze horen. Met een correlatie-id kun je vragen stellen als: wat kost één volledige uitvoering van deze workflow, van eerste tot laatste call? Dat is de vraag waar een beslissing uit volgt. Hoe zo'n keten er in de praktijk uitziet, laten we zien bij de workflow-showcase.

Waarom input-tokens de echte kostenpost zijn bij agents

Hier zit de observatie die het meeste oplevert. Bij agent-werk domineert het aantal input-tokens de rekening. Een enkele agent-call kan meer dan 100.000 input-tokens bevatten, tegenover een paar duizend output-tokens. Die verhouding is geen uitzondering — bij agents is het het normale geval.

Dat is ook logisch als je bekijkt waar die invoer vandaan komt. Een agent-call sleept drie dingen mee. Ten eerste de context: systeeminstructies, gereedschapsbeschrijvingen, regels, voorbeelden. Ten tweede de geschiedenis: alles wat er in deze sessie al gezegd en gedaan is, inclusief de uitvoer van eerdere gereedschappen. Ten derde de opgehaalde documenten: wat de retrieval-laag erbij zoekt. Alle drie groeien ze naarmate de agent langer werkt. De output blijft intussen ongeveer even lang: een antwoord, een besluit, een volgende actie.

De consequentie: wie op output-lengte stuurt, stuurt op de verkeerde knop. Je kunt je agent instrueren korter te antwoorden en daarmee een fractie van de kosten raken, terwijl het deel dat de rekening bepaalt onaangeroerd blijft. Pas als je per call ziet hoeveel input er in gaat, wordt duidelijk waar je moet ingrijpen.

API versus abonnement: hoe je die vergelijking eerlijk maakt

De tweede vraag die altijd terugkomt: is een vast abonnement goedkoper dan API-verbruik? Daar valt geen algemeen antwoord op te geven, want het hangt volledig af van jouw verbruikspatroon. Maar je kunt het wel meten in plaats van erover te discussiëren.

Wij houden daarom per call óók bij wat dezelfde call zou hebben gekost onder een vast abonnement. Dat betekent dat er in het register twee bedragen naast elkaar staan: de werkelijke API-kosten en het abonnementsequivalent. Zo kun je aan het eind van een periode twee reële totalen naast elkaar leggen in plaats van een echt bedrag te vergelijken met een schatting.

Waarom dit zo'n verschil maakt: een abonnement is aantrekkelijk bij een hoog, stabiel verbruikspatroon en onaantrekkelijk bij een grillig of laag patroon. Welke van de twee jij hebt, weet je pas als je een maand aan werkelijke calls hebt liggen. Een vergelijking op basis van een gemiddelde dag is misleidend, want juist de pieken bepalen of je binnen of buiten een abonnementslimiet valt.

Drie knoppen die wél werken

Als je eenmaal per call meet, worden drie ingrepen zichtbaar die daadwerkelijk aan de invoerkant zitten.

1. Context snoeien

Kijk wat er structureel in elke call meegaat en vraag per onderdeel of het er echt in hoort. Meestal blijkt een deel van de geschiedenis irrelevant voor de huidige stap, en blijken opgehaalde documenten breder ingeladen te worden dan nodig. Snoeien is geen eenmalige actie maar een ontwerpkeuze: bepaal expliciet wat er per stap mee moet in plaats van standaard alles door te geven. Het correlatie-id helpt je hier, omdat je kunt zien welke stap in een keten het meeste meesleept.

2. Een kleiner model voor het voorwerk

Niet elke stap in een agent-keten vraagt om het zwaarste model. Classificeren, samenvatten, filteren, bepalen of een document relevant is — dat zijn taken waar een kleiner model prima werk levert. Zet het grote model in voor de stap waar redeneren echt telt. Omdat je per call het model logt, kun je achteraf controleren of de kwaliteit inderdaad gelijk bleef en niet stilletjes wegzakte.

3. Caching

Het deel van je invoer dat bij elke call identiek is — systeeminstructies, gereedschapsbeschrijvingen, vaste regels — hoeft niet elke keer opnieuw als verse invoer behandeld te worden. Caching richt zich precies op het stuk dat bij agents het grootst en het meest herhaald is. Dat maakt het de meest directe ingreep op de post die de rekening domineert.

Conclusie: meten is de goedkoopste optimalisatie

Registratie per call voelt als overhead. Het is een tabel bijhouden die niets doet, geen functionaliteit toevoegt en geen gebruiker blij maakt. Maar het is de enige ingreep die alle andere ingrepen mogelijk maakt, en hij kost je een middag werk.

Zonder registratie per call weet je niet welke workflow je geld kost. Je weet alleen wat het totaal is, en op basis van een totaal kun je geen enkele gerichte beslissing nemen — alleen grove. Grove beslissingen op AI-kosten hebben de vervelende eigenschap dat ze meestal ook de kwaliteit raken: je zet iets uit, je gaat naar een kleiner model voor alles, je beperkt het gebruik. Met data per call kun je in plaats daarvan het ene dure onderdeel aanpakken en de rest ongemoeid laten.

Begin dus niet met optimaliseren. Begin met loggen, laat het een maand draaien, en kijk dan pas. De uitschieter die je zoekt zit er vrijwel zeker in — hij was alleen onzichtbaar in het gemiddelde. Wil je weten hoe wij dit inrichten binnen bestaande systemen, kijk dan bij onze diensten.