Límites de tokens de OpenManus y el error Unknown BrowserUseTool: uno existe y el otro desapareció

OpenManus no aplica ningún límite de tokens de forma predeterminada. Su propio límite es max_input_tokens, que app/config.py declara como Optional con un valor predeterminado de None y la descripción "Maximum input tokens to use across all requests (None for unlimited)", y que no aparece en ningún ejemplo de configuración incluido. Por tanto, una instalación estándar nunca genera por sí misma un error de límite de tokens: lo que encontraste procedía del proveedor. Cuando lo configuras, se comporta de dos formas que la gente no espera, y un defecto presente en main actual hace que falle lentamente en lugar de hacerlo de inmediato.

El otro error que cubre esta página, Error: Unknown tool 'BrowserUseTool', no es un error activo en absoluto. La clase que nombra se eliminó de OpenManus el 15 de agosto de 2026, y el agente Manus predeterminado de main actual no registra ninguna herramienta de navegador localmente. Ninguno de los dos síntomas es un problema de clave de API, endpoint o proveedor, y redirigir base_url no corrige ninguno de ellos.

Una aclaración antes de todo lo demás. No hay ninguna versión de OpenManus que citar: las únicas tres etiquetas, v0.1.0, v0.2.0 y v0.3.0, se publicaron todas con 34 segundos de diferencia el 10 de abril de 2025, y no se ha etiquetado nada desde entonces, por lo que todo el mundo ejecuta main sin etiquetar. El repositorio canónico es FoundationAgents/OpenManus — no está archivado, tiene licencia MIT, 58,371 estrellas y se actualizó por última vez el 22 de agosto de 2026 (API de GitHub, 21 de septiembre de 2026). La antigua ruta mannaandpoem/OpenManus ahora es un README provisional que indica que el proyecto se trasladó, por lo que las rutas de archivos y los números de línea citados en tutoriales de 2025 apuntan a código que ya no está allí. Todo lo que aparece a continuación se leyó en el código fuente de la rama main el 21 de septiembre de 2026 y no se ejecutó nada.

Cuál de los cuatro mensajes tienes realmente

El despacho que produce la tercera fila ocupa tres líneas y no ha cambiado con la reescritura del navegador de 2026: name = command.function.name y después if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". No contiene nada específico de navegadores, por lo que la misma cadena aparece con cualquier herramienta que invente un modelo.

El límite de tokens es opcional, acumulativo y aproximado

Se llama "límite de tokens" a tres números diferentes, y el mensaje de error solo se refiere a uno de ellos.

La segunda fila es la que sorprende a la gente. LLM.check_token_limit() en app/llm.py devuelve (self.total_input_tokens + input_tokens) <= self.max_input_tokens: un total acumulado de la sesión, no una comprobación contra una sola solicitud. Por tanto, una ejecución larga del agente lo activa por acumulación aunque cada solicitud individual sea pequeña, y el texto del error explicita la aritmética: actual, necesario, máximo. El agente Manus predeterminado establece max_steps = 20, y cada paso vuelve a enviar la conversación acumulada hasta ese momento, por lo que la cifra acumulada aumenta más rápido que el número de pasos.

El recuento también es una estimación propia de OpenManus. LLM.__init__ llama a tiktoken.encoding_for_model(self.model) y recurre a cl100k_base ante un KeyError, por lo que para cualquier ID de modelo que tiktoken no tenga predefinido — un ID de Claude o Gemini, o uno con espacio de nombres de gateway — el presupuesto aplicado es una aproximación y no el recuento del proveedor.

# 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

Qué valor monetario tiene un límite

Como max_input_tokens limita la entrada acumulada, se convierte directamente en un límite de coste para el lado de entrada de una ejecución. Las cifras siguientes son cálculos ilustrativos de tokens sobre el límite indicado, no un coste medido de una tarea ni un límite de facturación: calculan el precio de los tokens de entrada que limita la configuración, usando las tarifas actuales del catálogo de Kunavo por millón. La salida no está cubierta en absoluto por esa configuración; la última columna calcula el precio de una respuesta con el max_tokens = 8192 que incluye la configuración de ejemplo, y una ejecución de veinte pasos puede producir veinte respuestas de ese tipo.

Dos lecturas. Un límite es una parada, no un presupuesto: te indica cuánto puede costar como máximo el lado de entrada de una ejecución y no dice nada sobre si la tarea terminó. Y como OpenManus cuenta con tiktoken, el límite que aplica y los tokens que factura tu proveedor son dos mediciones diferentes: establece el número para limitar un bucle descontrolado y luego contrástalo con lo que realmente registró tu cuenta. El importe del catálogo de Kunavo es un mínimo de facturación, no un límite: cuando el proveedor ascendente informa de su cargo, la factura es el mayor entre el coste del catálogo y el coste del proveedor ascendente multiplicado por el margen aplicable. La recarga mínima de Kunavo es $10 en crédito prepagado, un mínimo de financiación, no una tarifa por tarea ni una suscripción; consulta los detalles de facturación.

Por qué el error de tokens llega tarde

Este es un defecto que puede leerse en la rama main actual, y es la razón por la que un fallo de límite de tokens parece un bloqueo. Los tres decoradores @retry de app/llm.py — en ask, ask_with_images y ask_tool — están escritos de forma idéntica:

El bucle del agente posterior confirma la estructura en lugar de contradecirla. app/agent/toolcall.py captura la excepción y comprueba isinstance(e.__cause__, TokenLimitExceeded); ese desempaquetado mediante __cause__ es la forma en que llega un RetryError de tenacity, y su propia línea de registro dice "Token limit error (from RetryError)". Solo entonces añade el mensaje visible para el usuario "Maximum token limit reached, cannot continue execution" y establece el estado del agente como terminado. En otras palabras, el código consumidor ya presupone el reintento que el comentario del decorador afirma que no ocurre.

No hay ninguna corrección fusionada. La PR #1348, titulada "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback", se cerró sin fusionarse el 10 de agosto de 2026; su reenvío, #1407, seguía abierto y sin fusionar el 21 de septiembre de 2026. Una PR relacionada sobre desbordamiento de contexto, #1391, "add tool description token budget to prevent context overflow", se cerró sin fusionarse el 18 de agosto de 2026. Aquí no se ha investigado por qué los mantenedores las cerraron, solo que no están fusionadas. El informe histórico, el issue #779 "hitting token limit" del 17 de marzo de 2025, se cerró el 17 de septiembre de 2026 por un bot de inactividad con state_reason: not_planned: un tiempo de espera, no una resolución. Hasta que se fusione una de ellas, las mitigaciones prácticas son dejar max_input_tokens sin establecer y permitir que el proveedor rechace las solicitudes demasiado grandes, o establecerlo y aceptar la demora.

Unknown tool 'BrowserUseTool' es un error de una versión que ya no existe

El Issue #789, "Result: Error: Unknown tool 'BrowserUseTool'", se abrió el 18 de marzo de 2025 y seguía abierto el 21 de septiembre de 2026, etiquetado como inactive. Su causa nunca fue un endpoint ni una clave. El propio registro de quien informó muestra que el modelo emitió el nombre de la clase Python, BrowserUseTool, cuando el nombre de herramienta registrado era browser_use, y que el paso siguiente de la misma ejecución se despachó correctamente cuando llamó a browser_use. El registro que pegó termina en "Activating tool: 'browser_use'", y su línea de cierre es todo el diagnóstico: "BrowserUseTool seems not work, but browser_use can". El único consejo de los comentaristas fue probar un modelo más potente, que es la respuesta adecuada para un problema de fidelidad al llamar herramientas.

Ese diagnóstico no se aplica a main actual, porque ya no existe ninguna herramienta llamada browser_use que haya que nombrar correctamente. El 15 de agosto de 2026, los commits ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") y 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server") eliminaron la herramienta de navegador local. Un listado del directorio app/tool/ en main no contiene ningún browser_use_tool.py, y la única aparición de la cadena BrowserUseTool que queda en el árbol es una línea comentada en app/agent/sandbox_agent.py.

Así que la solución para esta cadena exacta hoy es actualizar tu copia local del repositorio y dejar de basarte en tutoriales escritos para la antigua ruta del repositorio. Conviene señalar una salvedad en lugar de hacer suposiciones: cuando falla la conexión MCP, app/agent/manus.py registra Failed to connect to Browser Use CLI 3.0 y continúa con las cuatro herramientas locales, lo que permite que el modelo mencione una herramienta de navegador que no está registrada. No se observó aquí si eso produce un mensaje Unknown tool en la práctica ni con qué nombre; considéralo un punto que investigar, no un síntoma documentado. Ten en cuenta también que requirements.txt fija uv>=0.6.0; no se verificó si una instalación normal coloca uvx en tu PATH.

Hay algo que la búsqueda todavía encontrará y que los párrafos anteriores deliberadamente no afirman: el repositorio sí contiene código de navegador que la ruta predeterminada nunca carga. El punto de entrada independiente de Daytona-sandbox sandbox_main.py construye un agente SandboxManus que registra SandboxBrowserTool de app/tool/sandbox/sb_browser_tool.py como herramienta local, con el nombre sandbox_browser, no browser_use. Por tanto, "no hay ninguna herramienta de navegador local" es una afirmación sobre el agente Manus predeterminado que obtienes de main.py, no sobre todo el árbol.

Un nombre que conviene mantener separado durante la búsqueda: OpenManus/OpenManus-RL es un repositorio independiente en una organización distinta, un proyecto de investigación sobre aprendizaje por refuerzo y no una versión del entorno de ejecución del agente, y su estructura de archivos no dice nada sobre ninguno de los dos errores.

Qué cambia y qué no cambia con un endpoint de API diferente

Los dos síntomas anteriores se producen dentro de OpenManus, por lo que la respuesta honesta a "¿otro proveedor corregirá esto?" es no. Lo que sí afecta la elección del endpoint es un conjunto cercano de fallos que se pueden interpretar fácilmente como estos dos.

En esa quinta fila hay un detalle específico de primera parte que corresponde a este endpoint y no a una recomendación general. El despachador de Kunavo elimina temperature, top_p y top_k antes del reenvío, para los modelos del catálogo que declaran esos parámetros como no compatibles — actualmente 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 — y lo hace en el cambio de protocolo, por lo que el cuerpo sin esos campos es también lo que ve cualquier intento de reintento. Para cualquier otro modelo, el campo se reenvía tal como lo envió OpenManus. Eso elimina un 400 concreto para esos modelos; no afirma que OpenManus se haya probado aquí. Kunavo no ha probado OpenManus en tiempo de ejecución, y nada de esta página constituye un resultado de compatibilidad.

Si estás valorando rutas en lugar de depurar una sola, API compatible con OpenAI explica qué transporta y qué no la ruta genérica, gateway de LLM explica cuándo merece la pena una sola clave para varias familias y optimización de costes de IA explica la diferencia entre la tarifa indicada más barata y la forma más barata de completar una tarea, que es la distinción que decide un bucle de agente. Para el mismo tipo de diagnóstico en otro cliente, consulta Proveedor de OpenCode no encontrado.

¿Estás configurando OpenManus en lugar de repararlo? El lado del endpoint consta de tres campos en [llm]: model, base_url y api_key. Empieza por la guía de inicio rápido, comprueba la estructura de la solicitud con completions de chat y crea una cuenta de Kunavo cuando estés listo para financiar una clave. Mantén disponible una ruta funcional mientras lo pruebas y ejecuta una tarea limitada antes de cambiar cualquier otra cosa.

Preguntas frecuentes

Comprobado el 21 de septiembre de 2026 y no de forma más amplia: 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 y el README de la rama main; un listado del directorio app/tool/; el historial de commits de la herramienta de navegador eliminada; los registros de GitHub de los issues #779 y #789, sus comentarios y las pull requests #1348, #1391 y #1407; los metadatos del repositorio y de las versiones; y la página de retirada de modelos de Anthropic. No se ejecutó nada: ni instalación, ni ejecución de OpenManus, ni reproducción de ninguno de los dos errores, ni ninguna solicitud a través de OpenManus en ningún endpoint; por tanto, cada afirmación conductual aquí es una lectura del código fuente y no un fallo observado, y no se informa de ninguna ejecución mínima exitosa porque no se realizó ninguna. Las tarifas de tokens de Kunavo proceden del catálogo activo, y cada cifra en dólares es un cálculo ilustrativo de tokens, no un coste medido de una tarea.