Claude Code 1M Context: Zo Voorkom Ik Contextrot

Claude Code 1M Context: Zo Voorkom Ik Contextrot

De teller van de sessie stond op 612.000 tokens. Opus 4.7 was al bijna vier uur aan het werk. Het had 38 bestanden gelezen, een Laravel service layer geherstructureerd, tests geschreven, en vertelde me nu vol vertrouwen dat ik een methode moest updaten op een klasse die ik negentig minuten eerder had verwijderd.

Niet gehallucineerd. Verwijderd. Door Claude zelf. Met een tool-call waar ik in dezelfde sessie naar terug kon scrollen.

Ik zat daar voor de terminal — koffie koud geworden, de cursor knipperend onder een fix die een regression zou hebben geïntroduceerd — en voelde diezelfde angst die iedere Claude Code power user kent. Het model werd niet dommer. Het model verdronk. Ergens tussen token 300k en token 600k was de context stilletjes veranderd van een troef in een valkuil.

Dit is het deel dat niemand in de marketingtekst zet voor het Claude Code 1M context window. Het window is echt. Het werkt. Ik kan het bewijzen. Maar "1 miljoen tokens" is niet hetzelfde als "1 miljoen tokens aan heldere, gerichte, betrouwbare redenering." Het verschil tussen die twee dingen is waar het grootste deel van mijn recente debugging plaatsvond.

De afgelopen 30 dagen heb ik genoeg Opus 4.7-sessies op Max 20x versleten om precies in kaart te brengen waar context rot begint, wat het triggert, en de vijf specifieke stappen die langdurige Claude Code-sessies scherp houden in plaats van sponzig. Niets ervan is theoretisch. Alles kwam voort uit het eerst stukmaken van echte builds.

Als je ooit hebt meegemaakt dat Claude een constraint vergat die je in bericht drie had gezet, dan is dit voor jou.

Wat "1M Context" op dit moment werkelijk betekent in Claude Code

Even wat huishoudelijke zaken, want de versienummers zijn belangrijk en de meeste artikelen hebben ze fout.

Het 1 miljoen-token venster in Claude Code kwam niet met Opus 4.5. Opus 4.5 (november 2025) kwam uit op ongeveer 250k. Het 1M-venster werd geleverd met Claude Opus 4.6 op 5 februari 2026 — en werd vervolgens algemeen beschikbaar in Claude Code op 13 maart 2026 voor zowel Opus 4.6 als Sonnet 4.6. Het huidige model op het moment van schrijven is Opus 4.7, uitgebracht op 16 april 2026, met hetzelfde 1M maximum.

Toegang hangt nog steeds van je abonnement af:

• Max, Team, Enterprise — 1M is automatisch bij Opus 4.6/4.7, geen extra kosten, geen schakelaar om om te zetten
• Pro ($20/maand) — je moet zelf activeren door /extra-usage te typen binnen Claude Code; tokens boven het standaardvenster worden afgerekend met extra-gebruik tegoed
• API — voor context boven 200k geldt de long-context-tariefgroep; controleer de actuele Anthropic-prijzen voordat je een workflow bouwt die uitgaat van voordelige tarieven

Het contextvenster zelf omvat alles wat het model in één keer kan zien: de systeemprompt, je CLAUDE.md, gespreksgeschiedenis, elk bestand dat Claude heeft gelezen met de Read-tool, elke tooloutput die het heeft geproduceerd, elk Glob/Grep-resultaat, en het huidige bericht dat je net hebt getypt. Alles telt mee. Alles concurreert om aandacht.

Dat laatste is de kern van het verhaal. Onthoud dat goed.

Het getal dat niemand noemt: Context rot begint bij 300k, niet bij 1M

De marketingpitch voor elk model met een grote contextvenster wekt de indruk van een vlakke prestatiecurve — dat token 999.000 even waardevol is als token 9.000. Dat is niet zo. Er bestaat een officiële term voor wat er werkelijk gebeurt, en die verdient een vaste plek in de vocabulaire van iedere Claude Code-gebruiker.

Context rot is de meetbare achteruitgang in modelprestaties naarmate de inputcontext toeneemt. Het is geen bug die enkel bij Anthropic voorkomt. Chroma's studie uit 2025 testte 18 toonaangevende modellen — GPT-4.1, Claude Opus 4, Gemini 2.5, noem ze maar op — en vond context rot bij elk geanalyseerd inputniveau. Zelfs het eigen engineeringteam van Anthropic schrijft er openlijk over. Zij omschrijven context als een “eindig aandachtsbudget” dat met elk nieuw token verder omlaag gaat, net zoals het werkgeheugen van de mens.

Het praktische getal dat telt voor Claude Code: de degradatie wordt merkbaar bij ongeveer 300.000 tot 400.000 tokens. Dat is ruwweg 30–40% van de 1M-limiet — veel eerder dus dan het getal in de spotlights doet vermoeden. Op de MRCR multi-needle retrieval benchmark haalt Opus 4.6 nog altijd 76% nauwkeurigheid bij een volle 1M, wat uitstekend is voor een frontier model. Maar “76% accurate retrieval” wordt een ramp wanneer je een agent onbewaakt aan productiecode laat sleutelen. Die andere 24% staat op jouw naam.

Hoe rot er in de praktijk uitziet, is zelden een hallucinerende fout die je meteen ziet. Het is subtieler. Het is stiller. Het zijn de vier faalpatronen hieronder — en zodra je ze kunt benoemen, kun je ze opsporen.

De Vier Faaltmodi Die Ik Nu Hardop Benoem

Voordat ik hier de juiste vocabulaire voor had, voelde elk “Claude doet raar”-moment aan als hetzelfde vage probleem. Nu stel ik in seconden een diagnose. Elk probleem vereist een andere oplossing.

1. Contextvervuiling

Vervuiling is irrelevante informatie die het signaal verdringt. Je draaide een Grep die 800 matches opleverde. Je liet Claude een logbestand van 4.000 regels lezen “voor het geval dat.” Je voegde de complete node_modules types directory toe omdat je niet wist in welk bestand het type stond. Op zichzelf is geen van deze dingen fout. Maar samen maken ze Claude’s aandacht tot een brij.

Het model weet niet wat jij als relevant beschouwt. Het behandelt elke token als mogelijk essentieel. Hoe meer ruis je toevoegt, hoe meer cognitieve capaciteit wordt besteed aan het opnieuw evalueren van die ruis.

Herkenbaar teken: Claude verwijst naar bestanden waarvan je was vergeten dat je ze had ingeladen.

2. Doelvervaging

Doelvervaging is het langzame wegzakken van de oorspronkelijke intentie. Je begint de sessie met: “herschrijf de auth middleware om OAuth 2.1 te ondersteunen, zorg dat alle bestaande JWT-flows blijven werken, raak het user model niet aan.” Drie uur later, nadat Claude 22 bestanden heeft gelezen, acht niet-gerelateerde lintfouten heeft gefixt en een log-helper heeft gerefactord, vraag je hem om een nieuwe claim toe te voegen aan de JWT payload en verandert hij het user model.

Hij negeerde je beperking niet. Die beperking is gewoon verwaterd. Met 400k tokens tussen de oorspronkelijke instructie en het huidige verzoek is de signaal-ruisverhouding van de system prompt verdwenen.

Herkenbaar teken: Claude doet wat je nu vraagt, maar schendt een regel uit de oorspronkelijke briefing.

3. Geheugencorruptie

Dit was de reden dat ik deze post moest schrijven. Geheugencorruptie gebeurt wanneer het interne model van de agent van de werkelijkheid afdrijft. Het bestand waarvan Claude denkt dat het bestaat op app/Services/UserService.php is in beurt 47 verwijderd. Claude gebruikt nog steeds de versie die hij in werkgeheugen heeft onthouden. Je leest zijn plan, het lijkt coherent, je keurt het goed — en de patch eindigt in een bestand dat niet meer bestaat, of erger nog, op een verouderde versie van een bestaand bestand.

Mijn ergste geval hiervan zag ik bij een Multica refactor: Opus paste een service drie keer aan in de sessie, en bij de vierde wijziging genereerde hij een diff tegen de eerste versie van het bestand. De tussentijdse patches stonden wel in de conversatiegeschiedenis. Ze werden alleen niet meegewogen.

Herkenbaar teken: Tool-calls verwijzen naar een situatie die niet overeenkomt met het huidige bestandssysteem.

4. Besluitonnauwkeurigheid

Besluitonnauwkeurigheid is de consistentiebelasting. Aan het begin van de sessie besluit je: “alle fouten in deze service gooien een DomainException en worden doorgegeven; de handler logt naar Sentry.” Later, diep in de context, schrijft Claude een nieuwe methode die alles opvangt als \Exception, logt naar Log::error en een 500 teruggeeft.

Het is geen foutieve code. Het is gewoon niet jouw code. Andere keuzes, tegenstrijdige patronen, geen consistente ontwerptaal.

Herkenbaar teken: Code-stijl en architecturale keuzes komen niet meer overeen met de rest van de codebase, zelfs nadat Claude deze gelezen heeft.

Voor elk van deze problemen is er een oplossing. Geen ervan is “gebruik een kleiner model.” Ze hebben allemaal te maken met hoe je het contextwindow beheert.

De Vijf Moves Die Ik Dagelijks Gebruik

Wanneer een Claude Code-sessie over de 300k tokens gaat — of wanneer ik een van de vier hierboven genoemde faalmodi zie — heb ik vijf opties. De kunst is weten welke je moet kiezen. Ze zijn niet inwisselbaar.

Optie 1: Doorgaan (En Waarom Ik Dat Bijna Nooit Meer Doe)

De standaardzet. Gewoon doorgaan. De verleiding is groot omdat je “in de flow” zit en de overstapkosten hoog lijken.

Ik kies hier zelden nog voor, tenzij ik onder de 300k tokens zit EN het werk oppervlakkig is (enkel bestand, enkel onderwerp). Daarna is doorgaan een gok — elke nieuwe beurt stapelt de rot verder op. De kosten van een slechte patch die in productie terechtkomt, zijn vele malen hoger dan pauzeren en de context resetten.

Optie 2: Compacteren, Maar Dan Handmatig

/compact vat het bestaande gesprek samen tot een kortere samenvatting en gaat verder. In theorie is het de magische gum voor contextopblazing. In de praktijk is autocompact — de versie die automatisch afgaat als je de window-limiet raakt — onbetrouwbaar. Claude’s compaction-logica geeft voorkeur aan recente beurten en kan ongemerkt oudere, kritische context verwijderen: de originele briefing, de architecturale beslissingen, de beperkingen uit bericht drie.

Ik laat autocompact dus nooit uit zichzelf draaien. Ik voer /compact handmatig uit, proactief, rond de 300k, en geef expliciete instructies wat er bewaard moet blijven:

/compact Preserve: (1) de originele briefing bovenaan de sessie,
(2) alle architecturale beslissingen uit beurten 1–15,
(3) de lijst van bestanden die we al aangepast hebben en waarom,
(4) elke beperking die begint met "DO NOT" of "MUST".
Drop: tooloutput, tussentijdse Grep-resultaten, bestandlezen die we niet meer nodig hebben.

Die ene instructie verandert de kwaliteit van het compacteren drastisch. Je gaat van “vat de chat samen” naar “maak een gestructureerd overdrachtsdocument.” Groot verschil.

Optie 3: Wissen En Opnieuw Beginnen

/clear wist de context volledig. Het is de nucleaire optie. Maar ook vaker de juiste optie dan ik vroeger dacht.

Ik gebruik /clear als ik echt naar ander werk ga — bijvoorbeeld klaar met de auth refactor en over naar een billing webhook fix. Er is nul voordeel aan het meeslepen van auth-context naar de billing-sessie, maar wel ontzettend veel nadeel (vervuiling, drift, alle bovenstaande problemen).

De fout die mensen maken met /clear, is het zien als een mislukking. Dat is het niet. Een verse, gefocuste sessie van 12k tokens presteert altijd beter dan een oude, troebele sessie van 600k tokens vol onduidelijke redeneringen.

Optie 4: Clear + JSON Save (Mijn Standaard Voor Complex Werk)

Dit is de move waar ik het meest op vertrouw. Voor ik wis, laat ik Claude een gestructureerd JSON-bestand maken dat de staat van het werk vastlegt voor een nieuwe sessie. Bijvoorbeeld:

{
  "objective": "Migreer auth middleware naar OAuth 2.1 met behoud van JWT flows",
  "constraints": [
    "Wijzig app/Models/User.php niet",
    "Alle nieuwe endpoints moeten /api/v1-prefix behouden",
    "Bestaande JWT-consumenten moeten blijven werken"
  ],
  "files_modified": [
    {"path": "app/Http/Middleware/Authenticate.php", "status": "compleet"},
    {"path": "app/Services/Auth/OAuthHandler.php", "status": "in-progress"}
  ],
  "open_decisions": [
    "Strategie rotatie refresh token nog te bepalen",
    "Check of oud JWT-formaat een deprecatie-header krijgt"
  ],
  "next_step": "Implementeer refresh token rotatie in OAuthHandler::refresh()"
}

Daarna /clear ik, start een nieuwe sessie, en mijn eerste bericht is: “Lees .claude/state.json, bevestig dat je het huidige doel en de beperkingen snapt, en ga dan verder vanaf next_step.”

Die overdracht is vele malen betrouwbaarder dan welke /compact-run dan ook. De nieuwe sessie begint op zo’n 15k tokens, met een perfect signaal. Geen drift. Geen corrupte geheugen. Geen half onthouden constraints.

Optie 5: Subagents Voor Alles Dat Context Kan Overspoelen

Subagents zijn de nooduitgang van Claude Code voor taken die anders enorme tooloutput in je hoofdcontext zouden dumpen. De agent draait in een eigen, geïsoleerde context-window, doet zijn werk, en geeft alleen het eindresultaat terug aan de hoofd-sessie.

De mentale test die ik gebruik — en die het team van Anthropic zelf gebruikt — is: “Heb ik deze tooloutput later nog nodig, of alleen de conclusie?”

Alleen de conclusie nodig? Subagent. Voorbeelden:

• "Doorzoek de hele codebase naar alle plaatsen waar we de legacy betaalgateway aanroepen en rapporteer alleen de bestandsnamen en regelnummers" — perfecte subagent-taak. De Grep-output zou anders 40k tokens van je hoofdcontext opvreten. De uiteindelijke lijst past in 200 tokens.
• "Lees deze 12 documentatiepagina's en zeg welke de rate limit-info bevat" — subagent. De 12 pagina’s vervuilen, het antwoord is één zin.
• "Draai de testsuite en rapporteer alleen de fouten met stack traces" — subagent. Je hebt de 8.000 regels pass-output niet nodig.

Ik configureer deze als echte Claude Code subagents in .claude/agents/, zodat de orkestratie herhaalbaar is. De eerste keer dat ik een 90-minuten sessie retrofittede om subagents te gebruiken voor zoekintensieve stappen, zakte de hoofdcontext van 400k naar 90k en bleef Opus scherp tot het eind.

De drie praktijken die stiekem belangrijker zijn dan welke prompt ook

Naast de vijf opties zijn er drie gewoontes die op dagelijkse basis het grootste verschil maken. Geen ervan is opvallend.

Terugspoelen in plaats van herprompten

Wanneer Claude een verkeerde beslissing neemt en jij die corrigeert, blijft die verkeerde beslissing voor altijd in de context staan. Drie beurten later corrigeer je een andere gerelateerde fout. Tegen de tiende beurt bestaat het gesprek voor de helft uit echt werk en voor de helft uit "nee, niet dat, doe dit in plaats daarvan." De context rot versnelt.

De nettere zet is terugspoelen — zet het gesprek terug naar vóór de verkeerde beurt en geef een betere initiële instructie die rekening houdt met wat je hebt geleerd. Claude Code laat je eerdere berichten bewerken. Gebruik die functie. De teruggespoelde sessie is veel schoner, compacter beter, en veroorzaakt minder nieuwe fouten verderop.

Ik beschouw nu de derde "nee, dit klopt nog steeds niet" als een automatische trigger om terug te spoelen, niet om te blijven corrigeren.

Regelmatige samenvattingen zijn niet optioneel

Elke 50–75k tokens inhoudelijk werk vraag ik: "Vat het huidige doel samen, de afgesproken beperkingen, en het werk tot nu toe." Twee alinea’s, maximaal.

Dit klinkt misschien verspild. Het tegendeel is waar. De samenvatting dwingt Claude om zich opnieuw op de opdracht te richten, wat doelafwijking in volgende beurten sterk vermindert. Het geeft mij ook direct zicht op wanneer Claude’s begrip al is gaan afwijken — als de samenvatting niet klopt, weet ik dat de context rot al begonnen is en het tijd is voor /compact of /clear.

Beschouw samenvattingen als de goedkope versie van compactie. Compactie herstructureert het geheugen. Samenvattingen versterken het.

Expliciete compactie-instructies zijn altijd beter dan het standaardgedrag

Ik noemde dit bij Optie 2, maar het verdient een eigen regel. Laat je /compact zonder instructies draaien, dan vertrouw je erop dat Claude’s standaardinstellingen weten wat essentieel is in jouw werk. Vaak is dat niet zo. De beperking die je bij het derde bericht noteerde is voor de summarizer gewoon tekst.

Vertel /compact altijd wat behouden moet blijven, wat weg kan, en hoe de output gestructureerd moet zijn. Behandel het als het schrijven van een overdrachtsdocument voor een collega, niet als het oproepen van een magisch commando.

Hoe Dit Ervan Begin Tot Eind Uitziet: Een Echte Sessie

Hier is een uitgeklede versie van hoe een lange Claude Code-sessie nu daadwerkelijk voor mij verloopt, na een maand het proces hebben aangescherpt:

1. Start sessie — CLAUDE.md is strak, de briefing staat in het eerste bericht, beperkingen zijn expliciet. Aantal tokens: ~5k.
2. Eerste 200k tokens — gewoon werken. Ik optimaliseer niets. Bestanden lezen, code schrijven, tests uitvoeren. Context is gezond.
3. Bij 300k — eerste checkpoint. Ik vraag om een samenvatting. Richting wordt bevestigd. Nog geen /compact zolang het werk gefocust blijft.
4. Bij 400k — tweede checkpoint. Als ik nog midden in een taak zit, voer ik handmatig een /compact uit met expliciete behoud/verwijder-instructies. Token-aantal zakt terug naar ~80k. Doorgaan.
5. Elke output van >20k tokens uit tools — subagent. Altijd.
6. Einde van een afgebakend werkblok — schrijf een JSON statusbestand, /clear, nieuwe sessie, opnieuw opstarten vanuit JSON. De overgang kost me 3 minuten en bespaart me een ophoping van context rot.
7. Eerste “nee, dit klopt nog steeds niet”-loop — pauze. Diagnoseer welke van de vier faalmodi actief is. Pak het juiste oplossing. Blijf niet blind reprompten.

Dat is alles. Geen magie. Geen nieuwe tools. Gewoon gedisciplineerd gebruikmaken van wat Claude Code standaard biedt.

Het resultaat: ik draai nu productieve Claude Code-sessies die een volledige werkdag bestrijken op één project, zonder dat het model ontspoort. Een maand geleden haalde ik de dinsdagmiddag nog niet zonder een kettingreactie aan hallucinaties.

Wat Ik de Eerste Drie Weken Verkeerd Deed

Ik ben je de eerlijke versie verschuldigd van hoe ik dit heb uitgezocht, want ik heb er behoorlijk wat geld aan verspild om hier te komen.

Ik ging ervan uit dat een grotere context altijd beter was. Ik stopte expres meer bestanden in de context “zodat Claude volledige zichtbaarheid heeft.” Fout. Elk irrelevant bestand was een kleine belasting bij elke volgende beurt. Minder is meer. Lees wat je nodig hebt, niet wat misschien nuttig zou kunnen zijn.

Ik vertrouwde op autocompact. Drie weken lang liet ik het uitvoeren wanneer het maar wilde. De afwijking was zo geleidelijk dat ik mezelf de schuld gaf, of mijn prompts, of mijn projectstructuur — alles behalve de daadwerkelijke boosdoener. De eerste keer dat ik autocompact uitschakelde en handmatige compactions uitvoerde met expliciete instructies, was het verschil dag en nacht.

Ik vermeed subagents omdat de orkestratie als overhead aanvoelde. Ook daarin had ik ongelijk. Het opzetten van een zoek-subagent of een test-runner-subagent kost één keer tien minuten. Het bespaart je daarna iedere sessie 50k-token tool dumps.

En ik beschouwde /clear als een nederlaag. Dat is het niet. Een schone sessie is geen mislukte sessie. Een schone sessie is een tool. Gebruik het.

Veelgestelde Vragen

Wanneer begint context rot in Claude Code?

Context rot in Claude Code wordt meetbaar rond 300.000 tot 400.000 tokens — ongeveer 30–40% van het 1M-venster. De prestaties storten dan niet meteen in, maar doelafwijking, geheugenvervuiling en beslissingsinconsistentie worden vanaf dat punt merkbaar waarschijnlijker. Zie 300k als je eerste controlepunt, niet 1M als je plafond.

Moet ik /compact of /clear gebruiken in Claude Code?

Gebruik /compact wanneer de huidige taak nog gaande is en de recente context echt nodig blijft; gebruik /clear bij het overschakelen naar niet-gerelateerd werk of wanneer de context zó vervuild is dat zelfs samenvatten ruis zou achterlaten. Bij complex werk in uitvoering is het sterkste patroon: schrijf een JSON-statusbestand, /clear, en start een frisse sessie opnieuw op basis van de JSON.

Kost het 1M context-venster extra in Claude Code?

Bij Max-, Team- en Enterprise-abonnementen is het 1M context-venster inbegrepen zonder extra kosten voor Opus 4.6 en Opus 4.7. Met het Pro-abonnement ($20/maand) moet je optioneel kiezen voor /extra-usage en worden tokens boven het standaard venster in rekening gebracht via extra-gebruik tegoeden. API-prijzen gebruiken de long-context-laag boven 200k — controleer de actuele tarieven vóórdat je een workflow daarop bouwt.

Wat is het verschil tussen /compact en sub agents?

/compact vat het bestaande gesprek in je huidige sessie samen om tokens vrij te maken; sub agents voorkomen de wildgroei helemaal door neventaken in hun eigen geïsoleerde context-vensters uit te voeren en alleen het eindresultaat terug te geven. Gebruik sub agents voor taken waarvan je de tool-output niet steeds hoeft te blijven raadplegen — zoeken, log-analyse, testruns.

Waarom begint Claude Code te hallucineren in lange sessies?

Lange Claude Code-sessies hallucineren door context rot — naarmate de invoer groeit, raakt het aandachtbudget van het model versnipperd en worden oudere randvoorwaarden, bestandsinhoud en beslissingen steeds minder zwaar meegewogen. De oplossing is niet een groter venster; het is actief beheer: handmatige /compact met expliciete instructies, periodieke samenvattingen, sub agents voor taken met hoge output, en /clear+JSON-overdracht tussen grote werkblokken.

Dus: je terminal staat open. De sessie zit op 280k tokens. Opus 4.7 heeft zojuist voorgesteld een bestand te bewerken waarvan je 80% zeker weet dat je het een uur geleden hebt verwijderd.

Wat doe je in de komende 60 seconden?

Als je antwoord is: ‘vraag Claude om het te dubbelchecken’, dan beheer je context nog op de oude manier. Als het is: ‘ga terug naar de laatste schone beurt, schrijf een JSON-statusbestand, /clear, en herstart’ — welkom bij de versie van Claude Code die daadwerkelijk een volledige werkdag schaalbaar maakt. Het 1M-venster is echt. De betrouwbaarheid erin is iets wat je moet engineeren.

Ik engineer het liever, dan het model de schuld te geven.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag verder.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io