Een contextvenster is de maximale hoeveelheid tekst, gemeten in tokens, die een model in één aanroep kan lezen en over kan redeneren. Alles wat het model tijdens die aanroep weet, prompts, geschiedenis, opgehaalde documenten en tool-uitvoer, moet daarbinnen passen.
Tokens, niet woorden
Modellen verwerken geen tekens of woorden rechtstreeks. Ze verwerken tokens: stukken tekst die door een tokenizer worden gegenereerd. Een vuistregel is dat één token ongeveer drie tot vier tekens in het Engels beslaat, ofwel ongeveer 0,75 woord. Een contextvenster van 128.000 tokens bevat ongeveer 90.000 tot 100.000 woorden, maar exacte aantallen hangen af van het model en de tokenizer die het gebruikt.
Code wordt anders getokeniseerd dan doorlopende tekst. Variabelenamen, interpunctiezware syntaxis en niet-Latijnse tekens kunnen tokens sneller verbruiken dan gewone Engelse tekst.
Wat er in het venster zit
Elke token in één modelaanroep concurreert om dezelfde ruimte:
- Systeemprompt
- Gespreksgeschiedenis
- Opgehaalde documenten of chunks (zie wat is RAG)
- Tooldefinities en resultaten van toolaanroepen
- Het huidige bericht van de gebruiker
- Ruimte gereserveerd voor het antwoord van het model
In een agentische loop komen tooluitvoer bij elke iteratie terug in de context. Een taak met meerdere stappen kan een groot venster sneller vullen dan engineers verwachten.
Waarom grootte niet het hele verhaal is
Langere contextvensters lossen niet alles op, om een paar redenen.
Ten eerste: kosten. De meeste providers rekenen per token, zowel voor invoer als uitvoer. Bij schaal is het versturen van 100.000 tokens per aanroep duur.
Ten tweede: latentie. Grotere payloads kosten meer tijd om te verwerken, wat belangrijk is bij interactieve of realtime toepassingen.
Ten derde: kwaliteit van ophalen. Onderzoek en praktijkervaring laten zien dat modellen het spoor kunnen bijster raken van informatie die diep in een lange context is begraven. Het plaatsen van het meest relevante materiaal aan het begin of einde van de prompt levert doorgaans betere resultaten op.
Ten vierde: het contextvenster is tijdelijk. Niets daarin blijft bewaard tussen aanroepen, tenzij de applicatie dat expliciet beheert. Geheugen over sessies heen moet op de applicatielaag worden geregeld en niet worden verondersteld vanuit het model.
Praktische gevolgen voor engineers
Engineers die op de applicatielaag werken, moeten regelmatig beslissingen nemen over contextbeheer:
- Welke delen van een gesprek te bewaren en welke samen te vatten of weg te gooien
- Hoeveel opgehaalde chunks door te sturen en hoe ze te rangschikken
- Of een groot document op te splitsen of query's te verdelen over kleinere, gerichte aanroepen
- Hoe tool-intensieve agentische taken af te handelen zonder halverwege een tokenlimieten te bereiken
Dit zijn geen configuratiekeuzes. Ze vereisen begrip van wat het model daadwerkelijk doet met de informatie die het ontvangt. Een engineer die het contextvenster simpelweg behandelt als een grotere emmer, produceert doorgaans systemen die traag, duur of onbetrouwbaar zijn onder realistische belasting.
Context engineering is de discipline van het weloverwogen en beredeneerd beslissen wat je in een contextvenster plaatst, hoe je het structureert en wat je weglaat.
Relatie tot andere componenten
Een vectordatabase bestaat mede omdat contextvensters eindig zijn. In plaats van een volledige kennisbank in een prompt te laden, zoeken retrievalsystemen de meest relevante chunks op en geven alleen die door. De kwaliteit van dat ophalen bepaalt direct waarover het model kan redeneren.
In agentic coding-omgevingen bepaalt het contextvenster ook hoeveel van een codebase een model tegelijk in beeld kan houden. Engineers die aan grote repositories werken, moeten bewust kiezen welke bestanden, functies of diffs ze meenemen.
Waar we op testen
Een context window goed beheren is iets waar we in onze beoordeling van engineers specifiek op letten. In de hoe we vetten AI-native beoordeling scoren we prompt and context engineering precies hierop: of een engineer de taakontext zo inricht dat de tool bruikbare output produceert, in plaats van alles wat beschikbaar is mee te geven en opnieuw te prompten als het mislukt. We kijken ook naar spec-driven development, omdat een engineer die een vaag ticket opsplitst in goed afgebakende onderdelen dezelfde soort beslissing neemt: kiezen wat het model nodig heeft en weglaten wat het niet nodig heeft.
Korte antwoorden
Leidt een groter contextvenster tot betere resultaten?
Niet automatisch. Grotere vensters verhogen de kosten en latentie, en modellen kunnen informatie die diep in lange prompts is begraven uit het oog verliezen. Zorgvuldige selectie van wat de context ingaat, is vaak belangrijker dan de absolute venstergrootte.
Wat gebeurt er als je het contextvenster overschrijdt?
De API geeft een foutmelding, of de provider kapt de invoer stilzwijgend af, afhankelijk van de implementatie. In beide gevallen gaat er content verloren. Engineers moeten dit geval expliciet afhandelen in productiesystemen en het niet beschouwen als een randgeval.
Is de contextvenstergrootte hetzelfde bij alle modellen?
Nee. Die verschilt aanzienlijk per model en versie, van een paar duizend tokens tot meer dan een miljoen in sommige gevallen. De relevante limiet voor jouw systeem is het model dat je daadwerkelijk aanroept, niet het grootste getal dat je ergens hebt zien staan.
