Contextvenster

Wat is een contextvenster?

Een contextvenster is de maximale hoeveelheid tekst die een AI-model in één verzoek kan verwerken, gemeten in tokens, die de systeemprompt, gespreksgeschiedenis, opgehaalde documenten, toolresultaten, en de eigen output van het model omspant. Het functioneert als het werkgeheugen van het model: alles erbinnen kan het antwoord beïnvloeden, en alles erbuiten bestaat niet voor het model.

De belangrijkste punten

• Alles deelt één budget. Instructies, geschiedenis, bestanden, tooloutput, en het gegenereerde antwoord putten allemaal uit dezelfde tokenpool, dus verdringt een lang transcript direct ruimte om te denken.
• Vensters groeiden van een paar duizend tokens naar meer dan een miljoen in een paar jaar, wat veranderde wat mogelijk is zonder te veranderen wat verstandig is. Anthropics uitbreiding van Claude Sonnet 4 naar 1 miljoen tokens in augustus 2025 was een sprong van 5x, genoeg om een codebase van meer dan 75.000 regels in één verzoek te passen [1].
• Geadverteerde grootte en effectieve grootte verschillen. Herinnering en redeneerkwaliteit verslechteren over zeer lange inputs, dus zijn de laatste honderdduizend tokens zelden zo nuttig als de eerste.
• Het venster heeft geen persistentie. Wanneer een sessie eindigt of geschiedenis wordt bijgesneden, is die informatie weg tenzij iets zoals agentgeheugen het doelbewust vastlegt.

Hoe het werkt

Modellen lezen tekst als tokens, stukken van ruwweg drie tot vier Engelse tekens, en de architectuur legt een maximum vast waar het model in één verzoek aandacht aan kan geven. Dat plafond blijft bewegen: Google lanceerde Gemini 1.5 Pro in 2024 met een standaardvenster van 128.000 tokens en meldde succesvol tot 10 miljoen tokens te hebben getest in onderzoek [2]. Binnen die limiet laat het attention-mechanisme elk token relateren aan elk ander, wat is wat een antwoord op de laatste regel in staat stelt te putten uit een detail van de eerste. Datzelfde mechanisme verklaart het plafond: attention-kosten groeien steil met lengte, dus vergt het bedienen van lange vensters echt geheugen en rekenkracht, wat aanbieders terugwinnen met trucs zoals het cachen van het ongewijzigde prefix van herhaalde verzoeken. Praktische gevolgen volgen direct, inclusief waarom lange inputs meer kosten en waarom het stabiele deel van een prompt identiek houden over aanroepen heen goedkoper is dan het door elkaar husselen.

Het venster is een rollende beperking in plaats van een eenmalige check. In een gesprek of agentsessie herverpakt elk verzoek de opgestapelde geschiedenis plus de nieuwe beurt, en zodra het totaal de limiet nadert, moet iets wijken: oude beurten worden verwijderd, samengevat via compactie, of uitbesteed aan externe opslag en op aanvraag opgehaald via RAG-achtige opzoeking. Dit is de mechanische realiteit onder context engineering, de discipline van het budget goed besteden.

Capaciteit en kwaliteit gaan ook uit elkaar naarmate inputs groeien. Een model met een venster van een miljoen tokens accepteert een miljoen tokens, maar het ophalen van specifieke details uit het midden van enorme inputs is meetbaar minder betrouwbaar dan van de randen, en irrelevant volume leidt actief af, het verslechteringspatroon genaamd context rot. De kloof is groot: de NoLiMa-benchmark van 2025 testte 13 LLM's die vensters van 128K-plus claimden en vond dat GPT-4o daalde van een short-context-baseline van 99,3% naar 69,7% bij slechts 32K tokens [3]. Practitioners denken daarom in termen van een effectief venster, de lengte waarop het model nog steeds bijna optimaal presteert, en behandelen ruimte daarboven als noodruimte in plaats van een doel om te vullen.

Voorbeeld

Een coding-agent begint een grote migratie in een venster van 200.000 tokens. Sessiestart is goedkoop: instructies en het taakbriefje gebruiken 6.000 tokens. Drie uur later bevat de geschiedenis tientallen bestandslezingen, testruns, en diffs, en het venster staat op 85 procent. Symptomen verschijnen voor enige harde fout: de agent leest bestanden opnieuw die hij al zag en herbespreekt een ontwerpbeslissing uit het eerste uur, omdat het verslag van die beslissing tweehonderd pagina's terug begraven ligt. De harness compacteert, vervangt het oudste transcript door een samenvatting van genomen beslissingen en aangeraakte bestanden, en bevrijdt 60 procent van het budget. De agent scherpt onmiddellijk aan, en het team voegt een regel toe om bij 60 procent te compacteren in plaats van te wachten, plus een scratchpad-bestand waar de agent kernbeslissingen registreert zodat niets dragends alleen in het transcript leeft.

Veelvoorkomende misvattingen

De veelgemaakte fout is een gigantisch venster behandelen als oplossing voor geheugen, op basis van de logica dat een miljoen tokens betekent dat de hele codebase er gewoon in geplakt kan worden. Het faalt twee keer. Binnen een sessie verlaagt het venster volproppen de precisie van het model op de delen die ertoe doen terwijl het kosten vermenigvuldigt, dus is de dump slechter dan een gecureerde selectie relevante bestanden. Over sessies heen lost het venster helemaal niets op, want het is werkgeheugen, geen opslag: de sessie van morgen begint leeg ongeacht grootte. Duurzame kennis heeft een echt mechanisme nodig, instructiebestanden, geheugensystemen, retrieval, en een groter venster verandert daar niets aan. Venstergrootte is capaciteit; geheugen is architectuur.

FAQ

Wat gebeurt er wanneer een contextvenster vol raakt? Het verzoek wordt ofwel afgewezen wegens overschrijding van de limiet, of, in beheerde chat- en agentproducten, oudere content wordt stilletjes verwijderd of samengevat om ruimte te maken. Dat bijsnijden is waarom lange sessies vroege details "vergeten": de tokens zitten oprecht niet meer in het gezichtsveld van het model.

Is een groter contextvenster altijd beter? Groter is capabeler maar niet automatisch beter gebruikt. Lange inputs kosten meer per verzoek, vertragen antwoorden, en verwateren aandacht, en modellen halen minder betrouwbaar op uit het midden van enorme contexten. Een relevante 20.000 tokens verslaat routinematig een ongedifferentieerde 500.000.

Hoe verschilt een contextvenster van geheugen? Het venster is vluchtig werkgeheugen binnen één verzoekcyclus; het bewaart niets. Geheugen in agentsystemen betekent expliciete machinerie, bestanden, databases, retrieval, die informatie buiten het venster vastlegt en later herlaadt. De twee door elkaar halen is hoe teams verrast eindigen dat hun agent morgen niets meer weet.

Bronnen

1. Anthropic. "Contextvenster van Claude Sonnet 4 uitgebreid naar 1 miljoen tokens, een toename van 5x die codebases van meer dan 75.000 regels dekt." https://claude.com/blog/1m-context. Geraadpleegd augustus 2026.
2. Google (officiële blog). "Gemini 1.5 Pro gelanceerd met een standaard contextvenster van 128.000 tokens; tot 10 miljoen tokens getest in onderzoek." https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/. Geraadpleegd augustus 2026.
3. Modarressi et al., arXiv (NoLiMa). "13 LLM's met geclaimde vensters van 128K+ getest; GPT-4o daalde van een short-context-baseline van 99,3% naar 69,7% bij 32K tokens." https://arxiv.org/abs/2502.05167. Geraadpleegd augustus 2026.