Limites de tokens do OpenManus e o erro Unknown BrowserUseTool: um existe, o outro desapareceu

O OpenManus não impõe limite de tokens por padrão. Seu próprio limite superior é max_input_tokens, que app/config.py declara como Optional com valor padrão None e a descrição "Maximum input tokens to use across all requests (None for unlimited)", e que não aparece em nenhum exemplo de configuração distribuído. Portanto, uma instalação padrão nunca gera seu próprio erro de limite de tokens — o que você atingiu veio do provedor. Quando você o define, ele se comporta de duas maneiras que as pessoas não esperam, e um defeito presente no main atual faz com que falhe lentamente em vez de rapidamente.

O outro erro abordado nesta página, Error: Unknown tool 'BrowserUseTool', não é um bug ativo. A classe que ele nomeia foi excluída do OpenManus em 15 de agosto de 2026, e o agente Manus padrão no main atual não registra nenhuma ferramenta de navegador localmente. Nenhum dos sintomas é um problema de chave de API, endpoint ou provedor, e redirecionar base_url não corrige nenhum deles.

Uma observação de contexto antes de tudo. Não há uma versão do OpenManus a citar: as únicas três tags, v0.1.0, v0.2.0 e v0.3.0, foram todas publicadas em um intervalo de 34 segundos em 10 de abril de 2025, e nada foi marcado desde então, portanto todos executam o main sem tag. O repositório canônico é FoundationAgents/OpenManus — não arquivado, MIT, 58.371 estrelas, último push em 22 de agosto de 2026 (API do GitHub, 21 de setembro de 2026). O antigo caminho mannaandpoem/OpenManus agora é um README de stub dizendo que o projeto mudou, portanto caminhos de arquivo e números de linha citados em tutoriais de 2025 apontam para código que não está mais lá. Tudo abaixo foi lido no código-fonte no branch main em 21 de setembro de 2026 e nada foi executado.

Qual das quatro mensagens você realmente tem

O despacho que produz a terceira linha tem três linhas e não foi alterado pela reformulação do navegador de 2026: name = command.function.name, depois if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". Nada nele é específico para navegadores, portanto a mesma string aparece para qualquer ferramenta inventada por um modelo.

O limite de tokens é opcional, cumulativo e aproximado

Três números diferentes são chamados de "o limite de tokens", e a mensagem de erro diz respeito apenas a um deles.

A segunda linha é a que surpreende as pessoas. LLM.check_token_limit() em app/llm.py retorna (self.total_input_tokens + input_tokens) <= self.max_input_tokens — um total acumulado para a sessão, não uma verificação contra uma única solicitação. Portanto, uma execução longa do agente o atinge por acumulação mesmo quando cada solicitação individual é pequena, e o texto do erro explicita a aritmética: atual, necessário, máximo. O agente Manus padrão define max_steps = 20, e cada etapa reenvia a conversa até o momento, portanto o valor cumulativo sobe mais rápido do que a contagem de etapas.

A contagem também é uma estimativa própria do OpenManus. LLM.__init__ chama tiktoken.encoding_for_model(self.model) e recorre a cl100k_base em um KeyError, portanto, para qualquer ID de modelo sem predefinição no tiktoken — um ID Claude ou Gemini, ou um com namespace de gateway — o orçamento aplicado é uma aproximação, não a contagem do provedor.

# 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

Quanto vale um limite em dinheiro

Como max_input_tokens limita a entrada cumulativa, ele se converte diretamente em um teto de custo para o lado de entrada de uma execução. Os valores abaixo são aritmética ilustrativa de tokens com base no limite indicado, não o custo medido de uma tarefa nem um teto de cobrança: eles calculam o preço dos tokens de entrada limitados pela configuração, usando as tarifas atuais do catálogo do Kunavo por milhão. A saída não é coberta por essa configuração — a última coluna calcula o preço de uma resposta no max_tokens = 8192 distribuído pelo exemplo de configuração, e uma execução de vinte etapas pode produzir vinte delas.

Duas interpretações. Um limite é uma parada, não um orçamento: ele informa o máximo que o lado de entrada de uma execução pode custar e não diz nada sobre a conclusão da tarefa. E, como o OpenManus conta com tiktoken, o limite aplicado por ele e os tokens faturados pelo provedor são duas medições diferentes — defina o número para limitar um loop descontrolado e depois faça a reconciliação com o que sua conta realmente registrou. O valor do catálogo do Kunavo é um piso de cobrança, não um teto: quando o upstream informa sua cobrança, a fatura é o maior valor entre o custo do catálogo e o custo do upstream multiplicado pelo markup aplicável. O recarregamento mínimo do Kunavo é $10 em crédito pré-pago, um mínimo de financiamento, não uma tarifa de tarefa nem uma assinatura — consulte detalhes de cobrança.

Por que o erro de token chega tarde

Este é um defeito que pode ser lido no main atual e é o motivo pelo qual uma falha de limite de tokens parece um travamento. Todos os três decoradores @retry em app/llm.py — em ask, ask_with_images e ask_tool — são escritos de forma idêntica:

O loop do agente a jusante confirma o formato em vez de contradizê-lo. app/agent/toolcall.py captura a exceção e testa isinstance(e.__cause__, TokenLimitExceeded) — esse desempacotamento de __cause__ é como chega um RetryError do tenacity, e sua própria linha de log diz "Token limit error (from RetryError)". Só então ele adiciona a mensagem visível ao usuário "Maximum token limit reached, cannot continue execution" e define o estado do agente como concluído. Em outras palavras, o código consumidor já presume a repetição que o comentário do decorador diz que não ocorre.

Não há correção integrada. A PR #1348, intitulada "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback", foi encerrada sem integração em 10 de agosto de 2026; sua reapresentação, #1407, ainda estava aberta e sem integração em 21 de setembro de 2026. Uma PR relacionada sobre estouro de contexto, #1391, "add tool description token budget to prevent context overflow", foi encerrada sem integração em 18 de agosto de 2026. O motivo pelo qual os mantenedores as encerraram não foi lido aqui, apenas que não foram integradas. O relatório histórico, issue #779 "hitting token limit" de 17 de março de 2025, foi encerrado em 17 de setembro de 2026 por um bot de inatividade com state_reason: not_planned — um timeout, não uma resolução. Até que uma dessas correções seja integrada, as mitigações práticas são deixar max_input_tokens sem definição e permitir que o provedor rejeite solicitações grandes, ou defini-lo e aceitar o atraso.

Unknown tool 'BrowserUseTool' é um erro de uma versão que não existe mais

O issue #789, "Result: Error: Unknown tool 'BrowserUseTool'", foi aberto em 18 de março de 2025 e ainda estava aberto em 21 de setembro de 2026, rotulado como inactive. Sua causa nunca foi um endpoint ou uma chave. O próprio log do relator mostra o modelo emitindo o nome da classe Python, BrowserUseTool, onde o nome da ferramenta registrada era browser_use — e a etapa seguinte da mesma execução sendo despachada corretamente assim que chamou browser_use. O log colado termina em "Activating tool: 'browser_use'", e sua linha final é todo o diagnóstico: "BrowserUseTool seems not work, but browser_use can". O único conselho dado por qualquer comentarista foi tentar um modelo mais forte, que é o tipo correto de resposta para um problema de fidelidade na chamada de ferramentas.

Esse diagnóstico não se aplica ao main atual, porque não existe mais nenhuma ferramenta chamada browser_use para acertar. Em 15 de agosto de 2026, os commits ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") e 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server") excluíram a ferramenta de navegador local. Uma listagem do diretório app/tool/ no main não contém nenhum browser_use_tool.py, e a única ocorrência da string BrowserUseTool restante na árvore está em uma linha comentada de app/agent/sandbox_agent.py.

Portanto, a correção para esta string exata hoje é atualizar seu checkout e parar de raciocinar com base em tutoriais escritos para o caminho antigo do repositório. Vale declarar uma ressalva, em vez de presumir: quando a conexão MCP falha, app/agent/manus.py registra Failed to connect to Browser Use CLI 3.0 e continua com as quatro ferramentas locais, o que deixa o modelo capaz de nomear uma ferramenta de navegador que não está registrada. Não foi observado aqui se isso produz uma mensagem Unknown tool na prática, nem sob qual nome, — trate isso como um ponto a investigar, não como um sintoma documentado. Observe também que requirements.txt fixa uv>=0.6.0; não foi verificado se uma instalação normal coloca uvx em seu PATH.

Uma coisa que a pesquisa ainda encontrará, e que os parágrafos acima deliberadamente não afirmam: o repositório contém código de navegador que o caminho padrão nunca carrega. O ponto de entrada separado do sandbox Daytona sandbox_main.py cria um agente SandboxManus que registra SandboxBrowserTool de app/tool/sandbox/sb_browser_tool.py como uma ferramenta local — sob o nome sandbox_browser, não browser_use. Portanto, “nenhuma ferramenta local de navegador” é uma afirmação sobre o agente Manus padrão que você obtém de main.py, não sobre toda a árvore.

Um nome a manter separado durante a pesquisa: OpenManus/OpenManus-RL é um repositório distinto, em uma organização distinta, um projeto de pesquisa de aprendizado por reforço, não uma versão do runtime do agente; seu layout de arquivos não tem relação com nenhum dos dois erros.

O que um endpoint de API diferente muda e não muda

Ambos os sintomas acima são produzidos dentro do OpenManus, portanto a resposta honesta a “outro provedor corrigirá isso?” é não. O que a escolha do endpoint afeta é um conjunto próximo de falhas que podem ser facilmente confundidas com essas duas.

Na quinta linha, há um detalhe de primeira parte específico deste endpoint, e não uma recomendação geral. O dispatcher do Kunavo remove temperature, top_p e top_k antes do encaminhamento, para os modelos do catálogo que declaram esses parâmetros como incompatíveis — atualmente 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 — e faz isso na troca de protocolo; portanto, o corpo sem esses campos também é o que qualquer tentativa de repetição recebe. Para todos os outros modelos, o campo é encaminhado como o OpenManus o enviou. Isso elimina um erro 400 específico para esses modelos; não é uma afirmação de que o OpenManus foi testado aqui. O Kunavo não testou o OpenManus em runtime, e nada nesta página é um resultado de compatibilidade.

Se você está avaliando rotas, em vez de depurar uma, A API compatível com OpenAI aborda o que o caminho genérico transporta e não transporta, o gateway de LLM aborda quando vale a pena usar uma chave para várias famílias, e a otimização de custos de IA aborda a diferença entre a tarifa listada mais barata e a maneira mais barata de concluir uma tarefa — distinção que decide um loop de agente. Para o mesmo tipo de diagnóstico em outro cliente, consulte Provedor do OpenCode não encontrado.

Está configurando o OpenManus, em vez de consertá-lo? O lado do endpoint consiste em três campos em [llm]: model, base_url e api_key. Comece pelo quickstart, confira o formato da solicitação em relação a chat completions e crie uma conta Kunavo quando estiver pronto para financiar uma chave. Mantenha uma rota funcional disponível enquanto testa e execute uma tarefa delimitada antes de mudar qualquer outra coisa.

Perguntas frequentes

Verificado em 21 de setembro de 2026, e não de forma mais ampla: 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 e o README no branch main; uma listagem de diretório de app/tool/; o histórico de commits da ferramenta de navegador excluída; os registros do GitHub para as issues #779 e #789, seus comentários e os pull requests #1348, #1391 e #1407; os metadados do repositório e das versões; e a página da Anthropic sobre descontinuação de modelos. Nada foi executado — nenhuma instalação, nenhuma execução do OpenManus, nenhuma reprodução de qualquer um dos erros e nenhuma solicitação pelo OpenManus em qualquer endpoint — portanto, toda afirmação comportamental aqui deriva da leitura das fontes, não de uma falha observada, e nenhuma execução mínima bem-sucedida é relatada porque nenhuma foi realizada. As tarifas de tokens do Kunavo vêm do catálogo ativo, e cada valor em dólar é uma aritmética ilustrativa de tokens, não o custo medido de uma tarefa.