OpenManus-Tokenlimits und der Fehler „Unknown BrowserUseTool“: Einer ist aktuell, einer verschwunden

OpenManus setzt standardmäßig kein Token-Limit durch. Seine eigene Obergrenze ist max_input_tokens, die app/config.py als Optional mit dem Standardwert None und der Beschreibung "Maximum input tokens to use across all requests (None for unlimited)" deklariert und die in keinem mitgelieferten Konfigurationsbeispiel vorkommt. Eine Standardinstallation löst daher niemals einen eigenen Token-Limit-Fehler aus – was Sie erreicht haben, kam vom Anbieter. Wenn Sie sie setzen, verhält sie sich auf zwei Arten unerwartet, und ein in der aktuellen Version von main vorhandener Fehler lässt sie langsam statt schnell scheitern.

Der andere Fehler, den diese Seite behandelt, Error: Unknown tool 'BrowserUseTool', ist überhaupt kein aktiver Bug. Die von ihm benannte Klasse wurde am 15. August 2026 aus OpenManus entfernt, und der standardmäßige Manus-Agent in der aktuellen Version von main registriert lokal kein Browser-Tool. Keines der beiden Symptome ist ein API-Key-, Endpunkt- oder Anbieterproblem, und das Umleiten von base_url behebt keines von beiden.

Eine Einordnung vorab. Es gibt keine OpenManus-Version, die man angeben könnte: Die einzigen drei Tags, v0.1.0, v0.2.0 und v0.3.0, wurden alle am 10. April 2025 innerhalb von 34 Sekunden voneinander veröffentlicht, und seitdem wurde nichts mehr getaggt; alle verwenden daher ungetaggtes main. Das kanonische Repository ist FoundationAgents/OpenManus – nicht archiviert, MIT, 58.371 Sterne, zuletzt am 22. August 2026 gepusht (GitHub API, 21. September 2026). Der alte Pfad mannaandpoem/OpenManus ist jetzt ein README-Stub mit dem Hinweis, dass das Projekt verschoben wurde; in Tutorials von 2025 zitierte Dateipfade und Zeilennummern verweisen daher auf Code, der nicht mehr vorhanden ist. Alles Folgende wurde am 21. September 2026 aus dem Quellcode auf dem Branch main gelesen und nichts davon wurde ausgeführt.

Welche der vier Meldungen Sie tatsächlich haben

Der Dispatcher, der die dritte Zeile erzeugt, besteht aus drei Zeilen und ist durch die Browser-Überarbeitung von 2026 unverändert: name = command.function.name, dann if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". Nichts darin ist browserspezifisch; dieselbe Zeichenfolge erscheint daher für jedes Tool, das ein Modell erfindet.

Das Token-Limit ist optional, kumulativ und nur näherungsweise

Drei verschiedene Zahlen werden als „das Token-Limit“ bezeichnet, aber die Fehlermeldung betrifft immer nur eine davon.

Die zweite Zeile überrascht die meisten. LLM.check_token_limit() in app/llm.py gibt (self.total_input_tokens + input_tokens) <= self.max_input_tokens zurück – eine laufende Summe für die Sitzung, keine Prüfung einer einzelnen Anfrage. Daher wird es bei einem langen Agentenlauf durch Aufsummierung ausgelöst, selbst wenn jede einzelne Anfrage klein ist; der Fehlertext legt die Rechnung offen: aktuell, benötigt, maximal. Der standardmäßige Manus-Agent setzt max_steps = 20, und jeder Schritt sendet den bisherigen Gesprächsverlauf erneut; dadurch steigt die kumulative Zahl schneller als die Schrittzahl.

Auch diese Zählung ist nur die eigene Schätzung von OpenManus. LLM.__init__ ruft tiktoken.encoding_for_model(self.model) auf und fällt bei einem KeyError auf cl100k_base zurück; für jede Modell-ID, für die tiktoken keine Voreinstellung besitzt – eine Claude- oder Gemini-ID oder eine Gateway-namespaced-ID – ist das durchgesetzte Budget daher eine Näherung statt der Zählung des Anbieters.

# 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

Was eine Obergrenze in Geld wert ist

Da max_input_tokens die kumulative Eingabe begrenzt, lässt sie sich direkt in eine Kostengrenze für die Eingabeseite eines Laufs umrechnen. Die folgenden Zahlen sind beispielhafte Tokenrechnung auf Basis der angegebenen Obergrenze, keine gemessenen Aufgabenkosten und keine Rechnungslimitierung: Sie bepreisen die von der Einstellung begrenzten Eingabetokens zu den aktuellen Kunavo-Katalog-Tarifen pro Million. Die Ausgabe wird von dieser Einstellung überhaupt nicht abgedeckt – die letzte Spalte bepreist eine Antwort zum max_tokens = 8192, mit dem die Beispielkonfiguration ausgeliefert wird; ein Lauf mit zwanzig Schritten kann zwanzig davon erzeugen.

Zwei Betrachtungsweisen. Eine Obergrenze ist ein Stopp, kein Budget: Sie sagt, was die Eingabeseite eines Laufs höchstens kosten kann, und nichts darüber, ob die Aufgabe abgeschlossen wurde. Da OpenManus mit tiktoken zählt, sind die von ihm durchgesetzte Obergrenze und die vom Anbieter abgerechneten Tokens zwei verschiedene Messwerte – setzen Sie die Zahl, um eine ausufernde Schleife zu begrenzen, und gleichen Sie sie anschließend mit den tatsächlich von Ihrem Konto aufgezeichneten Werten ab. Der Katalogbetrag von Kunavo ist ein Abrechnungsuntergrenze statt einer Obergrenze: Wenn der Upstream seine Kosten meldet, ist die Rechnung der höhere Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem anwendbaren Aufschlag. Die minimale Kunavo-Aufladung beträgt $10 Prepaid-Guthaben, eine Mindestfinanzierung statt einer Aufgaben- oder Abonnementgebühr – siehe Abrechnungsdetails.

Warum der Tokenfehler verspätet eintrifft

Dies ist ein Fehler, den Sie in der aktuellen Version von main ablesen können, und der Grund, warum sich ein Token-Limit-Fehler wie ein Hänger anfühlt. Alle drei @retry-Dekoratoren in app/llm.py – für ask, ask_with_images und ask_tool – sind identisch geschrieben:

Die nachgelagerte Agentenschleife bestätigt diese Struktur, statt ihr zu widersprechen. app/agent/toolcall.py fängt die Ausnahme ab und prüft isinstance(e.__cause__, TokenLimitExceeded) – dieses __cause__-Entpacken erklärt, wie ein tenacity-RetryError ankommt, und die eigene Logzeile lautet "Token limit error (from RetryError)". Erst danach fügt sie die für den Benutzer sichtbare Meldung "Maximum token limit reached, cannot continue execution" hinzu und setzt den Agentenstatus auf finished. Der konsumierende Code geht also bereits von genau der Wiederholung aus, die der Kommentar des Dekorators verneint.

Es gibt keine zusammengeführte Korrektur. PR #1348 mit dem Titel "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback" wurde am 10. August 2026 ohne Merge geschlossen; seine erneute Einreichung #1407 war am 21. September 2026 noch offen und nicht zusammengeführt. Ein verwandter PR zum Kontextüberlauf, #1391, "add tool description token budget to prevent context overflow", wurde am 18. August 2026 ohne Merge geschlossen. Warum die Maintainer sie schlossen, wurde hier nicht untersucht; festgestellt wurde nur, dass sie nicht zusammengeführt sind. Der historische Bericht, Issue #779 "hitting token limit" vom 17. März 2025, wurde am 17. September 2026 von einem Inaktivitäts-Bot mit state_reason: not_planned geschlossen – ein Timeout, keine Lösung. Bis eine dieser Änderungen übernommen wird, besteht die praktische Abhilfe darin, max_input_tokens nicht zu setzen und den Anbieter übergroße Anfragen ablehnen zu lassen, oder es zu setzen und die Verzögerung zu akzeptieren.

Unknown tool 'BrowserUseTool' ist ein Fehler aus einer Version, die nicht mehr existiert

Issue #789, "Result: Error: Unknown tool 'BrowserUseTool'", wurde am 18. März 2025 eröffnet und war am 21. September 2026 noch offen, als inactive gekennzeichnet. Seine Ursache war nie ein Endpunkt oder ein Schlüssel. Das eigene Log des Erstellers zeigt, dass das Modell den Python-Klassennamen BrowserUseTool ausgab, obwohl der registrierte Toolname browser_use lautete – und dass der unmittelbar nächste Schritt desselben Laufs sauber weiterleitete, sobald browser_use aufgerufen wurde. Das eingefügte Log endet mit "Activating tool: 'browser_use'", und die abschließende Zeile enthält die gesamte Diagnose: "BrowserUseTool seems not work, but browser_use can". Der einzige Ratschlag eines Kommentators war, ein stärkeres Modell auszuprobieren; das ist für ein Problem der Tool-Calling-Treue die passende Einordnung.

Diese Diagnose lässt sich nicht auf die aktuelle Version von main übertragen, da es kein Tool namens browser_use mehr gibt, das man korrekt benennen könnte. Am 15. August 2026 löschten die Commits ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") und 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server") das lokale Browser-Tool. Eine Verzeichnisauflistung von app/tool/ auf main enthält kein browser_use_tool.py, und das einzige verbliebene Vorkommen der Zeichenfolge BrowserUseTool im Baum ist eine auskommentierte Zeile in app/agent/sandbox_agent.py.

Die heutige Lösung für genau diese Zeichenfolge besteht daher darin, Ihren Checkout zu aktualisieren und nicht mehr aus Tutorials zu schließen, die gegen den alten Repository-Pfad geschrieben wurden. Eine wichtige Einschränkung sollte ausdrücklich genannt werden: Wenn die MCP-Verbindung fehlschlägt, protokolliert app/agent/manus.py Failed to connect to Browser Use CLI 3.0 und läuft mit den vier lokalen Tools weiter; dadurch kann das Modell ein Browser-Tool benennen, das nicht registriert ist. Ob dies in der Praxis eine Unknown tool-Meldung erzeugt und unter welchem Namen, wurde hier nicht beobachtet – betrachten Sie es als Prüfpunkt, nicht als dokumentiertes Symptom. Beachten Sie außerdem, dass requirements.txt uv>=0.6.0 festlegt; ob eine normale Installation uvx in Ihrem PATH ablegt, wurde nicht überprüft.

Ein Punkt, den die Suche weiterhin hervorbringen wird und den die obigen Absätze bewusst nicht behaupten: Das Repository enthält tatsächlich Browser-Code, den der Standardpfad nie lädt. Der separate Daytona-Sandbox-Einstiegspunkt sandbox_main.py erstellt einen SandboxManus-Agenten, der SandboxBrowserTool aus app/tool/sandbox/sb_browser_tool.py als lokales Tool registriert – unter dem Namen sandbox_browser, nicht browser_use. „Kein lokales Browser-Tool“ bezieht sich daher auf den standardmäßigen Manus-Agenten, den Sie über main.py erhalten, nicht auf den gesamten Baum.

Ein Name, den Sie bei der Suche auseinanderhalten sollten: OpenManus/OpenManus-RL ist ein separates Repository in einer separaten Organisation, ein Forschungsprojekt zum Reinforcement Learning und keine Version der Agentenlaufzeit; seine Dateistruktur sagt über keinen der beiden Fehler etwas aus.

Was ein anderer API-Endpunkt ändert – und was nicht

Beide oben genannten Symptome entstehen innerhalb von OpenManus; die ehrliche Antwort auf „Behebt ein anderer Anbieter das?“ lautet daher nein. Die Wahl des Endpunkts beeinflusst jedoch eine nahe Gruppe von Fehlern, die leicht mit diesen beiden verwechselt werden.

Bei dieser fünften Zeile gibt es ein Detail aus erster Hand, das für diesen Endpunkt spezifisch ist und keine allgemeine Empfehlung darstellt. Kunavos Dispatcher entfernt temperature, top_p und top_k vor der Weiterleitung für die Katalogmodelle, die diese Parameter als nicht unterstützt deklarieren – derzeit 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 – und tut dies beim Protokollwechsel; daher sieht auch jeder Wiederholungsversuch den bereits bereinigten Body. Bei allen anderen Modellen wird das Feld so weitergeleitet, wie OpenManus es gesendet hat. Das entfernt einen bestimmten 400-Fehler für diese Modelle; es ist keine Behauptung, dass OpenManus hier getestet wurde. Kunavo hat OpenManus nicht zur Laufzeit getestet, und nichts auf dieser Seite ist ein Kompatibilitätsergebnis.

Wenn Sie Routen statt eines einzelnen Fehlers abwägen, behandelt OpenAI-kompatible API, was der generische Pfad überträgt und was nicht, LLM-Gateway, wann sich ein Schlüssel über mehrere Modellfamilien lohnt, und KI-Kostenoptimierung den Unterschied zwischen dem günstigsten aufgeführten Tarif und der günstigsten Möglichkeit, eine Aufgabe abzuschließen – eine Unterscheidung, die bei einer Agentenschleife entscheidend ist. Eine Diagnose derselben Art für einen anderen Client finden Sie unter OpenCode provider not found.

Richten Sie OpenManus ein, statt es zu reparieren? Die Endpunktseite besteht aus drei Feldern in [llm]: model, base_url und api_key. Beginnen Sie mit dem Quickstart, prüfen Sie die Anfrageform gegen Chat Completions und erstellen Sie ein Kunavo-Konto, sobald Sie einen Schlüssel finanzieren möchten. Halten Sie während des Ausprobierens eine funktionierende Route bereit und führen Sie eine begrenzte Aufgabe aus, bevor Sie etwas anderes ändern.

Häufig gestellte Fragen

Geprüft am 21. September 2026 und nicht umfassender: 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 und das README auf dem Branch main; eine Verzeichnisauflistung von app/tool/; die Commit-Historie des gelöschten Browser-Tools; die GitHub-Datensätze zu den Issues #779 und #789, ihren Kommentaren sowie den Pull Requests #1348, #1391 und #1407; die Repository- und Release-Metadaten; und Anthropics Seite zur Model-Abkündigung. Es wurde nichts ausgeführt – keine Installation, kein OpenManus-Lauf, keine Reproduktion eines der beiden Fehler und keine Anfrage über OpenManus an irgendeinen Endpunkt –, daher stammt jede Verhaltensaussage hier aus der Lektüre der Quellen und nicht aus einem beobachteten Fehler; ein erfolgreicher Minimal-Lauf wird nicht berichtet, weil keiner durchgeführt wurde. Kunavos Token-Tarife stammen aus dem aktuellen Katalog, und jeder Dollarbetrag ist eine beispielhafte Tokenrechnung statt gemessener Aufgabenkosten.