Twee jaar geleden was een contextvenster van 8.000 tokens normaal. In 2026 draaien de topmodellen routineus op een miljoen tokens. Dat klinkt als een getallenbrei, maar het verandert fundamenteel wat je met een taalmodel kan. Laten we uitpakken wat dat concreet betekent en waar de grenzen nog zitten.
Wat is een token eigenlijk?
Een token is een brokje tekst, meestal rond de vier karakters of driekwart woord in het Engels. Een miljoen tokens komt overeen met zo'n 750.000 woorden. Ter vergelijking: het volledige boek Oorlog en Vrede is ongeveer 560.000 woorden. Je stopt dus een roman van dat formaat plus nog een flink essay als bonus in één enkele prompt.
Voor code is de conversie iets anders. Een miljoen tokens dekt ruwweg 50.000 tot 80.000 regels code, afhankelijk van de taal en comment-dichtheid. Dat is ongeveer het formaat van een middelgrote webapplicatie.
Waarom dit niet zomaar meer van hetzelfde is
Meer context lijkt kwantitatief, maar het onderliggende verschil is kwalitatief. Bij 8.000 tokens moest je het model constant dezelfde achtergrond opnieuw voeren. Bij 200.000 tokens kon je al een hele documentatie set bijleveren. Bij een miljoen tokens stop je er je complete codebase, je volledige productspec, of een hele kwartaalrapportage in.
Dat betekent dat je workflows die vroeger afhankelijk waren van Retrieval Augmented Generation (RAG) kan vervangen door direct alles meesturen. Geen vectordatabase nodig, geen chunking-logica, geen zorgen over welke fragmenten wel of niet relevant zijn. Je geeft het model simpelweg alles.
De kosten van zulke vensters
De keerzijde is de prijs. Tokens zijn niet gratis. Een lange context vullen kost geld, en het kost latency. Een prompt van een miljoen tokens kan tientallen seconden nodig hebben voor de eerste token eruit komt. Voor chatbots die snel moeten reageren, is dat geen optie. Voor langlopende analysetaken is het een koopje.
Prompt caching verzacht het probleem flink. Als je dezelfde grote context meerdere keren bevraagt, cachen de aanbieders die content achter de schermen. Een cached request is typisch 90% goedkoper en veel sneller dan een cold request. Wie slim caches inzet, betaalt de hoge prijs alleen bij de eerste vraag.
Waar loopt het nog spaak?
Een miljoen tokens kunnen lezen is niet hetzelfde als ze allemaal even scherp verwerken. Modellen vertonen wat onderzoekers lost-in-the-middle noemen: informatie aan het begin en eind van een lange prompt wordt beter onthouden dan wat in het midden staat. Moderne modellen worstelen daar veel minder mee dan een jaar geleden, maar het is nog niet verdwenen.
Voor productie workflows betekent dat: plaats kritieke instructies aan het einde van je prompt, vat lange documenten samen in plaats van ze letterlijk in de prompt te duwen, en toets bij specifieke taken of het model echt alle details heeft opgepikt.
Praktische use cases
Waar glanzen miljoen-token contexten echt? Een paar concrete voorbeelden:
- Codebase analyse. Gooi een hele repo in, vraag waar een bug zit of waar een refactor zinnig is.
- Contractreview. Laad honderden pagina's aan juridische documenten en laat het model risico's en inconsistenties eruit halen.
- Wetenschappelijke meta-analyses. Stop dertig papers in één prompt en vraag om de gedeelde methodologische zwaktes.
- Productanalyse. Lever alle release notes, user feedback en support tickets tegelijk aan en vraag waar de prioriteiten moeten liggen.
Voor een voorbeeld van hoe deze generatie modellen presteert op real-world taken, zie onze review van Claude Opus 4.7.
Wat komt hierna?
De volgende stap is niet simpelweg twee miljoen tokens. De echte winst zit in efficiëntie: goedkopere verwerking, snellere time-to-first-token en betere attention over lange afstanden. De race gaat nu over hoeveel je kan ophoesten binnen een acceptabele latency en kostprijs, niet over theoretische maxima.
Voor wie deze tools professioneel inzet, is het goed nieuws. De ruwe capaciteit is er. De komende jaren gaat het over hoe je die slim benut. Meer technische achtergrond vind je in deze benchmark-analyse van Opus 4.7.
