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

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 is het deel dat je ziet en waarover je kunt discussiëren. Het deel dat je niet ziet, is veel groter. Denk aan de ruwe terminaluitvoer die na elk commando wordt ingelezen, de volledige file reads terwijl gericht één functie opzoeken de vraag al had beantwoord, en de responses van externe tool-koppelingen die telkens opnieuw in het werkgeheugen belanden in plaats van in opslag. Daar komt de trage opeenstapeling van tussentijdse state gedurende een lange sessie nog bij, die het model stilletjes voorbij het punt duwt waar de aandacht nog scherp is.

Deze week kwam er een lijst van tien open-source token optimizers langs in mijn feed, allemaal met dezelfde belofte in verschillende vormen. Sommige zijn uitstekend. Sommige zijn dubbel werk. Sommige 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 de vraag niet meer is “welke tool moet ik installeren” maar “welk lek probeer ik te dichten”.

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 betaal je niet per token, maar loop je wel eerder tegen je gebruikslimiet aan en tegen het moment waarop de sessie wordt samengeperst omdat het contextwindow vol zit.

En er is een tweede opbrengst die belangrijker is 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 niet tien tools installeren, maar een week meekijken waar jouw context daadwerkelijk heen gaat. Claude Code laat dat gewoon zien. 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, en wordt de keuze een kwestie van wat past bij jouw situatie, niet van marketingtekst.

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. Beleefd is duur.
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) zou 12 functies hebben ingelezen, geen 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. Het punt van deze indeling is dat je niet drie tools installeert die overlappen terwijl je het lek mist dat je daadwerkelijk geld kost.

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, met de claim dat er geen accuracyverlies is. De realiteit, in mijn tests, is dat de accuracy behouden blijft bij gerichte taken en instort bij taken die echt om hardop redeneren vragen (lange debugsessies, designdiscussies). Ik zou dit gebruiken voor code-generatie-prompts waarbij het antwoord de code zelf is, niet de uitleg. Ik zou het niet gebruiken voor “help me nadenken of ik voor X of Y moet kiezen”.

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. Zelfde idee, ander mechanisme. Het voordeel ten opzichte van Caveman Claude is dat de 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. Kies er één, niet allebei.

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. Het 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. Dit werkt omdat 90% van de git log-output regelmetadata is die de agent niet nodig heeft om een beslissing te nemen, maar toch inleest. RTK gooit de metadata weg voordat die ooit het contextwindow bereikt.

Context Mode. Andere vorm, hetzelfde probleem. In plaats van output te filteren, zet het de volledige ruwe output weg in een lokale SQLite-database en injecteert het alleen een samenvatting in context. Als de agent later beslist dat hij de volledige output nodig heeft, kan hij de 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 hij die database kan bevragen. Het voordeel is dat je niets verliest: je stelt de read alleen uit.

Als je in deze categorie maar één kiest, kies dan degene waarvan je het faalscenario kunt verdragen. RTK gooit stilletjes informatie weg die je misschien had gewild. 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 eerlijk: de agent leest alleen de slice van de codebase op symbolniveau die daadwerkelijk relevant is voor de wijziging, niet het volledige bestand eromheen. Als je werk zwaar leunt op cross-file code reviews, 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 Code Review Graph, maar de abstractie is symbol-first in plaats van graph-first, en de persistentielaag maakt het bij de tweede beurt goedkoper dan bij 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 eerlijke kritiek is dat vector retrieval op code lastiger is dan op tekst: functiesignaturen zijn kort, en semantische gelijkenis tussen twee functies kan misleidend zijn. Ik zou Code Review Graph verkiezen voor taken waarbij call graphs gevolgd moeten worden, en Claude Context voor taken waarbij de vraag is “waar in deze codebase hebben we X gedaan”.

Alle drie lossen ze hetzelfde lek op vanuit een andere invalshoek. Het eerlijke antwoord is om ze op je eigen codebase te testen voordat je er een kiest. Het foute antwoord is om alle drie te installeren.

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. Als je stack Figma, GA4, Sheets of een andere MCP-server bevat die grote gestructureerde JSON teruggeeft, wordt hetzelfde schema bij elke gerelateerde beurt opnieuw in context geduwd. Caching op de koppeling zorgt ervoor dat het model het schema één keer ziet en daarna alleen nog een verwijzing ernaar krijgt.

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

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. Dit is de categorie die ik het meest onderschat vind. CLAUDE.md wordt bij elk gesprek geladen, dus een besparing van 10 KB 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 om te schrijven dan een lange versie.

Wat ik deze week daadwerkelijk zou installeren

Dit is de eerlijke 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. Niet allebei.
• 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 leunt op MCP. Voor de meeste setups is dit een kleiner lek dan de vorige drie.
• Sla de tools voor output-verbositeit over totdat ik de input-lekken heb gedicht. De output van het model met 75% comprimeren levert niets op als de input die het moest lezen twee keer zo lang was als nodig.

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

Het patroon achter dit alles

Het patroon is hetzelfde als waar ik vorige week over schreef voor Google Ads: bouw eerst de gestructureerde bovenstroom en laat de agent daaruit lezen, in plaats van de agent bij elke beurt de ongestructureerde onderstroom te laten scannen. Dat patroon komt in dit artikel op elk oppervlak terug.

Als een tool beweert je tokens te besparen maar niets verandert aan wat het model onderweg leest, lost het niet het lek op dat je daadwerkelijk hebt. Blijf denken in lekken en laat de rest los.

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.