OpenManus token limits and the Unknown BrowserUseTool error: one is live, one is gone

OpenManus enforces no token limit by default. Its own ceiling is max_input_tokens, which app/config.py declares as Optional with a default of None and the description "Maximum input tokens to use across all requests (None for unlimited)", and which appears in no shipped config example. So a stock install never raises a token-limit error of its own — whatever you hit came from the provider. When you do set it, it behaves in two ways people do not expect, and a defect present in current main makes it fail slowly instead of fast.

The other error this page covers, Error: Unknown tool 'BrowserUseTool', is not a live bug at all. The class it names was deleted from OpenManus on August 15, 2026, and the default Manus agent on current main registers no browser tool locally. Neither symptom is an API key, endpoint or provider problem, and repointing base_url fixes neither.

One framing note before any of it. There is no OpenManus version to cite: the only three tags, v0.1.0, v0.2.0 and v0.3.0, were all published within 34 seconds of each other on April 10, 2025, and nothing has been tagged since, so everyone runs untagged main. The canonical repository is FoundationAgents/OpenManus — not archived, MIT, 58,371 stars, last pushed August 22, 2026 (GitHub API, September 21, 2026). The old mannaandpoem/OpenManus path is now a stub README saying the project moved, so file paths and line numbers quoted from 2025 tutorials point at code that is no longer there. Everything below was read at source on branch main on September 21, 2026 and none of it was executed.

Which of the four messages you actually have

The dispatch that produces the third row is three lines, and it is unchanged by the 2026 browser rewrite: name = command.function.name, then if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". Nothing in it is specific to browsers, so the same string appears for any tool a model invents.

The token limit is opt-in, cumulative, and approximate

Three different numbers get called "the token limit", and the error message only ever concerns one of them.

The second row is the one that surprises people. LLM.check_token_limit() in app/llm.py returns (self.total_input_tokens + input_tokens) <= self.max_input_tokens — a running total for the session, not a check against one request. So a long agent run trips it through accumulation even when every individual request is small, and the error text spells the arithmetic out: current, needed, max. The default Manus agent sets max_steps = 20, and each step resends the conversation so far, so the cumulative figure climbs faster than the step count does.

The count is also OpenManus's own estimate. LLM.__init__ calls tiktoken.encoding_for_model(self.model) and falls back to cl100k_base on a KeyError, so for any model ID tiktoken has no preset for — a Claude or Gemini ID, or a gateway-namespaced one — the budget being enforced is an approximation rather than the provider's count.

# 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

What a ceiling is worth in money

Because max_input_tokens bounds cumulative input, it converts directly into a cost ceiling for the input side of one run. The figures below are illustrative token arithmetic on the stated ceiling, not a measured task cost and not a bill ceiling: they price the input tokens the setting caps, at live Kunavo catalog rates per million. Output is not covered by that setting at all — the last column prices one response at the max_tokens = 8192 the example config ships, and a twenty-step run can produce twenty of them.

Two readings. A ceiling is a stop, not a budget: it tells you the most the input side of a run can cost, and says nothing about whether the task finished. And because OpenManus counts with tiktoken, the ceiling it enforces and the tokens your provider bills are two different measurements — set the number to bound a runaway loop, then reconcile against what your account actually recorded. Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. The minimum Kunavo top-up is $10 in prepaid credit, a funding minimum rather than a task fee or a subscription — see billing details.

Why the token error arrives late

This is a defect you can read in current main, and it is the reason a token-limit failure feels like a hang. All three @retry decorators in app/llm.py — on ask, ask_with_images and ask_tool — are written identically:

The agent loop downstream confirms the shape rather than contradicting it. app/agent/toolcall.py catches the exception and tests isinstance(e.__cause__, TokenLimitExceeded) — that __cause__ unwrapping is how a tenacity RetryError arrives, and its own log line reads "Token limit error (from RetryError)". Only then does it add the user-visible "Maximum token limit reached, cannot continue execution" message and set the agent state to finished. In other words the consuming code already assumes the retry the decorator comment says does not happen.

There is no merged fix. PR #1348, titled "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback", was closed unmerged on August 10, 2026; its resubmission #1407 was still open and unmerged on September 21, 2026. A related context-overflow PR, #1391, "add tool description token budget to prevent context overflow", was closed unmerged on August 18, 2026. Why the maintainers closed them was not read here, only that they are unmerged. The historical report, issue #779 "hitting token limit" from March 17, 2025, was closed on September 17, 2026 by an inactivity bot with state_reason: not_planned — a timeout, not a resolution. Until one of those lands, the practical mitigations are to leave max_input_tokens unset and let the provider reject oversized requests, or to set it and accept the delay.

Unknown tool 'BrowserUseTool' is an error from a version that no longer exists

Issue #789, "Result: Error: Unknown tool 'BrowserUseTool'", was opened on March 18, 2025 and was still open on September 21, 2026, labelled inactive. Its cause was never an endpoint or a key. The reporter's own log shows the model emitting the Python class name, BrowserUseTool, where the registered tool name was browser_use — and the very next step of the same run dispatching cleanly once it called browser_use. The log they pasted ends at "Activating tool: 'browser_use'", and their closing line is the whole diagnosis: "BrowserUseTool seems not work, but browser_use can". The only advice any commenter gave was to try a stronger model, which is the right shape of answer for a tool-calling-fidelity problem.

That diagnosis does not transfer to current main, because there is no longer any tool named browser_use to get right. On August 15, 2026 commits ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") and 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server") deleted the local browser tool. A directory listing of app/tool/ on main contains no browser_use_tool.py, and the only occurrence of the string BrowserUseTool left in the tree is a commented-out line in app/agent/sandbox_agent.py.

So the fix for this exact string today is to update your checkout, and to stop reasoning from tutorials written against the old repository path. One caveat worth stating rather than guessing at: when the MCP connection fails, app/agent/manus.py logs Failed to connect to Browser Use CLI 3.0 and continues with the four local tools, which leaves the model able to name a browser tool that is not registered. Whether that produces an Unknown tool message in practice, and under which name, was not observed here — treat it as a place to look, not as a documented symptom. Note also that requirements.txt pins uv>=0.6.0; whether a normal install puts uvx on your PATH was not verified.

One thing that search will still turn up, and that the paragraphs above are deliberately not claiming: the repository does contain browser code that the default path never loads. The separate Daytona-sandbox entry point sandbox_main.py builds a SandboxManus agent that registers SandboxBrowserTool from app/tool/sandbox/sb_browser_tool.py as a local tool — under the name sandbox_browser, not browser_use. So "no local browser tool" is a statement about the default Manus agent you get from main.py, not about the whole tree.

One name to keep apart while searching: OpenManus/OpenManus-RL is a separate repository in a separate organisation, a reinforcement-learning research project rather than a version of the agent runtime, and its file layout has nothing to say about either error.

What a different API endpoint does and does not change

Both symptoms above are produced inside OpenManus, so the honest answer to "will another provider fix this" is no. What an endpoint choice does affect is a nearby set of failures that are easy to misread as these two.

On that fifth row, one first-party detail that is specific to this endpoint rather than general advice. Kunavo's dispatcher drops temperature, top_p and top_k before forwarding, for the catalog models that declare those parameters unsupported — currently Claude Fable 5.1, Claude Fable 5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5 — and it does so at the protocol switch, so the stripped body is what any retry attempt sees too. For every other model the field is forwarded as OpenManus sent it. That removes one specific 400 for those models; it is not a claim that OpenManus has been tested here. Kunavo has not runtime-tested OpenManus, and nothing on this page is a compatibility result.

If you are weighing routes rather than debugging one, OpenAI-compatible API covers what the generic path does and does not carry, LLM gateway covers when one key across families is worth it, and AI cost optimization covers the difference between the cheapest listed rate and the cheapest way to finish a task — which is the distinction that decides an agent loop. For the same class of diagnosis on another client, see OpenCode provider not found.

Setting OpenManus up rather than repairing it? The endpoint side is three fields in [llm]: model, base_url and api_key. Start at the quickstart, check the request shape against chat completions, and create a Kunavo account when you are ready to fund a key. Keep a working route available while you try it, and run one bounded task before changing anything else.

FAQ

Checked September 21, 2026 and not more widely: 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 and the README on branch main; a directory listing of app/tool/; the commit history of the deleted browser tool; the GitHub records for issues #779 and #789, their comments, and pull requests #1348, #1391 and #1407; the repository and release metadata; and Anthropic's model-deprecation page. Nothing was executed — no install, no OpenManus run, no reproduction of either error, and no request through OpenManus at any endpoint — so every behavioural claim here is a source read rather than an observed failure, and no successful minimal run is reported because none was performed. Kunavo token rates come from the live catalog, and every dollar figure is illustrative token arithmetic rather than a measured task cost.