Tokenoptimalisatie betekent dat je de hoeveelheid tekst verkleint die een taalmodel verwerkt, terwijl de informatie behouden blijft die het nodig heeft om juist te antwoorden. Denk aan de instructies, de gespreksgeschiedenis en de documenten die met elke vraag worden meegestuurd.
Het doel is om de kosten van een juist antwoord te verlagen. Een kortere prompt kost misschien minder, maar die besparing verdwijnt als ontbrekende informatie tot fouten en nieuwe pogingen leidt. Om het effect te meten, deel je de kosten van alle pogingen door het aantal taken dat correct is afgerond.
De verborgen kosten van overbodige tokens
Stel je een AI-assistent voor die vragen beantwoordt over de interne documenten van een bedrijf. Een gebruiker heeft een uur lang drie lange rapporten besproken. Dan volgt een korte vervolgvraag: “Komt het tweede rapport tot dezelfde conclusie als het eerste?”
Om die vraag te beantwoorden, moet de assistent weten welke rapporten bedoeld worden en in beide de relevante passages vinden. Toch sturen veel applicaties alles opnieuw naar het model: de instructies, het hele gesprek, alle drie de rapporten en eerdere zoekresultaten.
In dit hypothetische voorbeeld komt dat neer op ongeveer 80.000 inputtokens. Het antwoord hangt intussen af van maar twee passages en net genoeg gespreksgeschiedenis om de rapporten te herkennen.
Al dat materiaal meesturen heeft een prijs. Je betaalt voor inputtokens, al krijgt content uit de cache soms een lager tarief. Grote inputs kosten ook meer verwerkingstijd en laten minder ruimte over voor nieuwe informatie. En irrelevante of tegenstrijdige details maken het voor het model lastiger om het juiste bewijs te vinden, waardoor de kans op een fout antwoord groter wordt.
Schrappen ligt voor de hand, maar blind schrappen schept nieuwe problemen. Haal de eerdere berichten weg en de assistent weet niet meer welk rapport “het tweede” is. Kort de rapporten te ver in en de assistent antwoordt vanuit de verkeerde sectie. Nieuwe pogingen kunnen de besparing van het goedkopere verzoek dan weer tenietdoen. Het gaat erom de juiste tokens te sturen, en alleen die.
Wat tokens zijn en hoe ze worden afgerekend
Tokens zijn de kleine stukjes tekst die een model leest en schrijft. Een token kan een heel woord zijn, een deel van een woord of een leesteken. In het Engels staan 100 tokens voor ongeveer 75 woorden. Onze uitleg over tokens in AI behandelt de basis.
Het exacte aantal hangt af van het model. Anthropic meldt dat Claude 4.7 en latere modellen voor dezelfde tekst ongeveer 30 procent meer tokens produceren dan eerdere modellen. Een telling op het ene model geldt dus niet automatisch voor het volgende.
Aanbieders tellen en rekenen tokens af in een paar groepen:
- Inputtokens zijn alles wat je verstuurt: instructies, geschiedenis, documenten en resultaten van tools.
- Outputtokens zijn wat het model terugschrijft. Ze zijn meestal duurder. Op de API-prijslijst van Anthropic kost output in oktober 2026 vijf keer zoveel als input, voor elk actueel Claude-model.
- Cached inputtokens zijn input die de aanbieder al heeft verwerkt voor een eerder verzoek dat op dezelfde manier begon. Ze kosten een fractie van het normale tarief.
- Reasoning tokens zijn de verborgen denkstappen van reasoning-modellen. Volgens de documentatie van OpenAI nemen ze ruimte in het context window in en worden ze als output afgerekend. Ze zitten al in de outputtelling, dus tel ze niet dubbel.
De afbeelding hierboven laat nog iets zien. De meeste tokens in een verzoek komen nooit op het scherm. De gebruiker ziet één korte vraag en één antwoord, terwijl het model alles daarachter ontvangt.
Wat prompt engineering is en waarom het ertoe doet
Prompt engineering is het schrijven en testen van de instructies, voorbeelden en regels die je een taalmodel meegeeft, zodat het een taak betrouwbaar uitvoert. Hier begint tokenoptimalisatie, omdat de system prompt met elke call meegaat.
Een goed ontworpen prompt kan overbodige instructies schrappen, antwoorden passend beknopt houden en nieuwe pogingen voorkomen. Soms heeft een prompt juist meer voorbeelden of details nodig om betrouwbaar te werken. Meet de besparing daarom over de hele taak, niet alleen over de prompt.
Prompt engineering gaat over de tekst die je zelf schrijft. Context engineering gaat over alles wat de applicatie tijdens het draaien toevoegt, zoals gespreksgeschiedenis, documenten en resultaten van tools. In de meeste applicaties zitten daar de meeste tokens, dus dit artikel behandelt beide.
De meeste system prompts groeien in de loop van de tijd. Na elk probleem komt er een regel bij en niemand haalt de oude weg. Bij de documentassistent ziet dat er bijvoorbeeld zo uit:
Je bent een behulpzame, vriendelijke en zeer deskundige AI-assistent voor ons bedrijf. Het is heel belangrijk dat je altijd nauwkeurig bent. Je krijgt documenten en moet daar vragen over beantwoorden. Lees alle documenten heel zorgvuldig voordat je antwoordt. Probeer grondig maar ook beknopt te zijn, en behandel alles wat relevant kan zijn. Vermeld altijd je bronnen. Verzin niets. Als je ergens niet zeker van bent, zeg dat dan. Maak je antwoorden netjes op. Onthoud: nauwkeurigheid is het allerbelangrijkste, dus verzin nooit iets en verwijs altijd naar de documenten.En dit is een opgeschoonde versie:
Je beantwoordt vragen van medewerkers over de documentfragmenten hieronder.
Regels:
- Gebruik alleen de fragmenten. Beantwoorden ze de vraag niet, zeg dan wat er ontbreekt.
- Verwijs bij elke bewering naar [document, sectie].
- Meld elke tegenstrijdigheid tussen fragmenten die het antwoord beïnvloedt.
Opmaak: één zin met het directe antwoord, daarna maximaal drie onderbouwende punten. Maximaal 150 woorden.
Voorbeeld:
V: Welke opzegtermijn heeft een medewerker?
A: Eén maand [Personeelshandboek, 4.2].
- Voor leidinggevenden geldt twee maanden [Personeelshandboek, 4.3].De tweede prompt is explicieter en minder herhalend. Herhaalde waarschuwingen maken plaats voor een woordlimiet, een vaste vorm voor bronverwijzingen en één voorbeeld. Hij telt minder woorden, maar woorden zijn geen tokens. Controleer beide versies daarom met de tokenizer van je eigen model voordat je het als besparing rekent. Ook vertelt de nieuwe prompt het model wat het moet doen als de fragmenten het antwoord niet bevatten. Omdat hij zowel de taak als de lengte verandert, test je hem voordat je overstapt.
Het engineeringteam van Anthropic geeft daarbij een nuttige waarschuwing: een minimale prompt is niet altijd een korte prompt. Het model heeft nog steeds genoeg sturing nodig om zich te gedragen zoals bedoeld. Een paar gevarieerde voorbeelden werken meestal beter dan een lange lijst randgevallen.
Meten voordat je optimaliseert
Of een wijziging heeft geholpen, weet je alleen als je weet waar je begon. Leg daarom eerst een nulmeting vast op een set echte taken, voordat je iets aanpast. Houd deze cijfers bij:
- Input- en outputtokens per call, uitgesplitst naar system prompt, geschiedenis, documenten en resultaten van tools.
- Kosten per geslaagde taak, met elke poging meegeteld, ook mislukte taken en herhaalpogingen.
- Responstijd, zowel tot het eerste woord als tot het volledige antwoord.
- Antwoordkwaliteit, beoordeeld tegen een referentieantwoord of een checklist.
- Herhaalpogingen en herstelverzoeken, van gebruikers of van code die de output afkeurt.
- De kosten van de optimalisatie zelf, zoals extra calls om samen te vatten.
Geef aan of je de kosten van de model-API meet of de kosten van de hele workflow. Neem voor de totale workflowkosten ook retrieval, reranking, betaalde tools en menselijke controle mee waar dat relevant is.
OpenAI en Anthropic bieden allebei endpoints om tokens te tellen, als je vooraf een schatting wilt.
Technieken om het aantal tokens te beperken
Zes technieken dekken de belangrijkste bronnen van overbodige tokens. Anthropic omschrijft het doel als de kleinst mogelijke set tokens met veel signaal die de kans op het gewenste resultaat het grootst maakt. De tabel laat zien waar elke techniek tokens bespaart en waar je op moet letten.
| Techniek | Waar je tokens bespaart | Let op |
|---|---|---|
| Schrijf compacte, expliciete instructies | System prompt en tooldefinities | Een regel of voorbeeld weglaten dat het model nodig heeft |
| Bewaar alleen het deel van het gesprek dat nog telt | Gespreksgeschiedenis | Besluiten, getallen of uitzonderingen kwijtraken |
| Haal passages op in plaats van hele documenten | Opgehaalde content | De passage missen die het antwoord verandert |
| Filter de resultaten van tools | Tooloutput | Een veld weghalen dat een latere stap nodig heeft |
| Beperk de lengte van output en reasoning | Output- en reasoning tokens | Antwoorden die te vroeg stoppen of aan kwaliteit inboeten |
| Gebruik code en korte overdrachten | Hele calls en workflows met meerdere stappen | Tool calls en sub-agents die nog steeds tokens gebruiken |
Schrijf compacte, expliciete instructies
Pas de opschoning van de prompt hierboven toe op elk vast onderdeel van het verzoek. Noem elke regel één keer, vervang vage woorden door concrete limieten en houd alleen de voorbeelden die echt iets toevoegen. Ook tooldefinities tellen mee. Bij Claude Opus 5.5, Sonnet 5.5 en Haiku 5.5 voegt het inschakelen van tools met de standaardinstellingen 286 tokens aan ingebouwde instructies toe. Je eigen tooldefinities komen daar nog bij, dus laad alleen de tools die een taak nodig heeft.
Bewaar alleen het deel van het gesprek dat nog telt
De meeste gesprekken hebben niet elk eerder bericht woord voor woord nodig. Bewaar de laatste paar berichten volledig en vervang de rest door een samenvatting.
Een samenvatting is een kopie met verlies, dus bepaal wat er nooit uit mag verdwijnen. Leg besluiten (“gebruik de cijfers van 2026”), randvoorwaarden (“laat de pilotregio buiten beschouwing”), open vragen en de lijst met documenten in het gesprek vast in een apart statusblok. Met die lijst kan de assistent ook bepalen welk rapport “het tweede” is. Bewaar exacte waarden exact, want een samenvatting die “60 dagen” verandert in “ongeveer twee maanden” heeft het antwoord veranderd.
Onderzoek ondersteunt gerichte context. In het onderzoek van Chroma uit 2025 werden 18 modellen getest. Op een taak met gespreksgeschiedenis scoorden de geteste modellen significant beter als ze alleen de relevante delen van die geschiedenis kregen. Die gerichte input was ongeveer 300 tokens, tegenover ongeveer 113.000 voor de volledige geschiedenis. Er zit wel een addertje onder het gras. De gerichte versies waren samengesteld op basis van de labels van de dataset zelf, dus de juiste passages werden vooraf aangereikt. Een echte applicatie moet ze nog zelf vinden.
Haal passages op in plaats van hele documenten
Wie drie volledige rapporten meestuurt om één vraag te beantwoorden, besteedt het grootste deel van het budget aan secties waar niemand om vroeg. Retrieval stuurt alleen de passages die bij de vraag passen. Label elke passage met het document en de sectie, zodat het model ernaar kan verwijzen. Onze gids over retrieval-augmented generation legt uit hoe dat werkt.
Neem ook mee waar een passage van afhangt, zoals een latere update, een definitie of een kruisverwijzing. En haal in het begin ruim op. Een ontbrekende passage kost meer dan een paar extra.
Filter de resultaten van tools
Tooloutput wordt makkelijk over het hoofd gezien, omdat niemand die met de hand schrijft. Stel je een zoektool voor die per resultaat 40 velden teruggeeft, waarvan de meeste metadata. Een assistent die die tool vijf keer aanroept, neemt dat allemaal mee in elk volgend bericht. Houd alleen de velden die de taak nodig heeft, beperk het aantal resultaten en verwijder oude resultaten zodra ze zijn gebruikt. De gids van Anthropic noemt het wissen van oude toolresultaten een van de veiligste manieren om de context kleiner te maken.
Beperk de lengte van output en reasoning
Output is meestal duurder dan input en bepaalt het grootste deel van de wachttijd. De latencygids van OpenAI geeft een vuistregel. Halveer je de output, dan kan de latency ongeveer halveren, terwijl het halveren van de prompt maar 1 tot 5 procent kan opleveren. De gids maakt een uitzondering voor zeer grote contexten, waar de lengte van de input zwaarder weegt.
Vraag om de lengte die je nodig hebt en stem die af op de taak. Een simpele ja-of-neevraag heeft één zin nodig. Laat het model met het antwoord beginnen en de samenvatting aan het eind overslaan. Leest een programma het resultaat, kies dan een compact formaat, maar meet het. JSON herhaalt bijvoorbeeld elke sleutel bij elk item, waardoor een lange lijst als JSON meer tokens kan kosten dan als losse regels.
Stel outputlimieten zorgvuldig in. Een limiet stopt antwoorden die uit de hand lopen, maar een krappe limiet breekt antwoorden af, en herstellen betekent de hele context opnieuw versturen. Bij reasoning-modellen telt de verborgen reasoning meestal mee in de limiet. OpenAI waarschuwt dat een antwoord de limiet kan bereiken voordat er zichtbare tekst verschijnt. Je betaalt dan voor input en reasoning zonder een antwoord te krijgen. Ondersteunt een model een instelling voor reasoning effort, dan gebruikt een lagere stand minder reasoning tokens en reageert het model sneller. OpenAI noemt het een knop om bij te stellen, niet de belangrijkste manier om kwaliteit terug te winnen, dus test elke stand.
Gebruik code en korte overdrachten
Rekenen met datums, totalen, sorteren en formaten controleren zijn taken voor geteste code, die ze betrouwbaar afhandelt zonder tekst te genereren. Roept het model die code aan als tool, dan gebruiken de call en het resultaat nog steeds tokens. Geef daarom compacte resultaten terug.
Geef in workflows met meerdere stappen elke stap het vorige resultaat mee, samen met de randvoorwaarden, bronverwijzingen en open vragen die die stap nodig heeft. Laat eerdere geschiedenis alleen weg als die details bewaard zijn gebleven. Anthropic beschrijft sub-agents die met tienduizenden tokens zoeken en een samenvatting van vaak 1.000 tot 2.000 tokens teruggeven. Zo blijft de hoofdcontext klein. De tokens van de sub-agents tellen wel mee, dus meet de hele workflow voordat je het een besparing noemt.
Andere manieren om LLM-kosten te verlagen
Niet elke besparing komt uit het inkorten van wat het model ziet. Sommige verlagen de prijs per token, andere voorkomen calls helemaal. Meet ze los van tokenreductie, zodat je weet welke wijziging wat heeft opgeleverd.
Prompt caching
Prompt caching hergebruikt het werk dat de aanbieder al heeft gedaan voor een identiek begin van de prompt, de prefix, zoals een vaste system prompt of een referentiedocument. Het model ziet nog steeds alle tokens. Een cache hit kan de verwerkingstijd en de kosten van de input verlagen. Hoeveel je bespaart, hangt af van de cachingregels van het model, de lengte van de prefix, hoe lang de cache bewaard blijft en hoe vaak de prefix echt wordt hergebruikt. Bij actuele modellen van OpenAI en Anthropic kost lezen uit de cache een tiende van de normale inputprijs of minder.
Schrijven naar de cache kost iets meer dan een normaal verzoek. Volgens de cachinggids van OpenAI geldt bij GPT-5.6 en latere modellen 1,25 keer het normale inputtarief. Caching loont dus alleen als dezelfde prefix wordt hergebruikt. Zet vaste content vooraan en wisselende content achteraan. Houd er rekening mee dat het samenvatten van de geschiedenis de herbruikbare prefix kan veranderen, waardoor het aantal cache hits daalt. OpenAI raadt aan de totale inputkosten voor en na te vergelijken.
Resultaatcaching
Je kunt ook een afgerond antwoord opslaan en opnieuw gebruiken. Dat past bij antwoorden die langzaam veranderen, zoals de samenvatting van een document dat niemand heeft aangepast. Baseer de cachesleutel op alles wat het antwoord bepaalt: de vraag, de instellingen, de documentversies, de toegangsrechten van de gebruiker en het outputformaat.
Batchverwerking en modelkeuze
Sommige aanbieders rekenen minder als je kunt wachten. Anthropic rekent bijvoorbeeld de halve prijs voor batchverzoeken. Een goedkoper model verlaagt de prijs per token, maar niet het aantal tokens, en heeft misschien langere prompts of meer herhaalpogingen nodig. Ons artikel over het verlagen van LLM-kosten gaat dieper in op caching, batching en routing.
Calls overslaan
Niet elk verzoek heeft een model nodig. Regels kunnen voor de hand liggende gevallen afhandelen, een databasequery kan een statusvraag beantwoorden en een sjabloon kan een bevestiging opmaken. Een overgeslagen call bespaart de volledige kosten.
Veelgemaakte optimalisaties die averechts werken
De meeste mislukte tokenoptimalisaties mislukken op dezelfde manier: de call wordt goedkoper en de taak wordt duurder.
| Optimalisatie | Wat er misgaat | Gevolg in de praktijk |
|---|---|---|
| Prompts samenpersen tot telegramstijl | Afkortingen en ontbrekende verbindingswoorden maken instructies dubbelzinnig | Het model raadt wat je bedoelt, en de output verschilt per run |
| Voorbeelden weglaten om tokens te besparen | Het model verliest zijn duidelijkste signaal over opmaak en toon | Opmaakfouten die nabewerking of een herstelcall vragen |
| Geschiedenis te agressief samenvatten | Uitzonderingen, getallen en besluiten verdwijnen uit de samenvatting | Antwoorden die eerdere afspraken tegenspreken, zonder waarschuwing |
| Te weinig passages ophalen | De passage die het antwoord verandert, ontbreekt | Stellige antwoorden op basis van verouderd of onvolledig bewijs |
| Outputlimieten te laag instellen | Antwoorden stoppen halverwege een zin, of een reasoning-model loopt tegen de limiet aan voordat het antwoordt | Een vervolgcall die de volledige context opnieuw verstuurt |
| Tokens per call schrappen zonder herhaalpogingen bij te houden | Elke call is goedkoper, maar de taak heeft meer calls nodig | Hogere kosten per geslaagde taak en tragere resultaten voor gebruikers |
De rode draad is dat de verkeerde eenheid wordt gemeten. Tokens per call zie je makkelijk op een dashboard, maar de kosten per geslaagde taak zijn wat je echt betaalt.
Veelgestelde vragen
Wat is tokenoptimalisatie bij LLM-toepassingen?
Tokenoptimalisatie betekent dat je een taalmodel precies de informatie geeft die een taak nodig heeft, op het moment dat het die nodig heeft, en de rest weglaat. Het gaat over prompts, gespreksgeschiedenis, opgehaalde documenten, resultaten van tools en de lengte van de output. Het doel is de laagste kosten per geslaagde taak, niet de kortst mogelijke prompt.
Hoe verlaag je het tokenverbruik van een LLM zonder kwaliteit te verliezen?
Meet eerst waar je tokens naartoe gaan en pak daarna de grootste vermijdbare bron aan: meestal gespreksgeschiedenis, hele documenten of ruwe tooloutput. Vat oudere berichten samen maar houd besluiten exact, haal relevante passages op in plaats van volledige documenten en filter de resultaten van tools. Verander één ding tegelijk en test het op echte taken.
Wat is de invloed van prompt engineering op het tokenverbruik?
Prompt engineering beïnvloedt het tokenverbruik op drie manieren. Een heldere system prompt vermijdt herhaling, en dat telt omdat hij met elke call meegaat. Hij legt de lengte en opmaak van het antwoord vast. En hij laat het model minder raden, zodat er minder nieuwe pogingen nodig zijn. Een goede prompt kan ook meer voorbeelden vragen, dus meet de hele taak.
Verlaagt prompt caching het aantal tokens?
Prompt caching verlaagt het aantal tokens niet. De aanbieder hergebruikt zijn werk voor een identieke prefix en het model ziet nog steeds alle tokens. Een cache hit verlaagt de prijs van het herhaalde deel en kan de verwerkingstijd verkorten. Bij actuele modellen rekenen OpenAI en Anthropic voor lezen uit de cache een tiende van het inputtarief of minder.
Zijn outputtokens duurder dan inputtokens?
Outputtokens zijn meestal duurder dan inputtokens. Op de API-prijslijst van Anthropic kost output in oktober 2026 vijf keer zoveel als input, voor elk actueel Claude-model. Output bepaalt ook het grootste deel van de responstijd, en OpenAI rekent verborgen reasoning tokens af als output. Daarmee is de lengte van de output een van de sterkste kostenhefbomen die je hebt.
Hoe bereken je de kosten per geslaagde taak?
Tel de kosten op van elke call over alle geprobeerde taken, inclusief mislukte taken, herhaalpogingen en vervolgcalls. Deel dat totaal door het aantal taken dat correct is afgerond. Meet dit op een vaste testset met echte taken. Een versie die per call goedkoper is, kan per geslaagde taak toch meer kosten als ze vaker faalt.
Dezelfde principes gelden voor coding agents zoals Claude Code, dat bij elk bericht zijn instructies, je CLAUDE.md en de hele sessie opnieuw meestuurt. De crashcursus tokenoptimalisatie van DataNorth is een praktische training van drie uur voor engineeringteams die dagelijks met Claude Code werken. Engineers leren contexthygiëne, een slanke CLAUDE.md en het kiezen van het juiste model per taak, en oefenen daarna met een echte taak uit hun eigen codebase. Een nulmeting van het gebruik vooraf maakt het effect meetbaar in je eigen cijfers.
