Le benchmark révèle que les outils d'automatisation de navigation par IA varient jusqu'à 2,6 fois en coût de tokens, malgré une précision identique.

Résultats du benchmark : Même précision, coûts différents

Un benchmark a testé 4 outils d'automatisation de navigateur en CLI utilisant le même modèle (Claude Sonnet 4.6) sur 6 tâches réelles contre des sites web en direct. Tous les outils ont obtenu 100% de précision sur 18 exécutions de tâches, mais l'utilisation de tokens a varié considérablement :

• openbrowser-ai : 36 010 tokens / 84,8 s / 15,3 appels d'outils
• browser-use : 77 123 tokens / 106,0 s / 20,7 appels d'outils
• playwright-cli (Microsoft) : 94 130 tokens / 118,3 s / 25,7 appels d'outils
• agent-browser (Vercel) : 90 107 tokens / 99,0 s / 25,0 appels d'outils

Openbrowser-ai a utilisé 2,1 à 2,6 fois moins de tokens que les autres outils. Le benchmark a révélé que le nombre d'appels d'outils est le prédicteur le plus fort du coût en tokens car chaque appel force le LLM à retraiter l'intégralité de l'historique de la conversation.

Comment les outils diffèrent dans leur implémentation

Les quatre outils maintiennent des sessions de navigateur persistantes via des démons en arrière-plan, peuvent exécuter JavaScript côté serveur et renvoyer uniquement le résultat, travaillent à rendre l'état de la page compact, et prennent en charge une forme d'exécution de code.

browser-use expose des commandes CLI individuelles : open, click, input, scroll, state, eval. Le LLM émet une commande par appel d'outil. eval exécute JavaScript dans le contexte de la page. L'état de la page est un arbre DOM amélioré avec des indices [N] à environ 880 caractères par page. Il communique avec Chrome via CDP direct via leur bibliothèque cdp-use.

agent-browser suit un schéma similaire : open, click, fill, snapshot, eval. C'est un binaire natif Rust qui communique directement avec Chrome via CDP. L'état de la page est un arbre d'accessibilité avec des références u/eN. Le drapeau -i produit une sortie compacte interactive uniquement d'environ 590 caractères. Les commandes peuvent être enchaînées avec && mais chacune reste une requête distincte au démon.

playwright-cli propose des commandes individuelles plus run-code, qui accepte du JavaScript Playwright arbitraire avec un accès complet à l'API. Le LLM peut écrire du code comme run-code "async page => { await page.goto('url'); await page.click('.btn'); return await page.title(); }" et exécuter plusieurs opérations en un seul appel. L'état de la page est un arbre d'accessibilité enregistré dans des fichiers .yml d'environ 1 420 caractères, avec des captures incrémentielles qui n'envoient que les différences après la première lecture.

openbrowser-ai n'a aucune commande individuelle. La seule interface est le code Python via -c :

openbrowser-ai -c 'await navigate("https://en.wikipedia.org/wiki/Python") info = await evaluate("document.querySelector('.infobox')?.innerText") print(info)'

navigate, click, input_text, evaluate, scroll sont des fonctions Python asynchrones dans un espace de noms persistant. L'état de la page est un DOM avec des indices [i_N] d'environ 450 caractères. Les variables persistent entre les appels comme dans un notebook Jupyter.

Le benchmark a observé que le LLM a effectué moins d'appels d'outils avec OpenBrowser (15,3 contre 20-26 pour les autres outils), ce que les auteurs attribuent à l'interface uniquement en code qui encourage naturellement le regroupement des opérations.