Claude Token Limits: context rot, geen harde limiet

Claude Token Limits: context rot, geen harde limiet

De rekening die me uiteindelijk deed nadenken was $ 73,41 – voor een enkele dinsdagmiddag van Claude Code. Ik had niets ongewoons gedaan. Eén functietak. Een handvol bestandsbewerkingen. Wat debuggen. Het soort sessie dat me acht of negen dollar had moeten kosten.

Ik opende het kostenoverzicht in de verwachting een weggelopen agent of een vergeten lus aan te treffen. Wat ik vond was nog erger. Bij elk bericht dat ik die middag had verzonden, werd de hele gespreksgeschiedenis opnieuw gelezen. Niet samengevat. Niet overgeslagen naar de relevante onderdelen. Herlees het. Tegen bericht dertig verwerkte het model meer tokens om te begrijpen wat we al hadden besproken dan om het volgende antwoord te genereren.

Toen besefte ik iets waarvan ik denk dat de meeste mensen die Claude gebruiken (inclusief veel doorgewinterde ontwikkelaars) volledig achterlijk zijn. De ‘tokenlimiet’ waar mensen over klagen, is geen limiet die Anthropic oplegt om je te wurgen. Het is geen factureringstruc. Het is niet eens echt een grens in de manier waarop de meesten van ons over grenzen denken.

Het is context rot. En als je eenmaal begrijpt wat er feitelijk gebeurt tijdens een Claude-sessie, zijn de strategieën om dit op te lossen niet langer willekeurige tips die je op Twitter leest, maar beginnen ze een samenhangend systeem te worden.

Ik gebruik dat systeem nu ongeveer acht weken voor vier verschillende projecten. Mijn gemiddelde dagelijkse kosten daalden met ongeveer 60%. De uitvoerkwaliteit ging omhoog, niet omlaag. En het meest contra-intuïtieve deel – datgene waar ik het langst over deed om het te accepteren – is dat bijna geen van de overwinningen voortkwam uit het ‘minder gebruiken van Claude’. Ze zijn afkomstig van het gebruik van Claude cleaner.

Dit is de volledige uitsplitsing. De wiskunde. Het onderzoek. De exacte slash-commando's die ik gebruik, wanneer ik ze gebruik, en de commando's die ik moest afleren. Aan het einde kun je elke Claude-sessie bekijken en binnen dertig seconden zien of deze gezond is of op het punt staat tokens te gaan bloeden.

De wiskunde die niemand je laat zien

Dit is wat elke Claude-tutorial ronddanst, maar nooit helemaal ronduit zegt: elke keer dat u een nieuw bericht verzendt, verwerkt het model het hele gesprek tot dat punt opnieuw. Systeemprompt. Elk bestand waarnaar u verwijst. Elke gereedschapsoproep. Elke assistent-reactie. Alles, elke beurt.

Dat klinkt duur. Het is.

Ik zal je laten zien hoe het er daadwerkelijk uitziet, met realistische cijfers. Stel dat elke berichtuitwisseling (uw prompt + het antwoord van Claude + de uitvoer van een tool) ongeveer 500 tokens aan het gesprek toevoegt. Bescheiden. Redelijk. Waarschijnlijk onder-geteld als je met code werkt.

Kijk naar bericht 10 versus bericht 1. Prompt van dezelfde grootte. Tien keer de kosten. Bij bericht 30 heb je al meer cumulatieve tokens verbrand dan de eerste vijftien samen. Bij bericht 100 heeft het model het gesprek zo vaak herlezen dat 98,5% van de tokens die voor die sessie zijn verwerkt, zijn besteed aan het opnieuw begrijpen van de oude context en niet aan het genereren van nieuwe uitvoer.

Dit is geen Claude-probleem. Het is een transformatorarchitectuureigenschap. Elke frontier LLM werkt op deze manier. Maar Claude maakt de kosten zichtbaar op een manier die de meeste mensen pas merken als de rekening arriveert.

En hier wordt het nog erger, want de kosten zijn niet het enige dat de kosten verergert.

Hoe contextrot er eigenlijk uitziet

In 2025 publiceerde Chroma onderzoek dat stilletjes veel aannames over het gedrag van modellen met een lange context doorbrak. Ze testten 18 frontier LLM's – inclusief Claude – op ophaaltaken met verschillende invoerlengtes. De conventionele wijsheid zei: groter contextvenster = betere prestaties, punt.

De gegevens zeiden iets anders.

Elk afzonderlijk model presteerde slechter naarmate de invoerlengte groter werd. Sommige bleven stabiel op een nauwkeurigheid van 95% en daalden vervolgens naar ongeveer 60% zodra de invoer een bepaalde drempel overschreed. De daling verliep niet geleidelijk. Het was een klif. En het gebeurde niet binnen de limiet van het op de markt gebrachte contextvenster – het gebeurde al lang daarvoor, vaak rond de 200.000 – 300.000 tokens, zelfs op modellen die reclame maakten voor 1 miljoen context.

Het mechanisme is iets dat onderzoekers het lost-in-the-middle-effect noemen. De aandacht van de transformator is U-vormig. Het model houdt goed rekening met het begin van de context (de systeemprompt, uw initiële installatie) en tot het einde (uw meest recente bericht). Het midden? Steeds waziger. Uit een onderzoek van Stanford uit 2023 bleek dat met slechts twintig opgehaalde documenten – ongeveer 4.000 tokens – de nauwkeurigheid van QA-taken daalde van 70-75% naar 55-60%. En dat is voordat u de gespreksgeschiedenis met meerdere beurten erbovenop toevoegt.

Koppel dat aan de kostencurve waar we zojuist naar hebben gekeken, en je krijgt een echt beeld van wat er gebeurt in een lange Claude-sessie:

• Tokens 1 tot en met ~50k: model is scherp, nauwkeurig en relatief goedkoop per beurt
• Tokens 50k tot ~200k: de kosten stijgen snel, de nauwkeurigheid begint af te nemen, hallucinaties sluipen binnen
• Tokens 200k+: u betaalt premiumtarieven voor verminderde output

Dit is de reden waarom "gewoon doorgaan in dezelfde chat" de duurste gewoonte is die je kunt hebben met Claude. U betaalt niet alleen meer, u betaalt meer voor slechter.

De oplossing is niet om te beperken hoeveel u Claude gebruikt. Het gaat erom dat u onderkent dat uw gesprek een goede halfwaardetijd heeft, en dat u er doelbewust mee omgaat. Contexthygiëne, niet smoren.

Ik zal je laten zien hoe ik dat precies doe.

Negen tips die mijn algemene Claude-kosten halveren

Dit zijn de gewoonten die ik gebruik in de reguliere Claude-apps: claude.ai, mobiel, de API. Nog geen Claude Code. Wij komen er wel.

1. Bewerken en opnieuw genereren in plaats van vervolgcorrecties te schrijven

Deze voelt achteraf gezien voor de hand en ik heb hem maandenlang gemist. Wanneer Claude iets verkeerd doet, was mijn instinct om een ​​vervolgbericht te schrijven: "Eigenlijk bedoelde ik X, niet Y." Dat vervolg zorgt voor twee nieuwe wendingen in het gesprek die bij elk toekomstig bericht opnieuw zullen worden gelezen.

De schonere zet is om de oorspronkelijke prompt te bewerken en opnieuw te genereren. Zelfde uitkomst. Geen extra contextgewicht. Als je dit vijf keer doet gedurende een lange sessie, heb je misschien 3.000 tot 5.000 tokens aan permanente overhead bespaard: elk bericht daarna.

2. Verzamel meerdere verzoeken in één prompt

Drie berichten, waarin elk één ding wordt gevraagd, kosten grofweg drie keer de contextoverhead van één bericht waarin drie dingen worden gevraagd. Het model is echt goed in het verwerken van aanwijzingen uit meerdere delen. Gebruik dat.

In plaats van:

• "Schrijf het API-eindpunt."
• "Schrijf nu de test."
• "Schrijf nu de README-sectie."

Verzenden: "Schrijf het API-eindpunt, de bijbehorende test en een README-sectie waarin het eindpunt wordt uitgelegd. Gebruik H2-koppen voor elk."

Je krijgt dezelfde kwaliteit. Eén keer contextkosten. Dit is de grootste gedragsverandering die ik heb doorgevoerd en het is waarschijnlijk goed voor een derde van mijn spaargeld.

3. Start elke 15-20 berichten nieuwe chats

Ik behandel 15-20 berichten als het zachte plafond voor een enkel gesprek. Daarna beginnen zowel de kosten als de nauwkeurigheid merkbaar te dalen. Als ik erop raak, doe ik een opzettelijke overdracht:

"Vat alles samen wat we in dit gesprek hebben vastgesteld: het doel, de genomen beslissingen, de aangeraakte bestanden, de huidige blokkeringen en wat de toekomst biedt. Formatteer het als een korte samenvatting die ik in een nieuwe sessie kan plakken."

Dan open ik een nieuwe chat en plak die samenvatting als eerste bericht. Nieuwe sessie, dezelfde context, fractie van het symbolische gewicht.

4. Kies het juiste model voor de taak

Huidige opstelling van Claude – Haiku 4.5, Sonnet 4.6 en Opus 4.7 – is geen ‘goed, beter, beste’-hiërarchie. Het is een spectrum van snelheid versus diepte, en het gebruik van Opus voor wat Haiku aankan is een stille geldkuil.

Een grove rubriek:

• Haiku 4.5 ($1/$5 per miljoen tokens): classificatie, routering, samenvatting, eenvoudige zoekopdrachten, lijmtaken. Alles waarbij je zou zeggen: "Dit is vervelend, maar niet moeilijk."
• Sonnet 4.6 ($3/$15): uw standaard. Coderen, schrijven, analyseren, redeneren in meerdere stappen. Volgens BenchLM's 2026-nummers zit Sonnet 4.6 binnen 1,2 punten van Opus op SWE-bench tegen 60% van de kosten.
• Opus 4.7 ($5/$25): echt harde redeneringen, nieuwe problemen, dubbelzinnige specificaties, de dingen waarvoor je het model nodig hebt om te denken, niet alleen om te produceren.

De meeste mensen die ik bekijk via het delen van Discord-schermen gebruiken standaard Opus voor taken die Sonnet zou verpletteren. Dat is een premie van 67% voor output die in veel gevallen functioneel identiek is.

5. Houd uitgebreid nadenken standaard uit

Uitgebreid nadenken genereert interne redeneringstokens voordat het model zijn zichtbare output produceert. Handig bij lastige problemen. Duur voor al het andere, omdat denkende tokens worden gefactureerd tegen uitvoertarieven — en de uitvoer is 5x de kosten van invoer op Opus en Sonnet.

Een reactie met 500 zichtbare tokens en 2.000 denktokens kost ongeveer 5x wat hetzelfde antwoord zou kosten zonder na te denken. Dat is de werkelijke vermenigvuldiger. Voor de meeste taken – opstellen, samenvatten, refactoring – betekent uitgebreid nadenken een hogere prijs voor marginale nauwkeurigheidswinst.

Ik laat het uit en zet het bewust aan als de taak dit vereist. Architectuurbeslissingen. Debuggen van vreemde bugs. Alles waarbij een verkeerd antwoord mij realtime stroomafwaarts kost.

6. Converteer bestanden naar Markdown voordat u ze uploadt

Een PDF van 30 pagina's kan meer dan 40.000 tokens bevatten. Dezelfde inhoud als de schone Markdown past vaak in 8.000–12.000. PDF's bevatten een enorme hoeveelheid opmaak en metagegevens die niets toevoegen aan wat het model kan extraheren. Hetzelfde geldt voor HTML: de helft van de tokens bestaat uit tag-soep.

Als ik tijdens een sessie herhaaldelijk naar een document ga verwijzen, converteer ik het één keer met een tool als pdftotext of markitdown en upload ik de Markdown-versie. De nauwkeurigheid gaat zelfs omhoog omdat het model geen lay-outruis bestrijdt.

7. Gebruik Projecten om herhaalde documenten in de cache op te slaan

Als u in veel sessies dezelfde documentatie, codebase-context of referentiemateriaal tegenkomt, laat Projecten dat materiaal in de projectkennisbank leven in plaats van dat het opnieuw in elke chat wordt geplakt. Het in de cache opgeslagen gedeelte wordt efficiënt opnieuw geïnjecteerd. Hetzelfde idee als prompt caching op de API – cache-lezingen kosten ongeveer 10% van de standaard invoerprijs.

Ik heb een "Mejba's Codebase Context"-project dat mijn coderingsstandaarden, architecturale patronen en enkele tientallen referentiebestanden bevat. Elke codegerelateerde chat vindt binnen dat project plaats. Het model komt binnen en weet al hoe ik werk.

8. De truc voor het resetten van een sessie van 5 uur

De gebruiksperioden van Claude.ai worden elke vijf uur gereset en de timer begint bij uw eerste bericht van een sessie. Als u om 8.00 uur wakker wordt en uw eerste bericht een echte werksessie is, begint het volgende resetvenster. Als je om zeven uur 's ochtends een klein wegwerpberichtje afvuurt - 'goedemorgen' of wat dan ook - verschuift de reset en kun je twee volledige werksessies in je dag inpassen in plaats van één.

Kleinzielig? Misschien. Maar in de weken waarin ik hard aan het malen ben, heeft het mij meer dan eens een extra werkvenster opgeleverd.

9. Werk buiten de spits als je kunt

Anthropic heeft soms tijdens piekuren de reacties afgeremd of de gevolgtrekking vertraagd. Ik heb hier geen harde gegevens over – Anthropic publiceert deze niet – maar het anekdotische patroon in mijn eigen sessies is duidelijk. Sessies in de vroege ochtend en in de late avond voelen vlotter aan. Middagsessies tijdens kantooruren in de VS voelen soms traag aan.

Als uw werk het toelaat, plan dan zwaar Claude-werk buiten het Pacific-venster van 10.00 tot 16.00 uur. In het slechtste geval krijg je dezelfde snelheid. In het beste geval ben je 20% sneller klaar.

Alleen al die negen tips zullen de naald in beweging brengen. Maar als u Claude Code gebruikt, is er een aparte set zetten die er meer toe doen, omdat Claude Code een ander kostenprofiel heeft en een andere set tools om dit te beheren.

Acht Claude Code-tips die belangrijker zijn dan de algemene

Claude Code is waar tokenkosten echt eng worden als je ze niet beheert, omdat de contextoppervlakte groter is. CLAUDE.md wordt bij elke beurt geïnjecteerd. MCP-toolschema's worden bij elke beurt geïnjecteerd. Bestandslezingen stapelen zich op. Aanroepen van subagenten retourneren hun volledige uitvoer naar uw hoofdcontext. De samenstelling is reëel.

Dit zijn de acht gewoonten die mijn Claude Code-rekeningen hebben veranderd van 'Ik moet hier waarschijnlijk naar kijken' in 'saaie achtergrondkosten'.

1. Voer /context vroeg uit — voordat u met het werk begint

Het meest bruikbare commando dat Claude Code heeft geleverd, en waarschijnlijk het commando dat de meeste mensen niet gebruiken. /context toont u een gekleurd raster van uw huidige contextgebruik: wat er is geladen, hoeveel elk stuk verbruikt, waar het budget naartoe gaat.

Voer het uit als het eerste wat u doet in een nieuwe sessie. Niet nadat je een uur hebt gewerkt. Het eerste.

Wat je vaak tegenkomt is zoiets als dit:

System prompt: 4,200 tokens
CLAUDE.md: 18,400 tokens
MCP tool schemas: 47,300 tokens
Loaded files: 0 tokens
---
Total: 69,900 tokens (35% of 200k context window)

Dat is 35% van uw budget voordat u ook maar één instructie heeft getypt. Als uw CLAUDE.md opgeblazen is en u vier MCP-servers geladen heeft, kunt u al op 22%-40% zitten voordat de sessie zelfs maar begint. Volgens MCP-contextanalyse van Scott Spence heeft één ontwikkelaar alleen al zijn MCP-tools gemeten en meer dan 66.000 tokens aan contextoverhead verbruikt.

Als u dit nummer kent, verandert de manier waarop u werkt. U wordt niet langer verrast door symbolische rekeningen.

2. Koppel de MCP-servers los die u niet actief gebruikt

Elke verbonden MCP-server injecteert zijn volledige toolschema – elke toolnaam, elke beschrijving, elke parameterdefinitie – in de context van elk afzonderlijk bericht. Niet één keer bij het opstarten. Elk. Draai.

Als u een MCP-server met 20 tools heeft en deze niet gebruikt voor de huidige taak, betaalt u hoe dan ook voor het bijbehorende schema voor elk bericht. Koppel het los. U kunt met één opdracht opnieuw verbinding maken wanneer u deze daadwerkelijk nodig heeft. De besparingen kunnen enorm zijn: gemakkelijk 15.000 tot 40.000 tokens per sessie voor iemand met meerdere servers geladen.

Het Anthropic-team heeft gewerkt aan lazy-loading toolschema's (laadt alleen het schema voor een tool wanneer deze daadwerkelijk wordt aangeroepen) en vanaf geavanceerd toolgebruik is er enige vooruitgang geboekt. Maar de veilige veronderstelling, totdat je het tegendeel hebt geverifieerd in je eigen configuratie met /context, is dat verbonden MCP = verbruikte tokens.

3. Vervang MCP-servers waar mogelijk door CLI's

Het kostte me een tijdje om dit te internaliseren. MCP-servers zijn handig maar uitgebreid. Een CLI-tool die hetzelfde doet (aangeroepen via de bash-tool van Claude Code) gebruikt doorgaans veel minder context, omdat je alleen maar de opdracht verzendt en de uitvoer parseert, en geen volledige schemadefinitie laadt.

Ik heb drie MCP-servers vervangen door gelijkwaardige CLI-workflows. De symbolische besparingen bedroegen gemiddeld ongeveer 35% -40% per sessie. De wisselwerking: iets meer wrijving bij het aanroepen van de tool, omdat Claude de opdracht moet construeren in plaats van een getypte functie aan te roepen. Voor mij is die afweging negen van de tien keer de moeite waard.

Als je de basisprincipes al hebt behandeld, dan loopt mijn diepere gids voor Claude Code-tokenbeheer door de specifieke MCP-naar-CLI-swaps die mij het meeste hebben opgeleverd.

4. Gebruik /clear tussen niet-gerelateerde taken

/clear wist de gespreksgeschiedenis en begint opnieuw. De meeste mensen gebruiken het als een 'opnieuw beginnen'-knop als er iets misgaat. Dat is niet het meest waardevolle gebruik.

Het gebruik met de hoogste waarde vindt plaats tussen niet-gerelateerde taken. U voltooit het herstructureren van de auth-module. Het volgende op uw lijst is het bijwerken van de README. Er is geen overlap. Het auth-gesprek draagt ​​niets bij aan de README-taak, maar het zou bij elke README-beurt opnieuw worden gelezen als u het niet wist.

Druk op /clear. Start de README-taak opnieuw. Je hebt jezelf zojuist duizenden tokens met irrelevante context bespaard, plus je hebt de verloren-in-het-midden nauwkeurigheidsverslechtering gereset die op het punt stond je te bijten.

5. /compact proactief bij ~50% contextgebruik

/compact vat uw gespreksgeschiedenis samen en vervangt het volledige transcript door een verkorte versie. De officiële richtlijnen zeggen dat je het moet gebruiken als de context groter is dan 80%. Ik gebruik het eerder - meestal rond de 50%.

Waarom eerder? Want tegen de tijd dat je 80% bereikt, bevind je je al in de context-rot-gevarenzone. De nauwkeurigheid is al aan het afnemen. Verdichten op 80% betekent schadebeperking. Verdichten op 50% is onderhoud.

U kunt instructies doorgeven aan /compact om te sturen wat het behoudt: /compact focus on the auth module decisions and current test failures. Gebruik dat. De standaardsamenvatting is in de meeste gevallen prima, maar voor complexe sessies maakt het vertellen wat je moet bewaren een echt verschil.

Als /compact een fout maakt – iets belangrijks laat vallen – kunt u met /resume terugspoelen naar een vorige sessiestatus. Wees niet bang voor /compact vanwege fouten; het terugspoelpad is echt.

6. Sessieoverdracht bij ~60% — volledige samenvatting, nieuwe start

Voor echt lange werksessies is /compact niet altijd voldoende. Er is een punt waarop het gesprek zoveel beslissingen, bestandsverwijzingen en contextverschuivingen heeft opgeleverd dat zelfs een samenvatting het niet volledig kan ontwarren.

Wanneer ik ~60% gebruik maak van iets complexs, voer ik een handmatige overdracht uit:

"Genereer een compleet overdrachtsdocument voor deze sessie. Voeg toe: het doel, alle gemaakte architecturale beslissingen, alle gewijzigde bestanden, de huidige status van het werk, blokkers en de volgende 3-5 acties. Formatteer het als een Markdown-briefing die ik in een nieuwe sessie kan plakken."

Vervolgens sla ik dat overzicht op, voer /clear uit en plak het als het openingsbericht van een nieuwe sessie. De nieuwe sessie komt binnen met volledige context met misschien 8.000 tokens overhead in plaats van 120.000.

7. Gebruik subagenten voor zware taken

Subagenten worden in afzonderlijke contextvensters uitgevoerd. Als ik een subagent stuur om "de Stripe webhook-integratiepatronen te onderzoeken en terug te rapporteren met drie opties", gebeurt al dat onderzoek (elke documentpagina, elk voorbeeld, elke doodlopende verkenning) in de context van de subagent, niet in de mijne. Ik begrijp de samenvatting. Het onderzoeksgewicht blijft buiten mijn hoofdsessie.

Dit is een van de grootste ontgrendelingen die Claude Code biedt. Voor elke taak die veel lezen, verkennen of onderzoek met zich meebrengt voordat een eindproduct wordt geproduceerd, zijn subagenten bijna altijd het juiste antwoord.

8. Schone installatie: CLAUDE.md onder 200 regels, settings.json afgestemd

De grootste constante overhead in elke Claude Code-sessie is CLAUDE.md. Het wordt bij elke beurt geïnjecteerd. Als uw bericht uit 600 regels bestaat, betaalt u voor de rest van het project voor die 600 regels voor elk bericht van elke sessie.

De analyse van de Prompt Shelf raadt aan om CLAUDE.md onder de 200 regels te houden. Ik zou onder de 150 pleiten als je ermee kunt zwaaien. Vijf regels. Drie bestandsaanwijzers. De vorm van het project, niet de documentatie ervan.

Combineer dat met een goed afgestelde settings.json:

• autocompact_threshold ingesteld op de trigger van uw voorkeur (ik gebruik 0,65)
• deny-regels voor node_modules, .next/cache, dist, build en alle andere mappen waarvan u nooit wilt dat Claude deze in context leest

Deze opzet alleen al – lean CLAUDE.md plus agressieve weigeringsregels – verplaatste mijn basissessie-overhead van ongeveer 35.000 tokens naar ongeveer 9.000.

Dat is het dagelijkse werk van kostenmanagement. Maar boven al deze tactieken zit een laag die, als je die eenmaal hebt toegepast, ervoor zorgt dat de meeste ervan automatisch aanvoelen.

Vier samenwerkingsgewoonten die zich in de loop van de tijd versterken

Bovenstaande tips zijn tactisch. Deze vier zijn structureel. Ze veranderen de vorm van hoe u met Claude werkt, niet alleen de parameters.

1. Wijs Claude naar een schone, speciale map

Dit klinkt triviaal. Dat is het niet. Als je Claude Code naar de root van een monorepo van 40.000 bestanden verwijst, zelfs met deny-regels, lok je ruis uit. Claude leest af en toe in mappen die u niet bedoelde. Tooloproepen leveren grotere ladingen op dan u had verwacht. Zoekopdrachten zullen irrelevante overeenkomsten opleveren.

De schone versie: maak een werkmap voor de specifieke taak. Symlink alleen in wat nodig is. Wijs Claude naar die map. Nu werkt elke lezing, elke zoekopdracht, elke klodder op een gericht oppervlak.

2. Lokale geheugenbestanden: instructions.md + memory.md

CLAUDE.md is globaal voor het project. Maar voor langdurig werk ben ik begonnen met het bijhouden van twee extra bestanden in de werkmap:

• instructions.md: regels, toon, opmaakvoorkeuren, "doe altijd X, doe nooit Y." Zelden bijgewerkt. Dit is hoe ik graag werk.
• memory.md: projectspecifieke feiten, genomen beslissingen, huidige status, wat nu. Aan het einde van elke sessie bijgewerkt.

Aan het begin van elke nieuwe sessie is mijn openingsprompt ongeveer: "Lees instructies.md en memory.md, wacht dan op mijn volgende bericht." Totale kosten: ~2.000–4.000 tokens. Wat ik terugkrijg: een Claude die binnenkomt en al weet wat de projectstatus is, wat de conventies zijn en waar we het laatst aan hebben gewerkt. Geen heruitleg. Geen herbeslissing. Het geheugen overleeft sessiegrenzen.

Dit patroon is samengesteld. Drie weken na aanvang van een project doet uw memory.md het werk waarvoor anders een gesprek van 50 berichten nodig zou zijn om het opnieuw tot stand te brengen.

3. Onderzoek naar andere tools overbrengen

Niet alles wat Claude kan doen, is iets dat Claude zou moeten doen. Uitgebreid webonderzoek, scraping, vergelijking van meerdere bronnen: deze taken verbruiken enorme hoeveelheden context voor resultaten die andere tools goedkoper produceren.

Ik leid nu het meeste onderzoekswerk door Perplexity of Gemini en voer de gedestilleerde output vervolgens terug naar Claude voor de daadwerkelijke bouwwerkzaamheden. Een onderzoekssessie van 40.000 tokens wordt een opdracht van 3.000 tokens. Claude richt zich op waar het het beste in is: code, gestructureerde uitvoer, technisch redeneren, in plaats van het doorspitten van tokens voor taken waarvoor dit niet het optimale hulpmiddel is.

Dit is een van die bewegingen die ketters aanvoelt totdat je het probeert. Dan voelt het gewoon vanzelfsprekend.

4. Codeer herhaalbare taken als vaardigheden

Alles wat ik meer dan drie keer doe in verschillende sessies (codebeoordeling, inhoudscontroles, checklists voor implementatie, beveiligingsbeoordelingen) wordt gecodeerd als een Claude-vaardigheid, waarbij het proces vooraf is geladen. De vaardigheid heeft zijn eigen minimale context: de stappen, de standaarden, het uitvoerformaat.

In plaats van het proces elke keer uit te leggen, activeer ik de vaardigheid. De vaardigheid weet wat te doen. Mijn hoofdcontext blijft licht. Ik krijg consistente output. En de vaardigheid wordt steeds beter: elke sessie die een betere aanpak naar voren brengt, wordt teruggeplooid in de vaardigheidsdefinitie.

Dit is waar het systeem samengestelde rendementen krijgt. De eerste keer dat u een vaardigheid opbouwt, is het een investering van 30 minuten voor marginale besparingen. De honderdste keer dat u het gebruikt, bespaart het u tien minuten en 20.000 tokens per aanroep, en levert het bovendien een betere, consistentere uitvoer op dan ad-hocinstructies ooit hebben gedaan.

Real Talk: wat ik verkeerd heb aan dit alles

Ik wil ergens eerlijk over zijn. De eerste zes maanden gebruikte ik Claude serieus, ik behandelde dit allemaal als boekhouding. Kostenoptimalisatie. Penny-knijpen. De saaie kant van het gebruik van AI-gereedschappen.

Dat kader was verkeerd, en het kostte me echt geld en echte uitvoerkwaliteit voordat ik het doorhad.

Contexthygiëne is geen boekhoudkundige kwestie. Het is kwaliteitscontrole. Dezelfde tactieken die mijn kosten hebben verlaagd – schone sessies, lean CLAUDE.md, agressieve /clear en /compact, subagenten voor zwaar werk – hebben het model ook aanzienlijk nauwkeuriger gemaakt. Omdat dezelfde omstandigheden die de kosten omhoog drijven (lange context, verzamelde cruft, afdrijvende onderwerpen) de nauwkeurigheid verlagen.

Ik had het achterstevoren in mijn hoofd. Ik dacht dat er een afweging was: meer uitgeven, betere resultaten behalen. De werkelijke relatie is, naar mijn ervaring, het tegenovergestelde. Sessies die veel kosten, waren bijna altijd sessies waarbij de output slechter werd, en ik schoof alleen maar meer tokens naar het probleem om dit te compenseren.

Nu behandel ik een klimbiljet zoals een arts koorts behandelt: als een symptoom. Er is iets mis met de sessie. Compacteer het. Wis het. Geef het af. De rekening daalt en de productie gaat tegelijkertijd omhoog.

Hier zitten grenzen aan, en die wil ik benoemen. Contexthygiëne zal u niet redden als uw probleem echt moeilijk is en redenering op Opus-niveau vereist over een grote codebase. Sommige sessies zijn duur omdat het werk duur is. Dat is prima. Het doel is niet om de uitgaven te minimaliseren; het is om ervoor te zorgen dat als u toch geld uitgeeft, u geld uitgeeft aan signaal, en niet aan het herlezen van oud gespreksgeluid.

Hoe dit er over acht weken uitziet

Dit is wat er voor mij concreet is veranderd nadat ik dit systeem twee maanden lang op vier projecten had uitgevoerd.

De gemiddelde dagelijkse uitgaven aan Claude Code daalden met ongeveer 60%. Sommige dagen meer, sommige minder. De variantie daalde ook: minder verrassingsdagen van $ 70.

De sessieduur voor één enkel gesprek daalde van 'totdat er iets kapot gaat' naar 'totdat /context ~50% toont'. Dat klinkt als een downgrade. Dat is het niet. De nieuwe sessies zijn van begin tot eind scherper. De oude lange sessies kenden in de tweede helft een kwaliteitsklif die ik net aan het absorberen was.

CLAUDE.md kromp in al mijn projecten van gemiddeld ongeveer 400 regels naar minder dan 150. Er ging niets belangrijks verloren. Veel dingen waarvan ik dacht dat ze belangrijk waren, bleken cruft te zijn, waarvoor ik elke keer moest betalen om te injecteren.

Het aantal MCP-servers waarmee ik standaard verbonden blijf, ging van zes naar twee. De andere vier worden op aanvraag verbonden voor specifieke taken en worden verbroken wanneer de taak eindigt.

En het deel dat ik echt niet had verwacht: het werk dat ik produceer in Claude Code is merkbaar beter. Schonere code. Minder hallucinaties. Meer gerichte architecturale beslissingen. Niet omdat het model beter werd: Sonnet 4.6 en Opus 4.7 zijn dezelfde modellen die ik eerder gebruikte. Omdat de sessies beter werden. Minder context rot. Minder drift in het midden van het venster. Meer signaal, minder ruis.

Dat is het deel hiervan dat ik je wil meegeven. Tokenlimieten zijn geen budget waar je onder moet leven. Ze zijn een kwaliteitssignaal waar je naar moet luisteren. Wanneer de rekening stijgt, vertelt het model u iets: dat de sessie zijn nuttige levensduur heeft overschreden, dat de context meer heeft verzameld dan hij netjes aankan, dat het tijd is voor een harde reset.

Luister ernaar. Compact. Duidelijk. Hand af. Begin opnieuw.

De kosten gaan omlaag. De output gaat omhoog. En uiteindelijk, na voldoende cycli, denk je er helemaal niet meer over na om tokens te beheren. Je beschouwt het als gewoon: goed werken met Claude.

Veelgestelde vragen

Waarom herleest Claude bij elk bericht het hele gesprek?

Transformer-gebaseerde LLM's verwerken het volledige contextvenster bij elke inferentieoproep - er is geen intern geheugen van eerdere beurten zoals mensen zich gesprekken herinneren. Bij elk nieuw bericht worden de systeemprompt, alle voorgaande beurten en eventuele geladen bestanden opnieuw verwerkt als één enkele invoer. Dit is een architectonisch pand en geen Claude-specifieke ontwerpkeuze. Voor de volledige tokenwiskunde, zie "De wiskunde die niemand je laat zien" hierboven.

Wat is het verschil tussen /clear en /compact in Claude Code?

/clear wist de gespreksgeschiedenis volledig en begint opnieuw: gebruik deze tussen niet-gerelateerde taken. /compact vat de bestaande geschiedenis samen in een verkorte versie met behoud van de belangrijkste feiten. Gebruik het proactief bij ongeveer 50% contextgebruik om een ​​productieve sessie uit te breiden. Beide zijn gedocumenteerd in de Claude Code commandoreferentie.

Is het 1M-tokencontextvenster de moeite waard om te gebruiken op Claude Code?

Soms, maar zelden als standaard. Uit onderzoek naar context rot blijkt dat de nauwkeurigheid ver vóór de limiet van 1 miljoen afneemt – vaak rond de 200.000 – 300.000 tokens, zelfs op modellen die reclame maken voor 1 miljoen context. Gebruik het grotere venster voor echt grote invoer (volledige codebases, lange documenten), maar verwacht dat de kwaliteit halverwege de context afneemt. Voor de meeste werksessies presteert een schone 50k-context beter dan een uitgestrekte 800k-context.

Moet ik altijd Opus 4.7 gebruiken voor het coderen?

Nee. Sonnet 4.6 ligt binnen ~1,2 SWE-bench-punten van Opus tegen 60% van de kosten, volgens BenchLM's 2026 benchmarks. Gebruik Sonnet als uw standaard en reserveer Opus voor echt harde redeneringen: nieuwe problemen, dubbelzinnige specificaties, complexe foutopsporing. De meeste codeertaken hebben geen diepgang op Opus-niveau nodig.

Hoe controleer ik hoeveel tokens mijn Claude Code-sessie gebruikt?

Voer /context uit in Claude Code. Het toont een gekleurd raster van het huidige contextgebruik, opgesplitst per systeemprompt, CLAUDE.md, MCP-toolschema's en geladen bestanden. Voer het uit als het eerste dat u tijdens een sessie doet, niet na een uur werken. Het kennen van uw startoverhead verandert de manier waarop u werkt.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io