OpenManus n’applique par défaut aucune limite de jetons. Son propre plafond est max_input_tokens, que app/config.py déclare comme Optional avec une valeur par défaut de None et la description « Maximum input tokens to use across all requests (None for unlimited) », et qui n’apparaît dans aucun exemple de configuration fourni. Une installation standard ne lève donc jamais sa propre erreur de limite de jetons — tout ce que vous avez rencontré venait du fournisseur. Lorsque vous le définissez, il se comporte de deux façons auxquelles on ne s’attend pas, et un défaut présent dans l’actuel main le fait échouer lentement plutôt que rapidement.
L’autre erreur traitée par cette page, Error: Unknown tool 'BrowserUseTool', n’est pas du tout un bug actuel. La classe qu’elle nomme a été supprimée d’OpenManus le 15 août 2026, et l’agent Manus par défaut de l’actuel main n’enregistre localement aucun outil de navigateur. Aucun de ces symptômes ne relève de la clé API, de l’endpoint ou du fournisseur, et rediriger base_url ne corrige ni l’un ni l’autre.
Une précision de cadrage avant de commencer. Il n’existe aucune version d’OpenManus à citer : les trois seuls tags, v0.1.0, v0.2.0 et v0.3.0, ont été tous publiés à moins de 34 secondes d’intervalle le 10 avril 2025, et aucun tag n’a été créé depuis, de sorte que tout le monde exécute le main sans tag. Le dépôt canonique est FoundationAgents/OpenManus — non archivé, sous licence MIT, 58,371 étoiles, dernier push le 22 août 2026 (API GitHub, 21 septembre 2026). L’ancien chemin mannaandpoem/OpenManus est désormais un README factice indiquant que le projet a été déplacé ; les chemins de fichiers et numéros de ligne cités dans les tutoriels de 2025 renvoient donc à du code qui n’existe plus. Tout ce qui suit a été lu dans les sources sur la branche main le 21 septembre 2026 et rien n’a été exécuté.
Lequel des quatre messages avez-vous réellement ?
| Ce que vous voyez | Qui l’affiche | Signification |
|---|---|---|
Maximum token limit reached, cannot continue execution: Request may exceed input token limit (Current: …, Needed: …, Max: …) | OpenManus, app/agent/toolcall.py | Le plafond max_input_tokens que vous aviez défini pour l’exécution a été atteint. Aucune requête n’a été envoyée |
| Une erreur de longueur de contexte ou de jetons mentionnant le modèle | Votre fournisseur, via OpenAIError | La requête dépassait la fenêtre de contexte du modèle ou la propre limite de l’endpoint. Sans rapport avec le plafond d’OpenManus |
Error: Unknown tool 'X' | OpenManus, lignes 179–181 de app/agent/toolcall.py | Le modèle a nommé un outil absent de available_tools.tool_map. Renvoyé comme résultat d’outil, le message permet donc à la boucle de continuer et consomme une étape |
Failed to connect to Browser Use CLI 3.0: … | OpenManus, ligne 99 de app/agent/manus.py | Le serveur MCP de navigateur par défaut n’a pas démarré. L’exécution continue : l’agent Manus conserve ses quatre outils locaux, ainsi que les autres serveurs MCP que vous avez configurés |
La distribution qui produit la troisième ligne tient en trois lignes et n’a pas changé avec la réécriture du navigateur en 2026 : name = command.function.name, puis if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". Rien ne lui est propre aux navigateurs ; la même chaîne apparaît donc pour tout outil inventé par un modèle.
La limite de jetons est facultative, cumulative et approximative
Trois nombres différents sont appelés « la limite de jetons », et le message d’erreur ne concerne jamais que l’un d’eux.
| Paramètre | Ce qu’elle borne | Par défaut | Dans l’exemple fourni ? |
|---|---|---|---|
max_tokens | Une réponse | 4096 dans le code | Oui — définie sur 8192 |
max_input_tokens | Entrées cumulées sur toute l’exécution | None, c’est-à-dire illimitée | Non. Vous l’ajoutez manuellement, sinon elle ne s’applique pas |
| La fenêtre de contexte du modèle | Une requête, chez le fournisseur | Celle du modèle | Ce n’est pas un paramètre d’OpenManus |
La deuxième ligne est celle qui surprend. LLM.check_token_limit() dans app/llm.py renvoie (self.total_input_tokens + input_tokens) <= self.max_input_tokens — un total cumulatif pour la session, et non un contrôle sur une seule requête. Une longue exécution d’agent peut donc la déclencher par accumulation, même lorsque chaque requête individuelle est petite, et le texte de l’erreur détaille le calcul : actuel, nécessaire, maximum. L’agent Manus par défaut définit max_steps = 20, et chaque étape renvoie toute la conversation accumulée, de sorte que le total cumulatif augmente plus vite que le nombre d’étapes.
Le décompte est également une estimation propre à OpenManus. LLM.__init__ appelle tiktoken.encoding_for_model(self.model) et revient à cl100k_base en cas de KeyError, donc, pour tout identifiant de modèle sans préréglage tiktoken — un identifiant Claude ou Gemini, ou un identifiant préfixé par une passerelle — le budget appliqué est une approximation plutôt que le décompte du fournisseur.
# 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 = 400000La valeur monétaire d’un plafond
Puisque max_input_tokens borne les entrées cumulées, il se convertit directement en plafond de coût pour le côté entrée d’une exécution. Les chiffres ci-dessous sont des calculs illustratifs de jetons fondés sur le plafond indiqué, et non le coût mesuré d’une tâche ni un plafond de facturation : ils tarifent les jetons d’entrée plafonnés par le paramètre, aux taux du catalogue Kunavo en vigueur par million. La sortie n’est pas couverte par ce paramètre — la dernière colonne facture une réponse au max_tokens = 8192 fourni par l’exemple de configuration, et une exécution de vingt étapes peut en produire vingt.
| Modèle | Entrée / sortie par million | Entrée avec un plafond de 100,000 | Entrée avec un plafond de 400,000 | Une réponse de 8,192 jetons |
|---|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.070 | $0.280 | $0.029 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.070 | $0.280 | $0.034 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.210 | $0.840 | $0.086 |
| Claude Opus 5 | $3.50 / $17.50 | $0.350 | $1.400 | $0.143 |
Deux interprétations. Un plafond est un arrêt, pas un budget : il indique le coût maximal du côté entrée d’une exécution, sans rien dire sur l’achèvement de la tâche. Et puisque OpenManus compte avec tiktoken, le plafond qu’il applique et les jetons facturés par votre fournisseur sont deux mesures différentes — définissez le nombre pour limiter une boucle incontrôlée, puis comparez-le à ce que votre compte a réellement enregistré. Le montant du catalogue Kunavo est un seuil de facturation plutôt qu’un plafond : lorsque l’amont signale son coût, la facture est le montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimal Kunavo est de $10 de crédit prépayé, un minimum de financement et non des frais de tâche ou un abonnement — voir les détails de facturation.
Pourquoi l’erreur de jetons arrive tard
Il s’agit d’un défaut lisible dans l’actuel main, et c’est pourquoi un échec de limite de jetons ressemble à un blocage. Les trois décorateurs @retry dans app/llm.py — sur ask, ask_with_images et ask_tool — sont écrits à l’identique :
| Ce que dit le décorateur | Ce qu’il intercepte | Conséquence |
|---|---|---|
Commentaire final : # Don't retry TokenLimitExceeded | retry_if_exception_type((OpenAIError, Exception, ValueError)) | TokenLimitExceeded est une sous-classe de OpenManusError, elle-même sous-classe de Exception — l’entrée nue Exception l’intercepte donc |
Commentaire du site de levée : # Raise a special exception that won't be retried | stop_after_attempt(6), wait_random_exponential(min=1, max=60) | Jusqu’à six tentatives avec temporisation exponentielle avant que l’erreur n’apparaisse, chacune recalculant le même total en échec |
La boucle d’agent en aval confirme la structure au lieu de la contredire. app/agent/toolcall.py intercepte l’exception et teste isinstance(e.__cause__, TokenLimitExceeded) — ce déballage __cause__ est la manière dont un RetryError de tenacity arrive, et sa propre ligne de journal indique « Token limit error (from RetryError) ». Ce n’est qu’alors qu’il ajoute le message visible par l’utilisateur « Maximum token limit reached, cannot continue execution » et définit l’état de l’agent sur finished. Autrement dit, le code consommateur suppose déjà la nouvelle tentative que le commentaire du décorateur dit ne pas avoir lieu.
Il n’existe aucun correctif fusionné. La PR #1348, intitulée « fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback », a été fermée sans fusion le 10 août 2026 ; sa soumission suivante #1407 était toujours ouverte et non fusionnée le 21 septembre 2026. Une PR connexe sur le dépassement de contexte, #1391, « add tool description token budget to prevent context overflow », a été fermée sans fusion le 18 août 2026. La raison de leur fermeture n’a pas été examinée ici ; seul le fait qu’elles ne sont pas fusionnées l’a été. Le rapport historique, issue #779 « hitting token limit » du 17 mars 2025, a été fermé le 17 septembre 2026 par un bot d’inactivité avec state_reason: not_planned — une expiration, pas une résolution. Tant que l’un de ces correctifs n’est pas intégré, les mesures pratiques consistent à laisser max_input_tokens non défini et à laisser le fournisseur rejeter les requêtes trop volumineuses, ou à le définir en acceptant le délai.
Unknown tool 'BrowserUseTool' est une erreur provenant d’une version qui n’existe plus
Issue #789, « Result: Error: Unknown tool 'BrowserUseTool' », a été ouverte le 18 mars 2025 et était toujours ouverte le 21 septembre 2026, étiquetée inactive. Sa cause n’a jamais été un endpoint ou une clé. Le journal du rapporteur montre que le modèle émettait le nom de classe Python, BrowserUseTool, alors que le nom de l’outil enregistré était browser_use — et que l’étape suivante de la même exécution s’est correctement distribuée dès qu’il a appelé browser_use. Le journal copié se termine par « Activating tool: 'browser_use' », et sa dernière ligne constitue tout le diagnostic : « BrowserUseTool seems not work, but browser_use can ». Le seul conseil donné par un commentateur était d’essayer un modèle plus puissant, ce qui correspond bien à un problème de fiabilité des appels d’outils.
Ce diagnostic ne s’applique pas à l’actuel main, car il n’existe plus d’outil nommé browser_use à appeler correctement. Le 15 août 2026, les commits ab8dfe43 (« feat(browser): use Browser Use CLI 3.0 ») et 05c5bbb1 (« refactor(browser): use CLI 3.0 MCP server ») ont supprimé l’outil de navigateur local. Une liste du répertoire app/tool/ sur main ne contient aucun browser_use_tool.py, et la seule occurrence restante de la chaîne BrowserUseTool dans l’arborescence est une ligne commentée dans app/agent/sandbox_agent.py.
| Code de mars 2025 (issue #789) | main actuel, lu le 21 septembre 2026 | |
|---|---|---|
| Outil de navigateur | Classe locale dans app/tool/browser_use_tool.py | Supprimée. Dans l’agent Manus par défaut, un serveur MCP hors processus est lancé avec uvx browser-use --cli-mcp |
| Nom enregistré | browser_use | browser_exec et browser_screenshot, selon le README |
| Outils enregistrés localement sur l’agent Manus | Incluait l’outil de navigateur | PythonExecute, StrReplaceEditor, AskHuman, Terminate — les outils de navigateur arrivent via MCP |
| Dépendance épinglée | Épinglée dans requirements.txt | Aucune entrée browser-use ; récupérée au moment de l’exécution par uvx, de sorte que la pile de navigateur évolue indépendamment de votre checkout |
| Identifiants | Votre clé de modèle | Le mode local ne nécessite aucune clé. Le mode cloud est un compte Browser Use distinct avec ses propres variables d’environnement |
| Désactivation | Supprimer l’outil | OPENMANUS_DISABLE_BROWSER_USE=1 |
La correction de cette chaîne précise consiste donc aujourd’hui à mettre à jour votre checkout et à cesser de vous fonder sur des tutoriels écrits pour l’ancien chemin du dépôt. Une réserve mérite d’être énoncée plutôt que devinée : lorsque la connexion MCP échoue, app/agent/manus.py journalise Failed to connect to Browser Use CLI 3.0 et continue avec les quatre outils locaux, ce qui permet au modèle de nommer un outil de navigateur qui n’est pas enregistré. La question de savoir si cela produit en pratique un message Unknown tool, et sous quel nom, n’a pas été observée ici — considérez cela comme un point à examiner, et non comme un symptôme documenté. Notez également que requirements.txt épingle uv>=0.6.0 ; il n’a pas été vérifié si une installation normale place uvx sur votre PATH.
Un élément ressortira encore des recherches, et les paragraphes ci-dessus ne prétendent volontairement pas le contraire : le dépôt contient bien du code de navigateur que le chemin par défaut ne charge jamais. Le point d’entrée séparé du bac à sable Daytona, sandbox_main.py, construit un agent SandboxManus qui enregistre SandboxBrowserTool depuis app/tool/sandbox/sb_browser_tool.py comme outil local — sous le nom sandbox_browser, et non browser_use. Ainsi, « aucun outil de navigateur local » concerne l’agent Manus par défaut obtenu depuis main.py, et non l’ensemble de l’arborescence.
Un nom à garder à part pendant vos recherches : OpenManus/OpenManus-RL est un dépôt distinct dans une organisation distincte, un projet de recherche en apprentissage par renforcement plutôt qu’une version de l’environnement d’exécution de l’agent, et sa structure de fichiers ne permet de tirer aucune conclusion sur l’une ou l’autre erreur.
Ce qu’un autre endpoint d’API modifie ou non
Les deux symptômes ci-dessus sont produits à l’intérieur d’OpenManus ; la réponse honnête à « un autre fournisseur corrigera-t-il cela ? » est donc non. En revanche, le choix de l’endpoint influence un ensemble voisin d’échecs qu’il est facile de confondre avec ces deux-là.
| Échec | Dépend-il de l’endpoint ? | Première vérification |
|---|---|---|
| Message de limite de jetons propre à OpenManus | Non — levé avant l’envoi de toute requête | Votre valeur max_input_tokens, et le fait que vous ayez voulu en définir une |
Unknown tool | Non — le modèle a nommé quelque chose qui n’est pas enregistré | Les outils enregistrés par cet agent, et l’aptitude du modèle à appeler des outils |
| Rejet de longueur de contexte par le fournisseur | Oui | La fenêtre de contexte du modèle et max_tokens par rapport à celle-ci |
| Erreur d’authentification ou de modèle introuvable lors d’une première exécution | Oui | L’exemple fourni nomme encore un identifiant Claude qu’Anthropic a retiré le 19 février 2026 — traité dans Tarification et configuration de l’API OpenManus |
Erreur 400 sur temperature | Oui | OpenManus envoie temperature à chaque requête en dehors de ses deux identifiants de raisonnement codés en dur, et fournit temperature = 0.0 |
| Captures d’écran n’arrivant silencieusement jamais au modèle | Partiellement | La vision est conditionnée par une correspondance exacte avec six identifiants de modèle codés en dur, dont tous ceux d’Anthropic ont été retirés. Également traité sur la page de configuration |
Pour cette cinquième ligne, un détail de première partie propre à cet endpoint plutôt qu’un conseil général. Le répartiteur de Kunavo supprime temperature, top_p et top_k avant le transfert, pour les modèles du catalogue qui déclarent ces paramètres non pris en charge — actuellement 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 — et le fait au niveau du changement de protocole ; le corps dépouillé est donc aussi celui que voit toute tentative ultérieure. Pour tous les autres modèles, le champ est transmis tel qu’OpenManus l’a envoyé. Cela supprime une erreur 400 précise pour ces modèles ; ce n’est pas l’affirmation qu’OpenManus a été testé ici. Kunavo n’a pas testé OpenManus en conditions d’exécution, et rien sur cette page ne constitue un résultat de compatibilité.
Si vous comparez des voies plutôt que de déboguer un cas précis, API compatible OpenAI couvre ce que le chemin générique transporte ou non, passerelle LLM explique quand une clé unique pour plusieurs familles vaut la peine, et optimisation des coûts d’IA traite la différence entre le tarif affiché le moins cher et la manière la moins chère d’achever une tâche — distinction décisive pour une boucle d’agent. Pour le même type de diagnostic sur un autre client, consultez Fournisseur introuvable dans OpenCode.
Vous configurez OpenManus plutôt que de le réparer ? Le côté endpoint tient en trois champs dans [llm] : model, base_url et api_key. Commencez par le démarrage rapide, vérifiez la forme de la requête avec les complétions de chat, puis créez un compte Kunavo lorsque vous êtes prêt à approvisionner une clé. Gardez une route fonctionnelle à disposition pendant vos essais et exécutez une tâche limitée avant de modifier quoi que ce soit d’autre.
Questions fréquentes
Quelle est la limite de jetons d'OpenManus ?
Par défaut, il n'y en a aucune. Le propre plafond d'OpenManus est le champ max_input_tokens, que app/config.py déclare comme Optional avec une valeur par défaut de None décrite comme « illimité », et qui n'apparaît dans aucun exemple de configuration fourni — une installation standard ne déclenche donc jamais sa propre erreur de limite de jetons, et toute limite rencontrée provient du fournisseur. Lorsque vous le définissez, LLM.check_token_limit() compare self.total_input_tokens + input_tokens à cette valeur, ce qui en fait un budget cumulatif d'entrée pour toute l'exécution, et non une vérification du contexte par requête. Il n'a aucun rapport avec la fenêtre de contexte du modèle, ni avec max_tokens, qui plafonne une réponse et est fourni comme 8192 dans config/config.example.toml. Les trois éléments ont été lus sur la branche main le 21 septembre 2026.
Pourquoi OpenManus se bloque-t-il avant de signaler la limite de jetons ?
Parce que l'erreur de limite est réessayée, malgré un commentaire indiquant le contraire. Les trois décorateurs @retry dans app/llm.py — sur ask, ask_with_images et ask_tool — sont écrits comme retry_if_exception_type((OpenAIError, Exception, ValueError)), avec le commentaire final « # Don't retry TokenLimitExceeded ». TokenLimitExceeded est une sous-classe de OpenManusError, lui-même sous-classe de Exception ; l'entrée Exception nue la capture donc, et tenacity réessaie jusqu'à stop_after_attempt(6), avec un délai wait_random_exponential(min=1, max=60). Le gestionnaire de l'agent confirme cette structure : app/agent/toolcall.py vérifie isinstance(e.__cause__, TokenLimitExceeded), ce qui explique l'arrivée d'une tenacity RetryError, puis affiche seulement « Maximum token limit reached, cannot continue execution ». Un correctif existe mais n'est pas fusionné : la PR #1348 a été fermée sans fusion le 10 août 2026, et sa nouvelle soumission #1407 était toujours ouverte et non fusionnée le 21 septembre 2026. Ceci provient de la lecture du code source, et non d'une reproduction par exécution.
Comment corriger l’erreur « Unknown tool 'BrowserUseTool' » dans OpenManus ?
Mettez à jour votre checkout, car cette classe n’existe pas dans le main actuel d’OpenManus. L’outil de navigateur local a été supprimé le 15 août 2026 dans les commits ab8dfe43 et 05c5bbb1 ; app/tool/ ne contient aucun browser_use_tool.py, et la seule occurrence de la chaîne BrowserUseTool dans l’arborescence est une ligne commentée dans app/agent/sandbox_agent.py. Dans l’agent Manus par défaut construit par main.py, les opérations de navigation sont désormais assurées par un serveur MCP hors processus lancé avec uvx browser-use --cli-mcp, qui expose des outils nommés browser_exec et browser_screenshot ; le point d’entrée séparé du bac à sable Daytona, sandbox_main.py, enregistre toujours son propre outil de navigateur local, nommé sandbox_browser. Dans le code de mars 2025 utilisé par le rapporteur de l’issue #789, la cause était que le modèle émettait le nom de la classe Python au lieu du nom de l’outil enregistré — leur propre journal montre que l’étape suivante s’exécutait correctement lorsqu’il appelait browser_use à la place, et leur dernière ligne indique « BrowserUseTool seems not work, but browser_use can ». La chaîne elle-même est générique : app/agent/toolcall.py renvoie f"Error: Unknown tool '{name}'" pour tout nom absent de available_tools.tool_map, donc le même message apparaît aujourd’hui pour tout outil inventé par le modèle.
L’issue #789 est-elle corrigée, et quelle version d’OpenManus contient le correctif ?
Elle n’est pas corrigée et il n’existe aucune version à citer. L’issue #789, « Result: Error: Unknown tool 'BrowserUseTool' », a été ouverte le 18 mars 2025 et était toujours ouverte le 21 septembre 2026, étiquetée inactive, avec trois commentaires — l’un suggérant un modèle plus puissant, le rapporteur acceptant d’en essayer un, et un bot d’inactivité. Le rapport connexe sur la limite de jetons, l’issue #779 « hitting token limit », a été fermé le 17 septembre 2026 par ce même bot d’inactivité avec state_reason not_planned, ce qui correspond à une expiration plutôt qu’à un correctif. Et OpenManus n’a aucune version actuelle à nommer : ses trois seuls tags, v0.1.0, v0.2.0 et v0.3.0, ont tous été publiés à moins de 34 secondes d’intervalle le 10 avril 2025, et aucun tag n’a été créé depuis, de sorte que tout le monde exécute le main sans tag. Citez une date de commit, pas un numéro de version.
Changer de fournisseur d’API corrigera-t-il une erreur de jetons ou d’outil d’OpenManus ?
Non, et il faut distinguer ces deux modes d’échec de ceux qui dépendent réellement du fournisseur. Le message de limite de jetons mentionné ci-dessus est produit par la propre comptabilité d’OpenManus par rapport au plafond que vous avez configuré, avant l’envoi de toute requête ; aucun endpoint ne peut donc le modifier. Le message Unknown tool est produit par le système de distribution d’outils d’OpenManus lorsque le modèle nomme quelque chose qui n’est pas enregistré, ce qui relève de la fiabilité des appels d’outils du modèle, et le seul conseil jamais donné dans l’issue #789 était d’essayer un autre modèle précisément pour cette raison. Ce qu’un autre endpoint modifie : un rejet de longueur de contexte côté fournisseur arrive sous la forme d’une OpenAIError plutôt que de TokenLimitExceeded ; une copie fraîche de l’exemple de configuration fourni échoue avec une erreur de modèle plutôt qu’une erreur de jetons, car elle nomme encore un identifiant Claude qu’Anthropic a retiré le 19 février 2026 ; et OpenManus envoie toujours une température en dehors de ses deux identifiants de raisonnement codés en dur, ce qui produit une erreur de type 400 sur les modèles dont le fournisseur a abandonné ce paramètre.
OpenManus compte-t-il les jetons de la même manière que mon fournisseur ?
Non. OpenManus compte localement avec tiktoken, et LLM.__init__ appelle tiktoken.encoding_for_model(self.model) dans un try qui revient à cl100k_base en cas de KeyError. Pour un identifiant Claude ou Gemini, ou tout identifiant préfixé par une passerelle pour lequel tiktoken ne possède aucun préréglage, le budget appliqué par OpenManus est une estimation cl100k_base plutôt que le décompte du fournisseur, et son TokenCounter ajoute ses propres constantes fixes — 4 jetons par message, 2 jetons de formatage, 85 pour une image avec peu de détails et 170 par tuile très détaillée. Comparez avec l’utilisation enregistrée par votre compte fournisseur, et non avec les totaux consignés par OpenManus. Vérifié sur la branche main, le 21 septembre 2026, avec tiktoken~=0.9.0 épinglé dans requirements.txt.
Vérifié le 21 septembre 2026, sans recherche plus large : 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 et le README sur la branche main ; une liste du répertoire app/tool/ ; l’historique des commits de l’outil de navigateur supprimé ; les enregistrements GitHub des issues #779 et #789, leurs commentaires, et les pull requests #1348, #1391 et #1407 ; les métadonnées du dépôt et des versions ; ainsi que la page de retrait des modèles d’Anthropic. Rien n’a été exécuté — aucune installation, aucune exécution d’OpenManus, aucune reproduction de l’une ou l’autre erreur et aucune requête via OpenManus sur aucun endpoint — ; toutes les affirmations comportementales reposent donc sur une lecture des sources plutôt que sur un échec observé, et aucune exécution minimale réussie n’est rapportée puisqu’aucune n’a été effectuée. Les tarifs de jetons Kunavo proviennent du catalogue en direct, et chaque montant en dollars correspond à un calcul illustratif de jetons plutôt qu’au coût mesuré d’une tâche.