# Waarom ik agent-browser verkies boven Playwright en Chrome MCP

> Browser-automation voor je agent kan zonder je context op te vreten. agent-browser is een CLI in plaats van een MCP, kost ~200 tokens per pagina, en laat je een hele verifieer-flow in een skill bakken. Plus alle features op een rij.

juli 2026 · slechts 5 min lezen
Tags: ai, agents, tokens, browser

De browser is voor mij de ultieme manier om te checken of iets écht werkt. Niet een test die groen kleurt omdat de mock precies doet wat je 'm influistert, maar daadwerkelijk door de flow klikken: inloggen, formulier invullen, doorklikken, kijken of het eindscherm klopt. Sinds de modellen beter zijn geworden laat ik m'n agent dat doen, en ik ben overgestapt van de browser-MCP's (Playwright of Chrome) naar [agent-browser](https://agent-browser.dev/).

## Reden 1: het is een CLI, geen MCP

Een MCP (zoals de Playwright- of Chrome-MCP) laadt z'n hele tool-schema permanent in je context. Elke tool, elke parameter, elke beschrijving staat er vanaf de eerste token in, of je 'm nou gebruikt of niet. Dat vreet veel tokens.

agent-browser is gewoon een CLI. Een bash-commando dat de agent kan aanroepen zonder dat er iets in z'n context hoeft te staan. Je typt bijvoorbeeld `agent-browser open example.com` en klaar. Geen schema, geen overhead. En omdat het bash is, kan ik er een hook voor zetten die de output bijknipt, precies zoals ik met [rtk](/posts/rtk-context) doe voor m'n dev-commando's.

## Reden 2: het kost veel minder tokens

De kern is de snapshot. In plaats van de volle DOM (3000-5000 tokens aan div-soep) geeft agent-browser je een accessibility-tree met compacte refs:

```
Page: Example - Log in
URL: https://example.com/login

@e1 [heading] "Log in"
@e2 [form]
  @e3 [input type="email"] placeholder="Email"
  @e4 [input type="password"] placeholder="Password"
  @e5 [button type="submit"] "Continue"
```

Dat is ongeveer 200-400 tokens per pagina. De agent leest dit, pakt de ref die-ie nodig heeft, en klikt met `agent-browser click @e5`. Deze simpele loop maakt dat alles lichtgewicht kan gebeuren: `open` → `snapshot -i` → `click @e3` → opnieuw snapshotten en repeat.

Een [benchmark die ytyng deed](https://www.ytyng.com/en/blog/ai-browser-automation-tools-comparison-2026) vangt dit verschil: dezelfde 10-staps-taak kostte via de **Playwright MCP zo'n 114k tokens**, via de **Playwright CLI ~27k**, en agent-browser komt daar met z'n **200-400 tokens per pagina** ruim onder. De conclusie van de schrijver was dat agent-browser "overwhelmingly superior" is als je op tokens let. En dat merk ik zelf ook: doordat m'n context schoon blijft, blijft de agent langer scherp en blijf ik langer binnen m'n usage.

## Reden 3: ik bak een hele verifieer-flow in een skill

Dit is waar het voor mij samenkomt. Omdat het gewoon bash is, kan ik een complete flow van login tot eindscherm in een skill zetten. De agent draait 'm van begin tot eind af en checkt of de uitkomst klopt. Een soort e2e-test, maar dan bruikbaar voor de AI zelf, of tijdelijk voor precies één verificatie die ik nu even nodig heb en daarna weer weggooi.

agent-browser heeft hier zelfs een kant-en-klare skill voor: `dogfood`. Die klikt systematisch door je hele app, vindt bugs en UX-issues, en levert een rapport op met per bevinding de volledige manier om te reproduceren: stap-voor-stap screenshots, een repro-video en de exacte stappen. 

agent-browser heeft sowieso [skills](https://agent-browser.dev/skills) waardoor je agent van het bestaan van agent-browser weet.

## Reden 4: vol met features

En naast dat je browser-automation dan geen MCP meer is, zit het vol met features die het gemakkelijker maken om ermee te werken. Een greep uit wat er allemaal in zit.

### Dingen die ik heul vet vind
- Een **dashboard** op poort 4848 (`dashboard start`): een observability-UI waar je de sessie live kunt volgen, inclusief AI-chat als je een gateway-key hebt.
- Live streamen van de sessie via WebSocket (`stream enable`).
- Video-opname (`record start/stop`, WebM), Chrome DevTools trace en profiler, console-logs en page-errors uitlezen, elementen highlighten, DevTools openen (`inspect`), en clipboard lezen/schrijven.
- Met `--enable react-devtools`: de volledige component-tree (`react tree`), één fiber inspecteren (props, hooks, state, source), re-renders profileren (`react renders`), en Suspense-boundaries in kaart brengen.
- Core Web Vitals meten (`vitals`: LCP/CLS/TTFB/FCP/INP), inclusief React-hydration-timing.

### Dingen die het krachtig maken
- Wachten op een element, op tekst (`--text "Success"`), op een URL-patroon (`--url "**/dashboard"`), op network-idle, op DOMContentLoaded, of op een JS-conditie (`--fn`).
- `diff snapshot` (huidige vs vorige), `diff screenshot --baseline` (visuele regressie), of `diff url` (twee pagina's vergelijken).
- Requests onderscheppen en muten (`network route --abort` / `--body`), requests loggen en filteren, en HAR-opname (`network har start/stop`).
- Offline-modus, custom headers, credentials, geolocatie en viewport/device faken (`set device "iPhone 15 Pro"`).
- Een auth-vault: credentials één keer opslaan (`auth save`), daarna `auth login my-app` en het vult + klikt zelf. Geen wachtwoorden in je shell-history.
- Login bewaren tussen runs met `state save` / `state load`, of een Chrome-profiel hergebruiken (`--profile Default`), of gewoon aanhaken bij een al draaiende Chrome (`--auto-connect`).
- Geïsoleerde sessies naast elkaar (`--session`), zodat je meerdere flows parallel kunt draaien.
- Een `chat`-commando: natuurlijke taal erin (`chat "open google en zoek katten"`), agent-browser vertaalt het naar acties.

### Standaard dingen die je verwacht
- Klikken, hoveren, focussen, draggen, uploaden, downloaden, muis rondbewegen
- Elementen vinden, semantische locators waar geen snapshot voor nodig is (`find role button --name "Submit"`)
- Kijken en lezen (met text, html etc.) of screenshots

## Het voorbehoud

Het is wel nog erg jong (ik draai v0.27), dus je komt af en toe een ruw randje tegen. De refs uit een snapshot verlopen zodra de pagina verandert, dus je moet consequent her-snapshotten na elke klik die iets doet, vergeet je dat, dan klik je mis. En voor zwaar gescripte test-suites zou ik alsnog naar Playwright grijpen; agent-browser is op z'n best als de agent zelf door een flow moet klikken, niet als je een dichtgetimmerde regressie-suite bouwt.

## Kortom

Als jij je agent ook door de browser laat klikken om te verifiëren dat iets werkt, en je merkt dat je context vol loopt of dat je usage eraan gaat: probeer agent-browser eens naast je MCP. Het is een CLI, dus je zet 'm zo naast wat je al hebt. Ik ben benieuwd of jij dezelfde winst ziet op tokens als ik, en het fijner vind werken.