--- title: "Je browsertool eet je context op" date: 2026-09-19 author: "Redactie Promptcoaching" featured_image: "https://promptcoaching.nl/wp-content/uploads/2026/09/playwright-cli-mcp-contextvenster-tokens.png" categories: - name: "AI en strategie" url: "/category/ai-en-strategie.md" --- # Je browsertool eet je context op Je vraagt je agent om één ding: log in op dat testaccount en kijk of de knop “Bestellen” nog werkt. Negen handelingen verderop staat het antwoord op je scherm, en je contextvenster is voor de helft gevuld met een voorleesbeurt van de hele pagina. Elke knop, elk menu-item, elke cookiemelding. De agent heeft ze allemaal gelezen om er twee te gebruiken. ## Twee installatieregels, één belofte Vrijdagnacht om 23:35 UTC zette Microsoft versie 0.1.21 van `@playwright/cli` op npm, tweeënhalve minuut later versie 0.0.82 van `@playwright/mcp`. Zesentwintig minuten later postte het Playwright-account [een lijstje van twaalf dingen](https://x.com/playwrightweb/status/2101099626401067367) die je agent krijgt, met erboven: “Playwright MCP or Playwright CLI: pick either.” Twee installatieregels eronder, en verder geen woord over het verschil. Hun eigen documentatie is een stuk minder vrijblijvend. De README van playwright-mcp zet de twee tegenover elkaar en kiest partij: moderne coding agents geven de voorkeur aan de CLI [“because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context”](https://github.com/microsoft/playwright-mcp). MCP blijft volgens diezelfde tekst nuttig voor verkennend werk en langlopende loops, “where maintaining continuous browser context outweighs token cost concerns”. Dat is geen keuzemenu. Dat is een aanbeveling met een rekening eronder. De [CLI-documentatie](https://playwright.dev/agent-cli/introduction) zet het in een tabel. CLI: geschikt voor coding agents zoals Claude Code en Copilot die met een grote codebase werken, tokenkosten “lower”, standaard headless. MCP: geschikt voor gespecialiseerde agentloops, tokenkosten “higher”, standaard met zichtbaar scherm. Wie de tweet leest denkt dat het om smaak gaat. Wie de tabel leest weet dat het om je contextvenster gaat, en dat is precies waar je bij [prompt coaching](https://promptcoaching.nl/) het vaakst tegenaan loopt. ## Een jaar geleden was dit uitdrukkelijk jouw probleem Het aardige is dat je kunt nalezen wanneer dit team van mening veranderde. In augustus 2025 opende een gebruiker [issue 889](https://github.com/microsoft/playwright-mcp/issues/889): zijn tokenverbruik was tussen twee versies met zes vermenigvuldigd voor dezelfde taak, en hij vroeg om een knop om de uitvoer korter te zetten. Op 7 september 2025 antwoordde Playwright-maintainer Pavel Feldman: [“We aren’t considering the ‘cost’ or the ’tier limitations’ at this point since the landscape is changing too fast. Yes, it will consume tokens, but as long as it produces add value we are fine with it.”](https://github.com/microsoft/playwright-mcp/issues/889#issuecomment-3264149677) En daarna: “I don’t think we’ll be adding a way to limit the number of tokens in replies.” Zijn tip aan de klagers was om subagents te gebruiken, elk met hun eigen context, en om een agentic loop te kiezen die goed samenvat. Dat was geen “niet mijn probleem”, het was “los het op in je eigen opzet”. Ruim een jaar later is de eerste kernfunctie in de README van de nieuwe CLI: [“Token-efficient. Does not force page data into LLM.”](https://github.com/microsoft/playwright-cli) Datzelfde verbruik dat toen geen overweging was, is nu het verkoopargument. Dat is geen verwijt, want gelijk krijgen duurt nu eenmaal even. Maar het zegt wel iets over hoe je zulke aankondigingen moet lezen: de kosten die een leverancier vandaag wegwuift, zijn het probleem dat hij volgend jaar oplost. ## Zoeken in plaats van voorlezen Het onderdeel dat in de tweet één regel krijgt, is technisch het interessantst. Beide routes hebben nu een zoekopdracht over de paginastructuur: `playwright-cli find "Add to cart"`, of in de MCP-variant de tool `browser_find`. Die geeft volgens de README alleen de treffers terug met een paar regels eromheen, [“which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref”](https://github.com/microsoft/playwright-mcp). Je kunt er ook een reguliere expressie in kwijt, dus `find --regex "\$[0-9]+\.[0-9]{2}"` haalt alle prijzen van een pagina zonder de rest te lezen. Let op wat daar gebeurt. Feldman schreef in 2025 dat de tool niet slim moet worden: de snapshot hoort compleet naar het model, en het model vat maar samen. Die regel staat nog overeind. `find` kort niets af en vat niets samen. Het model zegt zelf wat het zoekt, en krijgt alleen dat. Geen ommezwaai in principe dus, wel in prioriteit, en voor jouw contextvenster is dat het enige wat telt. ## Het enige cijfer dat rondzingt is niet onafhankelijk Hoeveel scheelt het? Het getal dat overal langskomt is ongeveer 27.000 tokens via de CLI tegen ongeveer 114.000 via MCP, vier keer minder, en het staat in [een vergelijking van drie browsertools van 27 maart 2026](https://www.ytyng.com/en/blog/ai-browser-automation-tools-comparison-2026). Dat klinkt mooi. Nu de eerlijkheid die erbij hoort, want wij citeren het zelf ook. Lees die vergelijking door en je ontdekt dat geen van beide getallen van de auteur zelf is. Ze staan allebei in zijn bronnenlijst onder één titel: “Playwright MCP Burns 114K Tokens Per Test. The New CLI Uses 27K”, een Medium-artikel over een taak van tien stappen. Zijn eigen test draaide negen handelingen inclusief inloggen en een cookiemelding, en daar publiceert hij geen tokentotaal bij. Hetzelfde geldt voor het derde cijfer dat hij noemt, de 200 tot 400 tokens waarmee agent-browser van Vercel Labs een pagina zou weergeven: ook dat verwijst hij door naar twee andere blogs. Eén verwijzing klopt aantoonbaar niet. Hij noemt 13.700 tokens per verzoek alleen al aan tool-omschrijvingen en zet er issue 889 bij als bron. In dat issue komt 13.700 nergens voor. Het enige tokengetal dat er staat is van een gebruiker die meldt dat één screenshot hem 15k tokens kostte. Wat wél uit zijn eigen handen komt en het nuttigst is: de snapshot is ook in de CLI nog altijd 13.000 tokens of meer, en het wordt pas werkbaar als je er gericht in zoekt. Wie op grond van “vier keer zuiniger” zijn hele opstelling omgooit, leunt dus op cijfers uit een test die hij niet gelezen heeft. Precies het soort getal waar we in de [promptgidsen](https://promptcoaching.nl/promptgidsen/) steeds voor waarschuwen. ## Meet je eigen verbruik voor je iets omgooit Doe dit bij je volgende browsertaak: laat je agent één pagina openen en vraag daarna hoeveel van je context al op is, nog voor er iets geklikt is. Draait er een MCP-server, dan zijn de tool-omschrijvingen al binnen voordat je iets vroeg. Dat is je vaste last. Vergelijk hem met dezelfde taak via `npm i -g @playwright/cli@latest` en drie shell-aanroepen, en je weet binnen tien minuten of dit voor jouw werk uitmaakt of niet. Hetzelfde principe als bij [Codex contextbeheer](https://promptcoaching.nl/codex-contextbeheer/): eerst meten waar je venster aan opgaat, dan pas knoppen omzetten. Werk je veel met dezelfde modellen, dan loont het om die meting per model te doen. Een tool-schema van een paar duizend tokens weegt anders bij een venster van 200.000 dan bij een miljoen, en de verschillen tussen aanbieders staan per model uitgewerkt in de [Claude prompt engineering](https://promptcoaching.nl/promptgidsen/)-gids en de [GPT-5.3 Codex prompting guide](https://promptcoaching.nl/promptgidsen/). ## Versienummer 0.1.21 is geen 1.0 De CLI staat na dertig releases sinds januari nog altijd op 0.1.21, en de WebMCP-functie die in hetzelfde lijstje wordt genoemd heet in beide README’s letterlijk experimenteel. Verschijnt er een 1.0 met een vaste commandostructuur, dan is dit een route om je scripts op te bouwen. Blijft het versienummer hangen onder de 1, dan is elke shell-aanroep die je vandaag vastlegt iets wat je over drie maanden opnieuw schrijft.