Boucles infinies et consommation de tokens de Nanobot : diagnostiquer un parcours Dream plafonné

Une exécution nanobot qui ressemble à une boucle infinie est une exécution bornée : dans le code source livré de la v0.3.5, chaque tour d’agent est plafonné par agents.defaults.maxToolIterations, dont la valeur par défaut est 200, et un mainteneur affirme publiquement qu’il ne s’agit pas d’une boucle littéralement infinie. Le véritable problème est la consommation de tokens, car une exécution qui atteint ce plafond journalise 201 tours d’assistant et renvoie un prompt de plus en plus long à chaque fois. Déterminer lequel de ces cas vous concerne est un diagnostic en quatre questions, et la correction étayée par des preuves n’est pas une valeur de configuration.

Commencez par écarter la fausse piste évidente. Le rapport amont est l’issue #5781, dont le titre mentionne dream.maxIterations, et la PR #5782 est intitulée « fix(dream): enforce configured iteration limit ». Cette clé n’existe pas dans v0.3.5, et la PR a été fermée sans fusion le 16 septembre 2026. Un tutoriel fondé dessus ne configure donc rien.

Une précision, car la requête fait remonter le mauvais tracker. Cette page concerne HKUDS/nanobot, sous licence MIT, installé comme paquet PyPI nanobot-ai — 0.3.5, Python 3.11 ou version ultérieure, téléversé le 15 septembre 2026. obot-platform/nanobot est un autre projet Go dont le README indique le mode maintenance avec les issues désactivées ; ses numéros d’issues ne constituent pas des preuves ici. Et pip install nanobot, sans suffixe, installe un paquet indépendant de navigation robotique.

Ce qui a été signalé, et pour quelle version

Dream est la tâche planifiée de consolidation de la mémoire de nanobot, exécutée par la passerelle comme une tâche cron nommée dream. Ce n’est pas une tâche d’embeddings ou d’index vectoriel : Kunavo ne fournit aucun modèle d’embeddings, et Dream n’en a pas besoin, car la mémoire persistante de nanobot est constituée de simples fichiers dans l’espace de travail et une exécution Dream correspond à du trafic de chat ordinaire.

L’issue #5781 a été ouverte le 15 septembre 2026 par BrianMwangi21 contre nanobot v0.3.0, sous Python 3.12 avec un modèle de raisonnement atteint via OpenRouter. Le symptôme : la tâche Dream alternait read_file sur memory/history.jsonl avec read_file sur un seul SKILL.md, des dizaines de fois, tandis que la trace de raisonnement redélibérait sur l’emplacement où déposer un seul petit fait. Sept exécutions consignées sur environ 26 heures allaient d’environ 25 minutes à environ 111 minutes ; celles proches de 200 appels d’outils atteignaient le plafond global, et un point de contrôle de session affichait runtime_checkpoint.iteration: 164, phase tools_completed, lors du même appel read_file.

Trois limites de portée accompagnent ces chiffres. Il s’agit des journaux de passerelle déclarés par un seul utilisateur, sur un seul modèle, en v0.3.0 — aucun mainteneur ne les a reproduits et personne ne les a retestés en v0.3.5. Le problème est marqué enhancement et priority: p2, et non bug, et il est toujours ouvert. Cette situation s’est déjà produite : le problème n° 3073, une boucle read_file presque identique sur history.jsonl datant du 12 avril 2026, a été fermé non prévu. Rien de tout cela ne permet d’affirmer que nanobot est généralement coûteux ; cela justifie de vérifier si votre propre installation se comporte ainsi.

La clé obsolète et la limite réellement active

Toute la confusion vient d’un écart de version, et la source tranche la question. Consultez les deux balises de version du 21 septembre 2026 :

Deux éléments rendent ce tableau facile à interpréter incorrectement. Le 200 est vrai deux fois : c’est la valeur de la configuration du rapporteur et la valeur par défaut fournie à la ligne 129 de nanobot/config/schema.py, identique dans la balise v0.3.5 et sur main, de sorte qu’un lecteur qui ne l’a jamais défini a tout de même 200. Et ce nombre n’est pas documenté : une récupération de la référence de configuration 0.3.5 de nanobot lui-même, le 21 septembre 2026, a renvoyé 488,608 octets de HTML avec zéro occurrence de maxToolIterations, et le docs/configuration.md du dépôt à cette balise n’en contient pas non plus. Ce nombre est vérifiable dans le code source et dans un commentaire de mainteneur, pas dans une page de documentation — méfiez-vous donc de tout tutoriel citant un autre chiffre.

modelOverride est le seul remède soumis à une condition de version. En v0.3.0, le champ existait avec le commentaire en attente d’implémentation et aucun code de résolution ; la PR #5107, fusionnée le 27 juillet 2026, l’a implémenté pour v0.3.5. La page mémoire officielle 0.3.5 indique qu’il sélectionne une entrée nommée dans model_presets pour Dream, accepte uniquement les noms de préréglages et que les identifiants de modèle bruts ne sont pas pris en charge. Cette page documente trois clés Dream et ne mentionne nulle part de limite d’itérations. Voici la surface complète actuelle, avec le bloc providers dont elle dépend, couvert sur la page de configuration de nanobot :

{
  "modelPresets": {
    "dream-cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192
    }
  },
  "agents": {
    "defaults": {
      "maxToolIterations": 200,
      "dream": {
        "enabled": true,
        "intervalH": 2,
        "modelOverride": "dream-cheap"
      }
    }
  }
}

Notez ce qui ne figure pas dans ce fichier : aucun moyen de limiter Dream seul. AgentLoop est construit une fois avec max_iterations à partir des valeurs par défaut du processus, et le chemin cron de Dream comme le chemin manuel /dream appellent process_direct(...) sans argument d’itération, tout comme les sous-agents. Réduire la limite la réduit donc simultanément pour le chat, Dream, le heartbeat et les sous-agents.

Diagnostiquez dans cet ordre

Répondez à ces quatre questions avant de modifier quoi que ce soit, car trois sont gratuites et la quatrième indique si les trois premières sont pertinentes. Les chaînes des journaux sont le texte littéral de v0.3.5 ; les accolades représentent des valeurs d’exécution.

Vous n’avez pas besoin d’attendre deux heures le tick cron pour reproduire le problème. La commande /dream exécute le même travail à la demande et signale la même distinction dans le chat : Dream completed in Ns. ou Dream completed in Ns; no memory changes. en cas de succès, contre Dream did not complete after Ns (reason); memory cursor was not advanced. lorsqu’il ne se termine pas. Une autre modification de v0.3.5 compte lorsque vous cherchez des preuves : les fichiers JSONL de session ont été déplacés sous l’arborescence sessions/<workspace-id>/ du répertoire de configuration, de sorte que les chemins v0.3.0 cités dans le fil du problème ne correspondent pas à l’emplacement de votre point de contrôle.

Cinq leviers et ce que chacun permet réellement de justifier

Les deux identifiants de modèle du rapporteur étaient deepseek/deepseek-v4-flash-0731 et openai/gpt-5.6-luna tels qu’il les a écrits via OpenRouter ; ces identifiants et leurs prix n’ont pas été vérifiés ici. Considérez donc cette comparaison comme un élément montrant que le modèle détermine la convergence, et non comme une recommandation de l’un ou l’autre. L’amont est parvenu à la même conclusion : en annonçant la clôture de la PR #5782 sur le problème #5781, chengyongru a écrit qu’une limite fixe d’itérations de Dream ne traite pas le problème sous-jacent de convergence dépendante du modèle et peut entraîner le retentissement répété d’exécutions autrement viables.

Coût d’une exécution limitée : calcul illustratif

Il s’agit de calculs illustratifs de jetons, pas du coût mesuré d’une tâche ni d’un plafond de facturation. nanobot ne publie aucun nombre de jetons par exécution pour Dream ; chaque donnée d’entrée est donc une hypothèse à remplacer par vos propres mesures. Supposons une exécution qui atteint la limite à 201 tours d’assistant — le nombre de l’audit du rapporteur — chacun renvoyant une invite maintenue à 25,000 jetons, ce qui décrit son propre espace de travail, et non une valeur publiée. Cela représente 5.03M jetons d’entrée. Les jetons de sortie sont exclus, et une véritable invite s’allonge avec chaque résultat d’outil ; ce calcul sous-estime donc une exécution réelle de deux façons à la fois. Les tarifs sont les prix actuels du catalogue Kunavo.

La dernière colonne suppose un cas optimal que rien ici n’a testé : le premier envoi au tarif d’entrée ordinaire et tous les 200 renvois servis comme lectures du cache. Une écriture dans le cache est facturée à son propre tarif, qui pour certains modèles est supérieur au tarif d’entrée ordinaire ; une entrée de cache expire ; et une invite qui s’allonge est réécrite plutôt que relue. Considérez donc l’écart entre les deux dernières colonnes comme l’ampleur du gain possible, et non comme un devis. Le seul point est que, lors d’une longue exécution répétitive, c’est le renvoi, et non le modèle, qui représente la dépense.

La question de savoir si les marqueurs de cache atteignent réellement le réseau est déterminée par votre configuration nanobot, et cela est visible dans le code source fourni. Une clé de fournisseur inventée sous providers est traitée comme un fournisseur compatible OpenAI ordinaire et laisse supports_prompt_caching à sa valeur par défaut false ; le client de nanobot n’envoie donc aucun marqueur cache_control sur ce chemin, même pour un identifiant de modèle de type Claude. Conserver le préréglage du fournisseur intégré anthropic et remplacer providers.anthropic.apiBase les maintient. Cela décrit ce qu’envoie le client nanobot, et non ce que fait un quelconque point de terminaison de son côté, et Kunavo n’a pas testé nanobot en conditions d’exécution. Consultez l’utilisation renvoyée par un appel réel avant de budgétiser un travail récurrent comme mis en cache — la documentation du cache montre à quoi ressemble un cache fonctionnel et la référence de l’URL de base fournit les deux conventions de point de terminaison.

Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque l’amont communique son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimal est de $10 en crédit prépayé — un minimum de financement, et non des frais de tâche ni un abonnement. Consultez les détails de facturation et l’optimisation des coûts pour connaître la méthode de mesure qui remplace les hypothèses ci-dessus.

Vérifier la correction sur une exécution

Modifiez une seule chose, puis exécutez /dream une fois au lieu d’attendre la planification, et vérifiez les trois marqueurs dans l’ordre : aucun avertissement Max iterations (200) reached, une ligne cursor advanced to … plutôt que cursor remains at …, et un nombre plausible d’appels d’outils entre les deux. Lisez ensuite le montant enregistré par votre propre compte pour cette période, par clé et par jour, dans usage ; le stockage de nanobot compte les jetons, pas l’argent. Si vous configurez le point de terminaison pour la première fois, le démarrage rapide et la page de configuration de nanobot couvrent les deux chemins de protocole, et la création d’un compte Kunavo est l’étape préalable au financement d’une clé. Vous comparez plutôt les durées d’exécution ? nanobot contre OpenClaw met les deux cadences d’arrière-plan côte à côte, et le répertoire des API d’agents indexe les clients par protocole réseau.

Questions fréquentes

Vérifié le 21 septembre 2026 : l’API GitHub pour HKUDS/nanobot, ainsi que pour les problèmes #5781, #5324 et #3073 et les pull requests #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 et #4622 ; l’enregistrement PyPI de nanobot-ai 0.3.5 ; la documentation mémoire et configuration 0.3.5 de nanobot ; et le code source fourni à la balise v0.3.5 pour chaque valeur par défaut, chaîne de journal et chemin de code cités ci-dessus, comparés à v0.3.0 lorsque les deux diffèrent. Kunavo n’a ni installé ni exécuté nanobot, aucun comportement décrit ici n’a été testé par Kunavo, et la boucle du problème #5781 n’a été retestée par personne sur v0.3.5. Les tarifs des jetons proviennent du catalogue actuel et chaque montant en dollars correspond à un calcul illustratif fondé sur les hypothèses indiquées.