Loop infiniti e utilizzo dei token in Nanobot: diagnosi di una run Dream con limite

Un'esecuzione nanobot che sembra un ciclo infinito è in realtà limitata: nel codice sorgente distribuito della v0.3.5 ogni turno dell'agente è limitato da agents.defaults.maxToolIterations, il cui valore predefinito è 200, e un manutentore ha dichiarato pubblicamente che non si tratta di un ciclo letteralmente infinito. Il vero problema è l'uso dei token, perché un'esecuzione che raggiunge quel limite registra 201 turni dell'assistente e reinvia ogni volta un prompt sempre più grande. Capire quale dei due casi hai davanti richiede una diagnosi in quattro domande; la correzione supportata dalle prove non è un valore di configurazione.

Inizia eliminando l'ipotesi più ovvia. La segnalazione upstream è il problema #5781, il cui titolo rimanda a dream.maxIterations, mentre PR #5782 si intitola "fix(dream): enforce configured iteration limit". Quella chiave non esiste nella v0.3.5 e la PR è stata chiusa senza merge il 16 settembre 2026. Un tutorial basato su di essa non configura nulla.

Un chiarimento, perché i risultati della ricerca mostrano il tracker sbagliato. Questa pagina riguarda HKUDS/nanobot, MIT, installato come pacchetto PyPI nanobot-ai — 0.3.5, Python 3.11 o successivo, caricato il 15 settembre 2026. obot-platform/nanobot è un progetto Go diverso, il cui README dichiara la modalità di manutenzione con le issue disabilitate; i suoi numeri di issue non costituiscono una prova in questo contesto. Inoltre, pip install nanobot, senza suffisso, installa un pacchetto di navigazione robotica non correlato.

Cosa è stato segnalato e contro quale versione

Dream è l'attività pianificata di consolidamento della memoria di nanobot, eseguita dal gateway come cron job denominato dream. Non è un'attività di embedding o di indice vettoriale: Kunavo non fornisce alcun modello di embedding e Dream non ne ha bisogno, perché la memoria persistente di nanobot è costituita da semplici file nel workspace e un'esecuzione Dream è normale traffico di chat.

Il problema #5781 è stato aperto il 15 settembre 2026 da BrianMwangi21 contro nanobot v0.3.0, su Python 3.12 con un modello di ragionamento raggiunto tramite OpenRouter. Il sintomo: l'attività Dream alternava read_file su memory/history.jsonl con read_file su una singola SKILL.md, per decine di volte, mentre la traccia di ragionamento riconsiderava dove archiviare un unico piccolo fatto. Sette esecuzioni registrate in circa 26 ore duravano da circa 25 minuti a circa 111 minuti; quelle vicine a 200 chiamate agli strumenti raggiungevano il limite globale e un checkpoint della sessione mostrava runtime_checkpoint.iteration: 164, fase tools_completed, sulla stessa chiamata read_file.

Tretti limiti di ambito accompagnano quei numeri. Si tratta dei log del gateway riferiti da un singolo utente, su un solo modello, in v0.3.0 — nessun manutentore li ha riprodotti e nessuno ha ripetuto i test su v0.3.5. Il problema è contrassegnato come enhancement e priority: p2, non come bug, ed è ancora aperto. Inoltre, questa situazione si è già verificata: issue #3073, un ciclo read_file quasi identico su history.jsonl del 12 aprile 2026, è stato chiuso come non pianificato. Nulla di tutto questo dimostra che nanobot sia generalmente costoso; dimostra che conviene verificare se la propria installazione si sta comportando così.

La chiave deprecata e il limite effettivamente attivo

L'intera confusione deriva da una differenza di versione, e la fonte la risolve. Consultare i due tag di release del 21 settembre 2026:

Due elementi rendono facile interpretare male quella tabella. Il 200 è vero due volte: è il valore nella configurazione del segnalatore e il valore predefinito distribuito alla riga 129 di nanobot/config/schema.py, identico nel tag v0.3.5 e su main, quindi anche chi non lo ha mai impostato ha 200. Inoltre, non è documentato: il recupero della documentazione di riferimento della configurazione 0.3.5 di nanobot stesso il 21 settembre 2026 ha restituito 488.608 byte di HTML con zero occorrenze di maxToolIterations, e nemmeno il file docs/configuration.md del repository a quel tag ne contiene. Il numero è dimostrabile dal codice sorgente e da un commento di un manutentore, non da una pagina di documentazione: quindi qualsiasi tutorial che citi una cifra diversa va considerato con sospetto.

modelOverride è l'unico rimedio con un vincolo di versione. In v0.3.0 il campo esisteva con il commento in attesa di implementazione e senza alcun codice che lo risolvesse; PR #5107, unita il 27 luglio 2026, lo ha implementato per v0.3.5. La pagina ufficiale sulla memoria 0.3.5 afferma che seleziona una voce denominata da model_presets, accetta solo nomi di preset e che gli identificatori di modello grezzi non sono supportati. La pagina documenta tre chiavi Dream e non menziona alcun limite di iterazioni. Ecco la superficie completa attuale, con il blocco providers su cui si basa trattato nella pagina di configurazione di 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"
      }
    }
  }
}

Si noti cosa non è presente in quel file: un modo per limitare solo Dream. AgentLoop viene costruito una volta con max_iterations dai valori predefiniti del processo, e sia il percorso cron di Dream sia il percorso manuale /dream chiamano process_direct(...) senza alcun argomento di iterazione, così come i subagent. Ridurre il limite lo riduce contemporaneamente per chat, Dream, heartbeat e subagent.

Diagnosticare in quest'ordine

Rispondere a queste quattro domande prima di cambiare qualcosa, perché tre sono gratuite e la quarta indica se le prime tre contano. Le stringhe dei log sono il testo letterale in v0.3.5; le parentesi graffe sono valori runtime.

Non è necessario attendere due ore il tick del cron per riprodurlo. Il comando /dream esegue lo stesso job su richiesta e riporta la stessa distinzione nella chat: Dream completed in Ns. o Dream completed in Ns; no memory changes. in caso di successo, rispetto a Dream did not complete after Ns (reason); memory cursor was not advanced. quando non termina. Un'altra modifica di v0.3.5 è importante mentre si cercano prove: i file JSONL delle sessioni sono stati spostati nell'albero sessions/<workspace-id>/ della directory di configurazione, quindi i percorsi di v0.3.0 citati nel thread dell'issue non sono quelli in cui si trova il checkpoint.

Cinque leve e ciò che ciascuna supporta realmente

I due model ID del segnalatore erano deepseek/deepseek-v4-flash-0731 e openai/gpt-5.6-luna come scritti tramite OpenRouter; qui tali ID e i relativi prezzi non sono stati verificati, quindi il confronto va letto come prova del fatto che il modello determina la convergenza, non come raccomandazione dell'uno o dell'altro. Upstream è giunto alla stessa conclusione: annunciando la chiusura del PR #5782 nell'issue #5781, chengyongru ha scritto che un limite fisso alle iterazioni di Dream non risolve il problema di fondo della convergenza dipendente dal modello e può causare il ritento ripetuto di esecuzioni altrimenti valide.

Quanto costa un'esecuzione limitata: calcolo illustrativo

Si tratta di un calcolo illustrativo dei token, non del costo misurato di un'attività e non di un limite di fatturazione. nanobot non pubblica alcun numero di token per esecuzione di Dream, quindi ogni dato qui è un'ipotesi da sostituire con la propria misurazione. Si supponga un'esecuzione che raggiunge il limite a 201 turni dell'assistente, il conteggio dell'audit del segnalatore, ciascuno dei quali reinvia un prompt mantenuto costante a 25.000 token, la sua caratterizzazione del proprio workspace, non un dato pubblicato. Sono 5,03M token di input. I token di output sono esclusi, e un prompt reale cresce con ogni risultato degli strumenti, quindi questa stima sottovaluta un'esecuzione reale in due direzioni contemporaneamente. Le tariffe sono i prezzi attuali del catalogo Kunavo.

L'ultima colonna presuppone il caso migliore, che qui non è stato verificato: il primo invio alla tariffa normale di input e tutti i reinvii 200 serviti come letture dalla cache. Una scrittura nella cache viene fatturata alla propria tariffa, che per alcuni modelli è superiore alla tariffa normale di input; una voce della cache scade; e un prompt che cresce viene riscritto anziché riletto: quindi la differenza tra le ultime due colonne indica l'entità del vantaggio, non un preventivo. Il punto è solo che, in un'esecuzione lunga e ripetitiva, è il reinvio, non il modello, a determinare la spesa.

La presenza dei marcatori della cache sul filo è determinata dalla configurazione di nanobot ed è visibile nel codice sorgente distribuito. Una chiave provider inventata sotto providers viene trattata come un provider compatibile con OpenAI semplice e lascia supports_prompt_caching al valore predefinito false, quindi il client di nanobot non invia marcatori cache_control su quel percorso nemmeno per un model ID con forma Claude. Mantenere il preset sul provider integrato anthropic e sovrascrivere providers.anthropic.apiBase li mantiene attivi. Questa è un'affermazione su ciò che invia il client di nanobot, non su ciò che fa autonomamente un endpoint, e Kunavo non ha testato nanobot in runtime. Prima di mettere a budget un job ricorrente come memorizzato nella cache, leggere l'usage restituito da una chiamata reale: la documentazione sulla cache mostra l'aspetto di una cache funzionante e il riferimento al base URL fornisce entrambe le convenzioni degli endpoint.

L'importo del catalogo Kunavo è un minimo di fatturazione, non un limite: quando l'upstream comunica il proprio addebito, la fattura è il maggiore tra il costo del catalogo e il costo upstream moltiplicato per il markup applicabile. Il ricarico minimo è $10 di credito prepagato: un minimo di finanziamento, non una tariffa per attività né un abbonamento. Consultare i dettagli di fatturazione e l'ottimizzazione dei costi per il metodo di misurazione che sostituisce le ipotesi precedenti.

Verificare la correzione su un'esecuzione

Cambiare una sola cosa, quindi eseguire una volta /dream invece di attendere la pianificazione e controllare i tre marcatori nell'ordine: nessun avviso Max iterations (200) reached, una riga cursor advanced to … anziché cursor remains at …, e un numero plausibile di chiamate agli strumenti nel mezzo. Poi leggere l'addebito registrato dal proprio account per quella finestra, per chiave e per giorno, in usage; lo store di nanobot conta i token, non il denaro. Se si configura l'endpoint per la prima volta, la guida rapida e la pagina di configurazione di nanobot coprono entrambi i percorsi del protocollo, e la creazione di un account Kunavo è il passaggio precedente al finanziamento di una chiave. Si stanno invece confrontando i runtime? nanobot vs OpenClaw affianca le due cadenze in background, e la directory delle API agent indicizza i client per protocollo wire.

Domande frequenti

Verificato il 21 settembre 2026: l'API GitHub per HKUDS/nanobot, per le issue #5781, #5324 e #3073 e per le pull request #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 e #4622; il record PyPI per nanobot-ai 0.3.5; la documentazione sulla memoria e sulla configurazione di nanobot 0.3.5; e il codice sorgente distribuito al tag v0.3.5 per ogni valore predefinito, stringa di log e percorso del codice citati sopra, confrontato con v0.3.0 dove differiscono. Kunavo non ha installato né eseguito nanobot, nessun comportamento qui descritto è stato testato da Kunavo e il ciclo dell'issue #5781 non è stato nuovamente testato su v0.3.5 da nessuno. Le tariffe dei token provengono dal catalogo attuale e ogni cifra in dollari è un calcolo illustrativo basato sulle ipotesi indicate.