Servertools vallen buiten de standaard tokenmeter
Bijgewerkt: September 1, 2026
De meeste LLM-kostenmodellen hanteren één meter: tokens in, tokens uit, prijs per miljoen. Dat model volstond toen een verzoek uitsluitend tekst genereerde. Het werd ontoereikend op het moment dat server-side tools hun intrede deden.
Web search, web fetch en code-executie draaien op de infrastructuur van de provider, en verschillende tools brengen een vaste toeslag per aanroep in rekening bovenop de geproduceerde tokens. Eén enkele interactieronde kan daardoor dubbel factureren: eenmaal voor de zoekopdrachten zelf, en nogmaals voor de tokens die de zoekresultaten aan de context toevoegen.
Het compounding-effect
De tweede kostenpost wordt stelselmatig over het hoofd gezien. Elk toolresultaat wordt toegevoegd aan de conversatiehistorie, en elke volgende turn verstuurt die complete payload opnieuw als input-tokens. Tien zoekopdrachten vroeg in een agent-run zijn niet slechts tien tariefposten — het zijn tien toeslagen plus de payloads die bij elke volgende stap opnieuw worden belast.
Drie bewezen beheersmaatregelen
- Begrens het aantal toolcalls per run: Een hard plafond op zoekopdrachten per gebruikersverzoek begrenst beide kostenposten gelijktijdig. Workflows die de limiet van tien overschrijden zitten vrijwel altijd in een oneindige lus.
- Kort payloads in vóór contextinjectie: U heeft zelden een volledige webpagina nodig. Door resultaten samen te vatten voordat ze worden toegevoegd, verlaagt u de kosten van elke opeenvolgende turn.
- Cache het stabiele prompt-voorvoegsel: Als de systeemprompt en gereedschapsdefinities constant blijven, elimineert prompt caching de grootste herhalende kostenpost.