L'intuition de base est simple : donner un navigateur à un agent, c'est donner un outil. Ce que personne ne mesure, c'est combien cet outil parle. Chaque tool call est un round-trip. Chaque round-trip empile des tokens dans le contexte. Et selon l'outil que tu as choisi ce matin-là, tu paies entre $0.074 et $0.120 pour la même tâche.
@kunchenguid a passé 915 runs à mesurer exactement ça.
Deux scénarios sur la homepage de Mozilla. Le premier : naviguer et vérifier du contenu. Le second : les mêmes assertions, mais certaines incorrectes, pour forcer l'agent à corriger sa trajectoire.
Chaque condition répétée 5 fois pour absorber la variance des LLMs. Sept outils browser testés. Les métriques retenues : coût total en tokens, latence, nombre de tool calls.
Le scénario 2 est le vrai stress test. Quand l'agent doit se corriger, les outils qui génèrent beaucoup de tool calls s'effondrent. Agent-browser peut monter jusqu'à 600 secondes de runtime sur ce cas. Playwright MCP reste entre 80 et 150 secondes.
Tu ne paies pas pour ce que tu penses
L'hypothèse naturelle quand on pense "optimisation de tokens" : moins de tokens dans les outputs, moins de coût. C'est insuffisant.
Ce benchmark montre que le nombre de tool calls est souvent le facteur dominant. Chaque appel outil génère un round-trip complet vers le modèle, qui reçoit le résultat, le digère, et décide de l'appel suivant.
Sur le même scénario, un outil CLI peut générer 50 tool calls là où MCP en génère 14.
La relation n'est pas linéaire pour autant. Moins de tool calls ne garantit pas moins cher, parce que chaque appel peut renvoyer un output massif. C'est le trade-off central que le benchmark tiers de Ranger a aussi mesuré indépendamment sur Playwright MCP : fewer tokens, hidden cost.
Coût par tâche▼
$0.074
AXI (chrome-devtools-axi)
Coût par tâche▲
$0.120
chrome-devtools-mcp-code (baseline)
Coût par tâche◆
$0.078
dev-browser
Runs au total◆
915
2 benchmarks, 5 répétitions par condition
AXI : quand l'interface est pensée pour l'agent
AXI (Agent eXperience Interface) est la contribution principale de @kunchenguid à cet écosystème. Techniquement, chrome-devtools-axi tourne chrome-devtools-mcp sous le capot. Les capacités sont quasi-identiques. Ce qui diffère : l'interface exposée à l'agent.
Le projet documente 10 principes de design sur axi.md. L'idée centrale : les CLIs pour agents obéissent à des contraintes radicalement différentes de celles d'un CLI humain. Un humain lit les erreurs. Un agent les parse. Un humain tolère la verbosité. Un agent la paie en tokens.
Trois leviers concrets expliquent l'écart de coût entre AXI et sa baseline MCP :
Format de sortie. AXI utilise TOON (Tree Object Notation), un format structuré dense. Kun Chen précise dans les réponses du thread que TOON est donné en input à l'agent, jamais demandé en output, ce qui évite les problèmes d'adhérence.
Chaînage d'outils. Certaines opérations qui nécessitent 3 tool calls séparés dans d'autres outils sont fusionnées en 1 dans AXI. Moins de round-trips, moins de tokens de contexte accumulés.
Commandes ergonomiques supplémentaires. Des arguments qui permettent à l'agent de spécifier plus précisément son intention dès le premier appel, réduisant les appels correctifs.
Les alternatives qui méritent d'être sur ton radar
dev-browser de Sawyer Hood tourne dans un sandbox QuickJS WASM. Full API Playwright, $0.078 par tâche dans le benchmark. Aucune dépendance Node.js à installer sur la machine cible, ce qui en fait un angle sérieux pour des environnements contraints.
Kuri est écrit en Zig. Binaire de 464KB, zéro Node.js, 16% moins cher en tokens que les alternatives comparables selon les données disponibles. Pas encore benchmarké dans les 915 runs de Kun Chen, mais la surface d'attaque est minuscule et ça se voit dans les chiffres.
La question que ce benchmark ne pose pas encore : comment ces outils se comportent sur des workflows multi-étapes, au-delà des tâches isolées. Kun Chen le reconnaît directement dans une réponse : trop de permutations de chaînage pour être couvertes dans une première version.
Ce que ça change dans tes choix d'architecture
La conclusion opérationnelle du benchmark dépasse le choix d'AXI. Elle concerne la discipline de sélection d'outils pour agents.
Jusqu'ici, le critère dominant pour choisir un outil browser était la complétude des capacités : gestion des iframes, shadow DOM, uploads de fichiers. Ces critères restent valides, mais ils ignorent la dimension économique de l'interface elle-même.
Un outil qui expose 40 actions granulaires sera toujours plus coûteux qu'un outil qui en expose 15 bien composables, même si les deux accomplissent les mêmes tâches. L'agent choisit parmi ce qu'on lui donne. Si tu lui donnes 40 boutons, il en appuiera davantage.
C'est ce que Kun Chen appelle l'ergonomie agent : une discipline de design à part entière, distincte de l'ergonomie humaine et distincte de la performance brute. Le benchmark tiers de Ranger sur Playwright MCP vs CLI vs agent-browser arrive à la même conclusion par un autre chemin.
La prochaine fois que tu intègres un outil browser dans ta stack agentique, la question n'est pas "est-ce qu'il peut faire X". C'est "combien de tokens il faut à mon agent pour décider de faire X avec cet outil".
