"De prijs per token is het afgelopen jaar gehalveerd, en toch is onze AI-rekening verdubbeld." We horen het bijna wekelijks. Het is geen paradox: het verbruik groeit sneller dan de prijs daalt. Elke verbetering van een AI-toepassing — langere instructies, meer opgehaalde documenten, agents die twintig stappen zetten — kost tokens. En die tokens tellen op.

Het goede nieuws: tokenverbruik is geen natuurverschijnsel. Het is een ontwerpkeuze, en dus te sturen. In dit artikel zetten we de technieken op een rij die het verbruik aantoonbaar omlaag brengen: van prompt caching en smart routing tot caveman-mode voor developers. Zonder te beknibbelen op kwaliteit, want een goedkoper antwoord dat niet klopt is het duurste antwoord dat er is.

Gaat het bij jou niet om zelfgebouwde toepassingen maar om de verbruikscredits van ChatGPT, Claude of Copilot? Lees dan eerst hoe die afrekening werkt. Dit artikel gaat over toepassingen die je organisatie zelf bouwt of laat bouwen op een AI-model.

Eerst begrijpen waar de tokens heen gaan

Voordat je gaat besparen, moet je weten waarop. Een AI-rekening bestaat uit drie delen die elk anders geprijsd zijn.

Invoer (input). Alles wat je naar het model stuurt: systeeminstructies, de vraag, opgehaalde documenten, gespreksgeschiedenis, tool-definities. Bij de meeste toepassingen is dit verreweg het grootste deel van het verbruik, omdat een model niets onthoudt tussen twee aanroepen en alles telkens opnieuw meegaat.

Uitvoer (output). Wat het model terugschrijft. Per token een veelvoud duurder dan invoer, maar meestal een klein deel van het totaal — tenzij je lange rapporten of complete codebestanden laat genereren.

Redeneren (thinking). Modellen die eerst "hardop nadenken" produceren tussenstappen die je nooit ziet, maar wél betaalt als uitvoer. Hoe dieper het model mag nadenken, hoe hoger dit deel.

De eerste stap is dus altijd meten: tag elke aanroep met de toepassing, het team en de taak, en kijk per toepassing naar de verhouding invoer, uitvoer en cache. Wie dat niet doet, optimaliseert in het duister. In de praktijk zien we dat alleen al het zichtbaar maken van verbruik per toepassing tot lagere kosten leidt, nog voordat er één technische aanpassing is gedaan.

1. Prompt caching: betaal niet elke keer opnieuw voor hetzelfde

De grootste besparing met de minste moeite. Bij prompt caching onthoudt de aanbieder het vaste begin van je prompt — systeeminstructies, tool-definities, een groot referentiedocument — zodat het bij de volgende aanroep niet opnieuw verwerkt hoeft te worden. Bij Anthropic kost het lezen uit de cache ongeveer een tiende van de normale invoerprijs; bij OpenAI ongeveer de helft. Bij toepassingen waar 80 tot 90 procent van de invoer per aanroep identiek is, kan dit de invoerkosten dus fors drukken.

De valkuil: caching werkt op basis van een exact gelijk begin. Eén afwijkende byte — een tijdstempel in de systeeminstructie, een willekeurig gesorteerde lijst, een gebruikersnaam vooraan — en de cache mist elke keer. De regel is simpel: vaste inhoud vooraan, variabele inhoud achteraan. En controleer in de gebruiksstatistieken of de cache daadwerkelijk geraakt wordt. Nul cache-hits bij een toepassing met vaste instructies is een bug, geen pech.

2. Smart routing: niet elke vraag verdient het zwaarste model

De meeste toepassingen sturen alles naar één model, meestal het krachtigste. Maar een groot deel van de aanvragen is eenvoudig: classificeren, een veld uit een document halen, een standaardvraag beantwoorden. Daar is een kleiner, veel goedkoper model ruim voldoende voor.

Smart routing (of model routing) zet een lichte beslisstap vóór het model: een eenvoudige vraag gaat naar het goedkope model, een complexe naar het zware. Onderzoek van de makers van het open-source framework RouteLLM liet zien dat zo'n router op bepaalde benchmarks ruim 85 procent van de kosten bespaarde, terwijl 95 procent van de kwaliteit van het zware model overeind bleef. Die cijfers verschillen per taak, maar de richting is consistent: gemengd verkeer kan vrijwel altijd goedkoper.

Een slimme variant is escalatie: begin standaard met het goedkope model en schakel alleen op naar het zware model als het antwoord onzeker is of een controle niet haalt. Let wel: een cache is per model. Wie tussen modellen wisselt, verliest de cachewinst uit punt 1. Meet dus de totale kosten per afgeronde taak, niet per aanroep.

3. Het juiste denkniveau per taak

Moderne modellen laten je instellen hoe diep ze mogen nadenken voordat ze antwoorden. Dat is een knop die veel organisaties op "maximaal" laten staan — voor elke taak. Het verschil tussen laag en maximaal kan in uitvoertokens een veelvoud zijn.

De vuistregel: hoog voor werk waar fouten duur zijn (code, juridische analyse, complexe planning), laag voor routinewerk (samenvatten, classificeren, eenvoudige vragen). Meet het effect per taak op een representatieve set voorbeelden. Vaak blijkt het nieuwste model op een laag denkniveau beter én goedkoper dan het vorige model op het hoogste niveau — en dan is dát de betere route dan een ingewikkelde routeringsopzet.

4. Batchverwerking voor alles wat niet nu hoeft

Nachtelijke verwerking van documenten, het verrijken van een klantbestand, het classificeren van duizend tickets: niets daarvan hoeft binnen een seconde klaar te zijn. Alle grote aanbieders bieden een batch-variant waarbij je resultaten binnen een aantal uur krijgt tegen ongeveer de helft van de prijs.

Dit is een puur organisatorische beslissing: welk deel van je verbruik is realtime nodig, en welk deel niet? In de praktijk is dat tweede deel groter dan gedacht. Combineer batching met caching en de besparing stapelt.

5. Context opschonen: minder meesturen, hetzelfde antwoord

Dit is waar de meeste winst zit bij toepassingen die al een tijdje draaien. Systeeminstructies groeien in de loop van de tijd aan tot pagina's vol uitzonderingen. Een kennissysteem haalt tien documentfragmenten op waar drie volstaan. Een agent sleept de volledige uitkomst van elke tussenstap mee tot aan het einde.

Concrete maatregelen:

Snoei de systeeminstructie. Elke regel die er ooit bijgezet is "voor de zekerheid" kost bij elke aanroep opnieuw tokens. Test welke regels nog effect hebben.

Beperk wat je ophaalt. Bij RAG-toepassingen: minder fragmenten, beter gerangschikt. Vijf relevante passages verslaan vijftien halfrelevante — in kwaliteit én in kosten.

Ruim tussenresultaten op. Laat een agent oude tool-uitkomsten wissen of samenvatten zodra ze hun werk gedaan hebben, in plaats van ze tot het einde mee te slepen. Aanbieders bieden hier inmiddels ingebouwde opties voor (context editing, compactie).

Comprimeer vaste documenten. Een lange handleiding die bij elke aanroep meegaat, kan vaak gehalveerd worden zonder verlies van de informatie die het model echt gebruikt.

6. Uitvoer beperken — en "caveman" voor developers

Uitvoertokens zijn per stuk het duurst, dus elke overbodige zin die een model schrijft is dubbel zonde. Vraag om gestructureerde uitvoer (alleen de velden die je nodig hebt) in plaats van een lopende tekst. Geef een maximale lengte mee. En laat het model niet herhalen wat de vraag was.

Een voorbeeld dat in developmentteams snel populair is geworden, is de caveman-aanpak: een instructieset voor codeer-assistenten zoals Claude Code die het model laat antwoorden in telegramstijl. Geen beleefdheden, geen inleidingen, geen samenvattingen van wat het net gedaan heeft — code, commando's en foutmeldingen blijven exact, al het andere valt weg. De makers claimen tot 65 procent minder uitvoertokens; onafhankelijke metingen komen uit op zo'n 10 tot 25 procent. Het is dus geen wondermiddel, maar wel gratis en direct toepasbaar.

Twee kanttekeningen. Eén: uitvoer is bij de meeste toepassingen een klein deel van de totale rekening, dus het effect op het totaal is bescheiden. Twee: de instructie zelf kost invoertokens. Bij lange sessies verdient dat zich terug via caching; bij losse korte vragen niet. Interessanter voor de totale rekening is de bijbehorende aanpak om projectinstructies (zoals een CLAUDE.md-bestand) te comprimeren: die gaan bij élke aanroep mee, en halvering daarvan telt bij elke stap.

7. Semantische cache en deduplicatie

Veel toepassingen krijgen steeds dezelfde vragen in andere woorden. "Wat is de levertijd?" en "Hoe lang duurt bezorging?" verdienen hetzelfde antwoord, zonder het model twee keer te vragen. Een semantische cache herkent de overeenkomst en serveert het eerdere antwoord. Bij klantenservice en interne helpdesks kan dat een flink deel van de aanroepen schelen, met als bonus een antwoord in milliseconden in plaats van seconden.

Pas dit wel voorzichtig toe: zet de drempel voor "dezelfde vraag" te ruim en je serveert verkeerde antwoorden. Begin streng, meet, en verruim stapsgewijs.

8. Agents in toom houden

Agents zijn de grootste kostenpost van dit moment, om een simpele reden: één opdracht wordt tientallen modelaanroepen, en bij elke aanroep gaat de hele context opnieuw mee. Een agent die blijft rondcirkelen omdat een tool een foutmelding geeft, kan in een uur het budget van een week opmaken.

Wat helpt: een maximumaantal stappen per opdracht, een tokenbudget per taak (aanbieders bieden dit inmiddels als instelling), een harde grens op het aantal herhaalpogingen, en bewaking die ingrijpt als een agent zichzelf herhaalt. Geef een agent bovendien niet veertig tools als hij er vijf gebruikt; elke tool-definitie gaat bij elke stap mee. En laat eenvoudig deelwerk door een goedkoper model doen — zoeken en lezen door een licht model, de eindbeslissing door het zware.

Wat levert het op?

De cijfers die rondgaan ("80 procent besparing") komen vaak van partijen die er een product voor verkopen, dus wees voorzichtig. Wat we in de praktijk zien bij toepassingen die nog niet geoptimaliseerd zijn: caching en batching samen leveren meestal de eerste grote stap, routing en denkniveau de tweede, en context opschonen de derde. Opgeteld is een halvering van de rekening bij gelijkblijvende kwaliteit geen uitzondering. Soms is het meer, soms minder — het hangt af van hoeveel er vóór die tijd al goed stond.

Belangrijker dan het percentage is de randvoorwaarde: je kunt alleen veilig besparen als je kunt meten of de kwaliteit gelijk blijft. Een vaste set voorbeeldvragen met bekende goede antwoorden, die je na elke aanpassing opnieuw draait, is daarom geen luxe maar de basis. Zonder die set is elke besparing een gok.

In welke volgorde?

Begin bij wat niets kost en niets verandert aan de uitkomst, en werk toe naar wat afwegingen vraagt:

1. Meten. Verbruik per toepassing en per taak, gesplitst in invoer, uitvoer en cache.

2. Gratis winst. Prompt caching goed inrichten, batching voor alles wat niet realtime hoeft, overbodige uitvoer schrappen, agent-loops begrenzen.

3. Opschonen. Systeeminstructies snoeien, minder ophalen, tussenresultaten wissen.

4. Afwegingen. Denkniveau per taak, smart routing of een goedkoper model — altijd getoetst aan je voorbeeldset.

De meeste organisaties stoppen na stap 2 en zijn dan al tevreden. Wie door wil, heeft bij stap 4 een werkende meetopzet nodig, en die is er dan al.

Hoe wij hierbij helpen

Gaide werkt als forward deployed engineer: we komen niet met een rapport over tokenkosten, maar gaan naast jouw team zitten en passen het aan. In de praktijk ziet dat er zo uit: we meten eerst een week het werkelijke verbruik per toepassing, richten vervolgens caching, batching en budgetten in, en toetsen elke aanpassing aan een voorbeeldset zodat de kwaliteit aantoonbaar gelijk blijft. Daarna laten we een meetopzet achter waarmee je team het zelf in de gaten houdt. Bouw je AI-agents of een kennissysteem? Dan nemen we tokenverbruik vanaf het ontwerp mee, in plaats van achteraf te repareren.

Stijgt jouw AI-rekening harder dan het gebruik rechtvaardigt? Plan een gesprek — dan kijken we in een uur mee naar je verbruik en vertellen we eerlijk waar de winst zit en waar niet.