OpenManusのトークン制限とUnknown BrowserUseToolエラー：一方は現存し、もう一方は削除済み

OpenManus はデフォルトではトークン制限を適用しません。 独自の上限は max_input_tokens で、app/config.py では Optional として宣言され、デフォルト値は None、説明は「すべてのリクエストで使用する最大入力トークン数（無制限の場合は None）」です。これは出荷済みの設定例には記載されていません。そのため、標準インストールで独自のトークン制限エラーが発生することはありません。遭遇したものはプロバイダーに由来します。設定した場合は、予想しにくい 2 通りの動作をし、現在の main に存在する不具合によって、すぐに失敗せず遅れて失敗します。

このページで扱うもう一つのエラーである Error: Unknown tool 'BrowserUseTool' は、現在発生しているバグではありません。このエラーが示すクラスは、2026年8月15日に OpenManus から削除されており、現在の main のデフォルトの Manus エージェントは、ローカルでブラウザーツールを一切登録しません。どちらの症状も API キー、エンドポイント、プロバイダーの問題ではなく、base_url の接続先を変更しても、どちらも解決しません。

その前に、位置付けについて 1 点。記載できる OpenManus のバージョンはありません。唯一の 3 つのタグ v0.1.0、v0.2.0、v0.3.0 は、2025 年 4 月 10 日にすべて 34 秒以内の間隔で公開され、それ以降はタグが付けられていないため、全員がタグなしの main を実行しています。正規のリポジトリは FoundationAgents/OpenManus です。アーカイブされておらず、MIT、スター数は 58,371、最終 push は 2026 年 8 月 22 日です（GitHub API、2026 年 9 月 21 日）。旧 mannaandpoem/OpenManus パスは現在、プロジェクトが移転したと記載する README のスタブになっているため、2025 年のチュートリアルに引用されたファイルパスや行番号は、もはや存在しないコードを指します。以下はすべて、2026 年 9 月 21 日に main ブランチのソースで確認したもので、実行は一切していません。

4 つのメッセージのうち、実際に表示されているのはどれか

3 行目を生成するディスパッチは 3 行で、2026 年のブラウザ書き換えによっても変更されていません。name = command.function.name、続いて if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'" です。その中にはブラウザ固有の要素がないため、モデルが作り出したどのツールでも同じ文字列が表示されます。

トークン制限はオプトイン式で、累積的かつ概算です

「トークン制限」と呼ばれる異なる数値が 3 つあり、エラーメッセージが関係するのは常にそのうち 1 つだけです。

2 行目が意外に感じられる部分です。app/llm.py の LLM.check_token_limit() は (self.total_input_tokens + input_tokens) <= self.max_input_tokens を返します。これは 1 つのリクエストに対するチェックではなく、セッションの実行中合計です。そのため、個々のリクエストが小さくても、長いエージェント実行では累積によって上限に達します。エラーテキストには current、needed、max の計算が明記されます。デフォルトの Manus エージェントは max_steps = 20 を設定し、各ステップでそれまでの会話を再送信するため、累積値はステップ数以上の速さで増加します。

このカウントも OpenManus 独自の推定です。LLM.__init__ は tiktoken.encoding_for_model(self.model) を呼び出し、KeyError で cl100k_base にフォールバックします。そのため、tiktoken にプリセットがないモデル ID、つまり Claude や Gemini の ID、またはゲートウェイ名前空間付き ID では、適用される予算はプロバイダーのカウントではなく概算値です。

# config/config.toml
[llm]
model = "claude-sonnet-4-6"
base_url = "https://api.kunavo.com/v1"
api_key = "sk-kn-..."

# The RESPONSE cap. Ships as 8192 in config.example.toml; the code default is 4096.
max_tokens = 8192

# The CUMULATIVE INPUT budget for the whole run. Absent from every shipped
# example, and None in code — so a stock install enforces no ceiling at all.
max_input_tokens = 400000

上限が金額面で意味すること

max_input_tokens は累積入力を制限するため、1 回の実行における入力側のコスト上限に直接換算できます。以下の数値は、記載された上限に基づく例示的なトークン計算であり、実測タスクコストでも請求額の上限でもありません。この設定によって上限が定められる入力トークンを、100 万トークンあたりの現在の Kunavo カタログ料金で価格換算しています。出力はこの設定の対象に一切なりません。最後の列は、サンプル設定に含まれる max_tokens = 8192 で 1 回のレスポンスを価格換算したもので、20 ステップの実行ではこれが 20 回生成される可能性があります。

2 つの見方があります。上限は予算ではなく停止条件です。実行の入力側にかかり得る最大コストを示すだけで、タスクが完了するかどうかは示しません。また、OpenManus は tiktoken で数えるため、適用される上限とプロバイダーが請求するトークンは異なる測定値です。暴走ループを制限するために数値を設定し、その後、アカウントに実際に記録された値と照合してください。Kunavo のカタログ金額は上限ではなく請求の下限です。上流が料金を報告すると、請求額はカタログコストと上流コストに適用されるマークアップを掛けた額の大きい方になります。Kunavo の最小トップアップは前払いクレジット $10 であり、これは資金投入の最低額であって、タスク料金やサブスクリプションではありません。請求の詳細を参照してください。

トークンエラーが遅れて発生する理由

これは現在の main で読み取れる不具合であり、トークン制限の失敗がハングのように感じられる理由です。app/llm.py 内の 3 つの @retry デコレーター（ask、ask_with_images、ask_tool）はすべて同じように記述されています。

下流のエージェントループも、この形を否定するのではなく裏付けています。app/agent/toolcall.py は例外を捕捉して isinstance(e.__cause__, TokenLimitExceeded) を検査します。この __cause__ のアンラップによって tenacity の RetryError が到達し、独自のログ行には「Token limit error (from RetryError)」と表示されます。その後で初めて、ユーザーに表示する「Maximum token limit reached, cannot continue execution」メッセージを追加し、エージェント状態を finished に設定します。つまり、消費側のコードは、デコレーターのコメントが発生しないとしているリトライをすでに前提にしています。

マージ済みの修正はありません。PR #1348（タイトル「fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback」）は 2026 年 8 月 10 日に未マージのままクローズされ、その再提出である #1407 は 2026 年 9 月 21 日時点でもオープンかつ未マージでした。関連するコンテキストオーバーフロー PR #1391（「add tool description token budget to prevent context overflow」）は 2026 年 8 月 18 日に未マージのままクローズされました。メンテナーがクローズした理由はここでは確認しておらず、未マージであることだけを確認しています。2025 年 3 月 17 日の過去の報告 issue #779「hitting token limit」 は、state_reason: not_planned の状態で非アクティブ bot により 2026 年 9 月 17 日にクローズされました。これは解決ではなくタイムアウトです。いずれかが取り込まれるまで、実用的な回避策は max_input_tokens を未設定のままにしてプロバイダーに過大なリクエストを拒否させるか、設定して遅延を受け入れることです。

Unknown tool 'BrowserUseTool' は、もはや存在しないバージョンからのエラーです

Issue #789「Result: Error: Unknown tool 'BrowserUseTool'」は 2025 年 3 月 18 日に起票され、2026 年 9 月 21 日時点でもオープンのままで、inactive のラベルが付いていました。原因はエンドポイントでもキーでもありません。報告者自身のログでは、登録されたツール名が browser_use である箇所で、モデルが Python クラス名 BrowserUseTool を出力しています。同じ実行の次のステップでは、browser_use を呼び出すと正常にディスパッチされています。貼り付けられたログは「Activating tool: 'browser_use'」で終わり、締めくくりの行が診断全体です。「BrowserUseTool seems not work, but browser_use can」。コメント投稿者が示した唯一の助言は、より強力なモデルを試すことでした。これはツール呼び出し忠実度の問題に対する適切な回答です。

この診断は現在の main には当てはまりません。正しく指定すべき browser_use という名前のツールが、もはや存在しないためです。2026 年 8 月 15 日のコミット ab8dfe43（「feat(browser): use Browser Use CLI 3.0」）と 05c5bbb1（「refactor(browser): use CLI 3.0 MCP server」）によって、ローカルブラウザツールが削除されました。main にある app/tool/ のディレクトリ一覧には browser_use_tool.py がなく、ツリーに残る BrowserUseTool という文字列の出現箇所は app/agent/sandbox_agent.py のコメントアウトされた 1 行だけです。

したがって、今日この特定の文字列を修正するには、チェックアウトを更新し、古いリポジトリパスを前提に書かれたチュートリアルに基づく判断をやめてください。推測せずに述べるべき注意点が 1 つあります。MCP 接続に失敗すると、app/agent/manus.py は Failed to connect to Browser Use CLI 3.0 をログに記録し、4 つのローカルツールで処理を続けます。その結果、モデルは登録されていないブラウザツールを指定できる状態になります。実際に Unknown tool メッセージが発生するか、またどの名前で発生するかは、ここでは 観測していません。調査箇所として扱い、文書化された症状とはみなさないでください。また、requirements.txt が uv>=0.6.0 を固定している点にも注意してください。通常のインストールで uvx が PATH に入るかどうかは確認していません。

検索で今も見つかるもので、上の段落が意図的に主張していないことが 1 つあります。リポジトリには、デフォルトパスでは読み込まれないブラウザコードが実際に存在します。別個の Daytona サンドボックスエントリポイント sandbox_main.py は、SandboxManus エージェントを構築し、app/tool/sandbox/sb_browser_tool.py の SandboxBrowserTool をローカルツールとして登録します。名前は sandbox_browser であり、browser_use ではありません。したがって「ローカルブラウザツールがない」というのは、main.py から取得するデフォルトの Manus エージェントについての記述であり、ツリー全体についての記述ではありません。

検索時に区別しておくべき名前が 1 つあります。OpenManus/OpenManus-RL は別組織にある別リポジトリで、エージェントランタイムのバージョンではなく強化学習の研究プロジェクトです。そのファイル構成は、どちらのエラーについても何も示しません。

別の API エンドポイントで変わること、変わらないこと

上記の両方の症状は OpenManus 内部で生成されるため、「別のプロバイダーにすれば解決するか」という問いへの正直な答えは、いいえです。エンドポイントの選択が影響するのは、これら 2 つと取り違えやすい近接した一連の失敗です。

5 行目について、一般的な助言ではなくこのエンドポイントに固有のファーストパーティ情報が 1 つあります。Kunavo のディスパッチャーは、未対応パラメーターとして宣言しているカタログモデル — 現在は Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5 — について、転送前に temperature、top_p、top_k を削除します。これはプロトコルスイッチの段階で行われるため、削除後の本文がリトライ試行でも使用されます。それ以外のモデルでは、このフィールドは OpenManus が送信したまま転送されます。これにより、それらのモデルで発生する特定の 400 を 1 つ取り除けますが、OpenManus がここでテスト済みだという主張ではありません。Kunavo は OpenManus をランタイムテストしていません。このページのどの記述も互換性の結果ではありません。

デバッグではなく経路を比較しているなら、OpenAI 互換 APIでは汎用経路が運ぶものと運ばないものを、LLM ゲートウェイでは複数のモデル系統で 1 つのキーを使う価値がある場合を、AI コスト最適化では掲載料金が最安であることとタスク完了までの最安方法の違いを扱っています。これはエージェントループを左右する区別です。同じ種類の診断を別のクライアントで行う場合は、OpenCode でプロバイダーが見つからない場合を参照してください。

不具合の修正ではなく OpenManus のセットアップを行うのですか？エンドポイント側で必要なのは [llm] 内の 3 つのフィールド、model、base_url、api_key です。クイックスタートから始め、リクエスト形式を チャット補完 と照合し、キーへの資金追加の準備ができたら Kunavo アカウントを作成してください。試している間も動作する経路を確保し、他を変更する前に、範囲を限定したタスクを 1 つ実行してください。

よくある質問

2026 年 9 月 21 日に確認した範囲であり、より広範な確認ではありません。app/llm.py、app/config.py、app/agent/toolcall.py、app/agent/manus.py、app/agent/base.py、app/agent/sandbox_agent.py、app/tool/sandbox/sb_browser_tool.py、sandbox_main.py、app/exceptions.py、requirements.txt、config/config.example.toml、および main ブランチの README、app/tool/ のディレクトリ一覧、削除されたブラウザツールのコミット履歴、issue #779 と #789、それらのコメント、PR #1348、#1391、#1407 の GitHub 記録、リポジトリとリリースのメタデータ、Anthropic のモデル廃止ページを確認しました。実行は一切していません。インストール、OpenManus の実行、どちらのエラーの再現、OpenManus 経由でのどのエンドポイントへのリクエストも行っていないため、ここでの動作に関する主張はすべて、実際に観測した失敗ではなくソースの読み取りに基づくものです。成功した最小限の実行も、実施していないため報告していません。Kunavo のトークン料金はライブカタログに基づき、すべてのドル金額は実測タスクコストではなく例示的なトークン計算です。