blog/claude-code-token-optimalisatie.mdx
Alle notities

19 mei 2026

Claude Code-tokens besparen: tien tools getoetst, vijf lekken die er echt toe doen

Het grootste deel van je Claude Code-verbruik is onzichtbaar: terminal dumps die de agent nooit hergebruikt, volledige file reads terwijl een gerichte symbol lookup volstond, en tool-responses die elke beurt opnieuw in context belanden. Ik heb tien open-source token optimizers getoetst aan de vijf plekken waar tokens in een sessie daadwerkelijk verloren gaan. Niet elke tool is het installeren waard, de meeste setups hebben er hooguit twee of drie nodig. In dit stuk lees je welk lek je eerst dicht, wat dat oplevert op een abonnement en via de API, en welke tools ik zelf zou kiezen.

Jermaya Leijen

Jermaya Leijen

Google Ads-specialist & AI-engineer

Wie Claude Code serieus gebruikt, kent het moment: je bent halverwege een klus en de agent meldt dat het contextwindow bijna vol is, terwijl je zelf maar een paar regels hebt getypt. Dat contextwindow is het werkgeheugen van het model, en tokens zijn de tekstblokjes waarin dat geheugen en je verbruik worden gemeten. Het grootste deel van dat verbruik is onzichtbaar. De output die de agent genereert zie je, en daar kun je over discussiëren. Het deel dat je niet ziet is veel groter. Daar zit de ruwe terminaluitvoer die na elk commando wordt ingelezen. Daar zitten de volledige file reads, terwijl gericht één functie opzoeken de vraag al had beantwoord. En daar zitten de responses van externe tool-koppelingen, die telkens opnieuw in het werkgeheugen belanden in plaats van in opslag. Bij een lange sessie komt daar de opeenstapeling van tussenresultaten nog bij, waardoor het model uiteindelijk voorbij het punt raakt waarop het zijn aandacht scherp houdt.

Deze week kwam er een lijst van tien open-source token optimizers langs in mijn feed, allemaal met dezelfde belofte in een andere verpakking. Sommige zijn uitstekend, andere doen dubbel werk, en weer andere lossen een probleem op dat je niet hebt. Ik heb de tijd genomen om elke tool te toetsen aan de vijf plekken waar tokens in een Claude Code-sessie daadwerkelijk verloren gaan, zodat je begint bij de vraag welk lek je wilt dichten in plaats van bij de vraag welke tool je moet installeren.

Claude Code token economics diagram, raw 200k context window on the left filled with terminal dumps, raw file reads, MCP responses and verbose model output, passing through filter layers labelled sandbox, graph, compress, into an optimized session on the right that uses the same window with much smaller bars and a 60 to 95 percent reduction marker, with a five-card panel below grouping the ten tools by which leak they fix

Wat dit je oplevert, en voor wie

Eerst de nuchtere vraag: waarom zou je hier tijd in steken? Dat hangt af van hoe je betaalt. Werk je via de API, bijvoorbeeld in een team of in geautomatiseerde workflows, dan is elk verspild token direct geld en telt de besparing gewoon op je factuur. Zit je op een Pro- of Max-abonnement, dan gaat er per token niets extra af. Je loopt wel eerder tegen je gebruikslimiet aan, en tegen het moment waarop de sessie wordt samengeperst omdat het contextwindow vol zit.

Er is een tweede opbrengst die zwaarder weegt dan de rekening: een leger contextwindow maakt de agent beter. Een model dat door 40 volgeladen files aan ruis moet waden, mist vaker het detail waar het om ging. Kleinere, relevantere context betekent scherpere antwoorden en minder herstelwerk. Dat effect heb je ook op een vast abonnement.

De realistische eerste stap is dan ook een week meekijken waar jouw context daadwerkelijk heen gaat, en niet meteen tien tools installeren. Claude Code laat het zelf zien: het commando /context geeft een uitsplitsing per categorie, van je CLAUDE.md tot de tools die je MCP-servers hebben geladen. Pas als je je eigen grootste lek kent, heeft de lijst hieronder waarde.

Vijf plekken waar tokens daadwerkelijk verloren gaan

Zodra je kunt aanwijzen waar je tokens naartoe gaan, valt de lijst van tien losse repo's uiteen in vijf categorieën. De keuze wordt dan een kwestie van wat bij jouw situatie past, en niet van wie de mooiste marketingtekst schrijft.

  1. Verbositeit van de output. Stilistische tokens, herhaalde headers, beleefde inleidingen, “Natuurlijk, ik help je daar graag mee”-openingen, herhaalde vragen. Het model is getraind om beleefd te zijn, en die beleefdheid kost tokens.
  2. Terminal- en tool-output spam. Elke npm install, elke git log --oneline -50, elke curl-respons wordt standaard volledig ingelezen. Het meeste is ruis. Een samenvatting van zes regels was genoeg geweest.
  3. Codebase reads. Vraag de agent om “de auth flow te reviewen” in een repo met 4.000 files, en je ziet hem hele files inlezen. Dat is in de praktijk het grootste token-lek dat ik tegenkom. Een tool die op functie- en klasseniveau kan zoeken (symbol-aware, in vaktaal) had 12 functies ingelezen in plaats van 40 files.
  4. MCP-responses. MCP-servers zijn koppelingen waarmee de agent externe systemen als Figma, Sheets, GA4 en GitHub kan aanspreken. Die retourneren JSON die de agent vervolgens bij elke gerelateerde beurt opnieuw inleest. Zonder caching op die koppeling komt hetzelfde schema van 30 KB drie keer in context terecht.
  5. Overbodige project setup. Een CLAUDE.md (het instructiebestand dat Claude Code bij elk gesprek van je project laadt) van 12 KB met copy-paste conventiedocumentatie. Als 80% ervan “gebruik 2-space indentation”-achtige opvulling is en 20% de daadwerkelijk essentiële projectcontext, betaal je bij elke beurt voor de verkeerde 80%.

Elk van de tien tools hieronder richt zich op een van deze categorieën. Geen enkele lost er meer dan twee op. Deze indeling voorkomt dat je drie tools installeert die elkaar overlappen terwijl het lek dat je daadwerkelijk geld kost open blijft staan.

Categorie 1, verbositeit van de output, twee tools

Caveman Claude. Een prompt-interventie die het model in gecomprimeerd telegramstijl-Engels laat praten. De belofte is 75% reductie van output-tokens, zonder verlies aan nauwkeurigheid. In mijn tests blijft die nauwkeurigheid inderdaad overeind bij gerichte taken, en stort ze in bij taken die echt om hardop redeneren vragen: lange debugsessies, designdiscussies. Ik zou dit inzetten voor code-generatieprompts waarbij het antwoord de code zelf is. Voor “help me nadenken of ik voor X of Y moet kiezen” zou ik ervan afblijven.

Claude Token Efficient. Eén CLAUDE.md-bestand dat je in je repo zet en dat beknoptheid afdwingt: geen inleidingen, geen samenvattingen aan het eind. Hetzelfde idee met een ander mechanisme. Het voordeel ten opzichte van Caveman Claude is dat deze tool het Engels van het model met rust laat en alleen de overbodige plichtplegingen onderdrukt. Het voordeel van Caveman is dat het agressiever snoeit. Ze overlappen sterk, dus kies er één.

Categorie 2, terminaloutput-spam, twee tools

RTK, Rust Token Killer. Een snelle lokale proxy die tussen je shell en de agent zit en de ruwe terminaluitvoer filtert. Hij stript opmaakcodes, voegt repetitieve regels samen en vat npm install-ruis samen tot één statusregel. Geen dependencies, geen Python-runtime nodig. Beweerde reductie van 60 tot 90% bij echte terminalsessies. Het werkt omdat zo'n 90% van de git log-output regelmetadata is die de agent niet nodig heeft om een beslissing te nemen, maar toch inleest. RTK gooit die metadata weg voordat ze het contextwindow bereikt.

Context Mode. Deze tool pakt hetzelfde probleem anders aan. In plaats van output te filteren, zet hij de volledige ruwe output weg in een lokale SQLite-database en injecteert hij alleen een samenvatting in context. Beslist de agent later dat hij de volledige output nodig heeft, dan kan hij die database alsnog bevragen. Beweerde 98% contextreductie bij sessies die zwaar leunen op logs en GitHub-fetches. Het nadeel is dat de agent moet onthouden dat die database er is. Het voordeel is dat je niets kwijtraakt: je stelt de read alleen uit.

Kies je er in deze categorie één, kies dan degene waarvan je het faalscenario kunt verdragen. RTK gooit stilletjes informatie weg die je misschien had willen hebben. Context Mode houdt alles bij, maar voegt een tool toe die de agent moet onthouden te gebruiken.

Categorie 3, codebase reads, drie tools

Dit is de categorie waar ik zelf de grootste verspilling zie. Drie tools bevinden zich hier, elk met een andere aanpak.

Code Review Graph. Bouwt met tree-sitter (een parser die code ontleedt tot een structuur van functies en klassen) een graaf van je repo en laat de agent daarin navigeren in plaats van bestanden te lezen. Voor codereviewtaken op een monorepo is er een beweerde 49x tokenreductie. Het mechanisme is navolgbaar: de agent leest op symbolniveau alleen het deel van de codebase dat voor de wijziging relevant is, in plaats van het volledige bestand eromheen. Leunt jouw werk zwaar op cross-file code reviews, dan is dit de tool met het grootste hefboomeffect op de lijst.

Token Savior. Navigeert door code op basis van symbols in plaats van files. De persistente geheugenlaag betekent dat de agent de symbolmap niet elke sessie opnieuw hoeft op te bouwen. Beweerde 97% reductie bij codenavigatie. Het uitgangspunt is hetzelfde als bij Code Review Graph, alleen is de abstractie hier symbol-first in plaats van graph-first, en maakt de persistentielaag de tweede beurt goedkoper dan de eerste.

Claude Context, Zilliz. Hybride vector search over de codebase via een MCP-server: zoeken op betekenis in plaats van op letterlijke tekst. Functioneel is dit RAG voor code, retrieval waarbij de agent alleen de relevante stukken aangereikt krijgt. Beweerde 40% kostenreductie met de hele codebase als effectieve context. De kritiek die je erbij moet houden: vector retrieval op code is lastiger dan op tekst. Functiesignaturen zijn kort, en semantische gelijkenis tussen twee functies kan misleiden. Ik zou Code Review Graph verkiezen voor taken waarbij call graphs gevolgd moeten worden, en Claude Context voor de vraag “waar in deze codebase hebben we X gedaan”.

Alle drie lossen ze hetzelfde lek op vanuit een andere invalshoek. Test ze op je eigen codebase voordat je er een kiest, en installeer ze zeker niet alle drie.

Categorie 4, MCP-responses, twee tools

Token Optimizer MCP. Voegt agressieve caching en compressie toe op de MCP-koppellaag. Beweerde 95% reductie door responses over beurten heen te dedupliceren. Bevat je stack Figma, GA4, Sheets of een andere MCP-server die grote gestructureerde JSON teruggeeft, dan wordt hetzelfde schema bij elke gerelateerde beurt opnieuw in context geduwd. Caching op de koppeling zorgt ervoor dat het model dat schema één keer ziet en daarna alleen nog een verwijzing krijgt.

Token Optimizer. Een algemenere versie die jaagt op ghost tokens: de onzichtbare context die zich opstapelt uit tool-boilerplate, systeemberichten en herhaalde headers. Minder gericht dan de MCP-variant, maar nuttig voor sessies die niet zwaar op MCP leunen.

Categorie 5, project setup, één tool

Claude Token Optimizer. Setup-prompts die naar je project kijken en een veel korter CLAUDE.md produceren. De claim is 90% tokenbesparing op de projectguide zelf, met een typische reductie van 11K naar 1,3K tokens. Dit is de categorie die ik het meest onderschat vind. CLAUDE.md wordt bij elk gesprek geladen, dus bijna 10K aan bespaarde tokens stapelt zich op over honderden sessies per jaar. Het nadeel is dat een beknopte CLAUDE.md wel raak moet zijn: elke regel moet ertoe doen, en dat kost meer denkwerk dan een lange versie schrijven.

Wat ik deze week daadwerkelijk zou installeren

Dit is de stack die ik zou kiezen als ik morgen met een schone Claude Code-setup zou beginnen.

  • Eén tool voor codebase reads, omdat dat het grootste lek is bij echt werk. Ik zou Code Review Graph kiezen voor de codebases die ik het vaakst review, en Claude Context alleen toevoegen als ik merk dat ik de codebase vaker semantisch doorzoek dan structureel doorloop.
  • Eén tool voor terminaloutput: RTK als snelheid me interesseert, Context Mode als ik geen informatie wil verliezen. Eén van de twee volstaat.
  • Eén beknopte CLAUDE.md, idealiter handgeschreven of gestript met Claude Token Optimizer, waarbij elke regel zijn plek verdient. Dit betaalt zich elke sessie opnieuw uit.
  • Optioneel een cache op de MCP-laag, alleen als mijn workflow daadwerkelijk zwaar op MCP leunt. Voor de meeste setups is dit een kleiner lek dan de vorige drie.
  • Sla de tools voor output-verbositeit over totdat de input-lekken dicht zijn. De output van het model met 75% comprimeren levert niets op zolang de input die het moest lezen twee keer zo lang was als nodig.

De volgorde is belangrijk. De meeste adviezen over token-optimalisatie beginnen bij “laat het model minder praten”, en dat is het kleinste van de vijf lekken. Het grootste is wat het model onderweg leest. Pak de inputkant dus eerst aan.

Het patroon achter dit alles

Het patroon is hetzelfde als waar ik vorige week over schreef voor Google Ads: bouw eerst een gestructureerde laag en laat de agent daaruit lezen, in plaats van hem bij elke beurt de ruwe data te laten doorzoeken. Dat patroon komt in dit artikel op elke plek terug.

PlekRuwe dataGestructureerde laag
CodebaseHele files inlezenGraaf of symbolmap op functieniveau
TerminalRuwe output volledig in contextSamenvatting, ruwe data in opslag
Externe tools (MCP)Zelfde JSON elke beurt opnieuwCache met verwijzing
ProjectcontextCLAUDE.md van 12 KBBeknopte guide waarin elke regel telt
Google AdsAgent doorzoekt losse ruwe dataKnowledge base van de catalogus

Belooft een tool je tokens te besparen zonder iets te veranderen aan wat het model onderweg leest, dan dicht ze het lek niet dat je daadwerkelijk hebt. Kijk dus eerst naar je eigen uitsplitsing en pas daarna naar de lijst.

Wil je een tweede paar ogen op je Claude Code-setup, stuur me dan een bericht. Mail info@jermayads.nl of gebruik jermayads.nl/contact.

Jermaya Leijen

Over de auteur

Jermaya Leijen

Hoi, ik ben Jermaya. Sinds 2013 zit ik in Google Ads en de laatste jaren bouw ik AI-agents die het repeterende werk overnemen. Hier schrijf ik op wat ik in de praktijk tegenkom: wat werkt, wat niet, en hoe ik het zelf zou aanpakken. Een vraag of gewoon even sparren? Ik lees alles. Bekijk mijn werk of stuur me een bericht.