TL;DR
- Wat: Cursor 3.3 toont een overzicht van hoe je AI-agent zijn contextvenster verbruikt — uitgesplitst naar rules, skills, MCP's en subagents.
- Waarom relevant: Als ondernemer met een ontwikkelteam wil je weten waarom je AI-tools soms haperen; dit maakt zichtbaar waar de bottleneck zit.
- Wat je ermee kunt: Vraag je ontwikkelaar om de context-breakdown te checken en de setup aan te scherpen zodat de agent effectiever werkt.
Ik stuitte op een bericht van Cursor — de AI-code-editor die steeds meer terrein wint onder ontwikkelaars — over hun versie 3.3. Op zich klinkt "context usage breakdown" niet als iets waar je als ondernemer wakker van ligt. Maar als je beseft dat dit direct invloed heeft op hoe goed (of slecht) een AI-tool code schrijft voor jouw bedrijf, wordt het ineens een stuk interessanter.
Wat is er precies veranderd?
Cursor is een code-editor die AI-agents inzet om softwareontwikkeling te versnellen. Met versie 3.3, uitgebracht op 6 mei 2026, kun je nu precies zien hoe je agent zijn beschikbare "context" verbruikt. Dat overzicht is uitgesplitst in vier categorieën:
- Rules — de instructies die je aan de agent meegeeft
- Skills — gespecialiseerde kennis en workflows die de agent kan inzetten
- MCP's (Model Context Protocol servers) — externe tools en databronnen die de agent kan raadplegen
- Subagents — onafhankelijke deel-agents die parallel taken uitvoeren
Denk aan context als het werkgeheugen van de AI. Net zoals je zelf maar een beperkt aantal dingen tegelijk kunt onthouden tijdens een vergadering, heeft een AI-model een vast venster waarbinnen het informatie kan verwerken. Alles wat je erin stopt — instructies, bestanden, gespreksgeschiedenis — concurreert om dezelfde ruimte.
Waarom "context" ertoe doet
Hier wordt het voor mij pas echt interessant. Uit wat ik erover lees, blijkt dat het verschil tussen het geadverteerde contextvenster en de daadwerkelijk bruikbare ruimte aanzienlijk is. Volgens analyses op Morph verbruikt Cursor zelf al een flink deel van het venster voor systeeminstructies, zoekresultaten uit de codebase en automatisch meegeladen bestanden. Het bruikbare deel kan 50 tot 75 procent kleiner zijn dan wat er op papier staat.
Stel dat je als ondernemer een vergaderruimte huurt voor twintig personen. Je komt binnen en ziet dat er al tien stoelen bezet zijn door de cateraar, de geluidsinstallatie en de notulist. Je hebt nog maar tien plekken over voor je eigen team. Zo werkt het bij AI-context ook — en tot nu toe was het voor de meeste gebruikers onduidelijk wie er precies op die stoelen zat.
Dat maakt deze update waardevol: je kunt nu zien waar je ruimte naartoe gaat.
Wat betekent dit voor je ontwikkelteam?
Als je een softwareteam hebt — intern of extern — dat met Cursor werkt, is dit een praktisch handvat. Een paar dingen die deze breakdown zichtbaar kan maken:
Te veel rules, te weinig ruimte
Rules zijn de instructies die je aan de AI meegeeft over hoe hij moet werken. Denk aan codeerstandaarden, projectafspraken, of stijlvoorkeuren. Het is verleidelijk om die lijst steeds langer te maken. Maar elke regel vreet context. Als de breakdown laat zien dat 40 procent van je venster opgaat aan rules, weet je dat je moet snoeien.
MCP's die onnodig meeladen
MCP-servers zijn externe koppelingen — denk aan een database, een API, of een documentatiebron. Cursor 3.3 laadt MCP's nu alleen wanneer de agent ze écht nodig heeft, wat al scheelt. Maar met de breakdown kun je controleren of dat in de praktijk ook zo werkt. Worden er MCP's geladen die voor jouw specifieke taak irrelevant zijn? Dan kost dat context die beter besteed kan worden.
Subagents die meer ruimte innemen dan verwacht
Subagents zijn een relatief nieuw concept in Cursor. Het zijn zelfstandige deel-agents die elk hun eigen context hebben en parallel taken uitvoeren — bijvoorbeeld code onderzoeken, commando's draaien, of meerdere werkstromen tegelijk afhandelen. Handig, maar als je niet oplet kunnen ze gezamenlijk meer ruimte innemen dan je denkt.
De bredere trend: zichtbaarheid in AI-kosten
Wat mij opvalt aan deze update is dat het past in een breder patroon. Steeds meer AI-tools geven gebruikers inzicht in wat er onder de motorkap gebeurt. Niet alleen qua geld — wat kost een API-call — maar ook qua technische resources: hoeveel context gebruik je, hoe efficiënt is je setup, waar zitten de knelpunten?
Ik vind dat een gezonde ontwikkeling. Voor ondernemers die AI inzetten in hun bedrijfsprocessen, is het belangrijk om niet alleen te weten dat iets werkt, maar ook hoe efficiënt het werkt. Een AI-agent die de helft van zijn werkgeheugen besteedt aan overbodige instructies is vergelijkbaar met een medewerker die de helft van de werkdag bezig is met het lezen van procedures die niet relevant zijn voor de taak.
Volgens Cursor's eigen best practices is het advies inmiddels om juist minder context vooraf mee te geven en de agent zelf de relevante bestanden te laten vinden. Dat klinkt tegenstrijdig — je zou denken dat meer informatie beter is — maar door het beperkte venster is selectiviteit effectiever dan volledigheid.
Moet je hier als ondernemer iets mee?
Als je bedrijf geen software ontwikkelt, is dit niet direct relevant. Maar als je een ontwikkelteam hebt dat AI-tools inzet — en dat worden er steeds meer — dan is het goed om te weten dat dit soort optimalisaties bestaan. Het verschil tussen een goed geconfigureerde en een slecht geconfigureerde AI-agent kan het verschil zijn tussen een taak die in vijf minuten klaar is en een taak die vastloopt of onbruikbare output oplevert.
Kun je je voorstellen wat dat betekent als je tien ontwikkelaars hebt die dagelijks met zo'n tool werken? Kleine inefficiënties vermenigvuldigen snel.
Ik zou zelf willen weten: hoeveel van dit soort onzichtbare verspilling zit er in de AI-tools die we nu gebruiken, zonder dat we het doorhebben?
Tot slot
Voor mij is dit vooral een signaal dat AI-tooling volwassener wordt. We gaan van "kijk, de AI kan code schrijven" naar "laten we ervoor zorgen dat de AI dat zo efficiënt mogelijk doet." Dat is precies de fase waarin het voor bedrijven interessant wordt om er serieus naar te kijken — niet als speeltje, maar als gereedschap dat je goed moet onderhouden en afstellen.