ベンチマークによると、AIブラウザ自動化ツールは、同一の精度にもかかわらず、トークンコストが2.6倍も異なることが示されています。

ベンチマーク結果：同じ精度、異なるコスト

同じモデル（Claude Sonnet 4.6）を使用して、4つのCLIブラウザ自動化ツールを、実稼働中のウェブサイトに対する6つの実世界タスクでテストしたベンチマークが実施されました。すべてのツールは18回のタスク実行で100%の精度を記録しましたが、トークン使用量は劇的に異なりました：

• openbrowser-ai: 36,010トークン / 84.8秒 / 15.3回のツール呼び出し
• browser-use: 77,123トークン / 106.0秒 / 20.7回のツール呼び出し
• playwright-cli（Microsoft）: 94,130トークン / 118.3秒 / 25.7回のツール呼び出し
• agent-browser（Vercel）: 90,107トークン / 99.0秒 / 25.0回のツール呼び出し

Openbrowser-aiは他のツールよりも2.1倍から2.6倍少ないトークンを使用しました。このベンチマークでは、ツール呼び出し回数がトークンコストの最も強力な予測因子であることがわかりました。なぜなら、各呼び出しがLLMに会話履歴全体を再処理させるからです。

実装方法におけるツールの違い

4つのツールすべてが、バックグラウンドデーモンによる永続的なブラウザセッションを維持し、サーバーサイドでJavaScriptを実行して結果のみを返し、ページ状態をコンパクトにすることに取り組み、何らかの形式のコード実行をサポートしています。

browser-useは個別のCLIコマンドを公開します：open、click、input、scroll、state、eval。LLMはツール呼び出しごとに1つのコマンドを発行します。evalはページコンテキストでJavaScriptを実行します。ページ状態は、ページあたり約880文字の[N]インデックス付きの拡張DOMツリーです。cdp-useライブラリを介してChromeと直接CDPで通信します。

agent-browserは同様のパターンに従います：open、click、fill、snapshot、eval。これはChromeと直接CDPで通信するネイティブのRustバイナリです。ページ状態はu/eN参照付きのアクセシビリティツリーです。-iフラグは約590文字のコンパクトなインタラクティブ専用出力を生成します。コマンドは&&で連結できますが、それぞれが依然として個別のデーモンリクエストです。

playwright-cliは個別のコマンドに加えて、完全なAPIアクセスを持つ任意のPlaywright JavaScriptを受け入れるrun-codeを提供します。LLMはrun-code "async page => { await page.goto('url'); await page.click('.btn'); return await page.title(); }"のようなコードを記述し、1回の呼び出しで複数の操作を実行できます。ページ状態は約1,420文字の.ymlファイルに保存されるアクセシビリティツリーで、最初の読み取り後の差分のみを送信するインクリメンタルスナップショットを備えています。

openbrowser-aiには個別のコマンドがまったくありません。唯一のインターフェースは-cを介したPythonコードです：

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は、永続的な名前空間内の非同期Python関数です。ページ状態は約450文字の[i_N]インデックス付きDOMです。変数はJupyterノートブックのように呼び出しをまたいで保持されます。

このベンチマークでは、LLMがOpenBrowserでは他のツール（20〜26回）と比べて少ないツール呼び出し（15.3回）を行ったことが観察されました。著者らは、コード専用インターフェースが操作のバッチ処理を自然に促すためだと指摘しています。