Loops infinitos e uso de tokens no Nanobot: diagnostique uma execução Dream limitada

Uma execução do nanobot que parece um loop infinito é limitada: no código-fonte distribuído da v0.3.5, cada turno do agente é limitado por agents.defaults.maxToolIterations, cujo padrão é 200, e um mantenedor afirma oficialmente que não se trata de um loop literalmente infinito. O verdadeiro problema é o uso de tokens, porque uma execução que chega a esse limite registra 201 turnos do assistente e reenvia um prompt cada vez maior. Distinguir qual desses casos você tem exige quatro perguntas, e a correção respaldada por evidências não é um valor de configuração.

Comece eliminando a pista óbvia. O relatório upstream é a issue #5781, cujo título aponta para dream.maxIterations, e o PR #5782 tem o título "fix(dream): enforce configured iteration limit". Essa chave não existe na v0.3.5, e o PR foi encerrado sem incorporação em 16 de setembro de 2026. Um tutorial baseado nele não configura nada.

Uma distinção, porque a consulta mostra o rastreador errado. Esta página trata de HKUDS/nanobot, MIT, instalado como o pacote PyPI nanobot-ai — 0.3.5, Python 3.11 ou posterior, enviado em 15 de setembro de 2026. obot-platform/nanobot é um projeto Go diferente, cujo README declara modo de manutenção com issues desativadas; seus números de issue não são evidências aqui. E pip install nanobot, sem sufixo, instala um pacote não relacionado de navegação de robôs.

O que foi relatado e contra qual versão

Dream é o job agendado de consolidação de memória do nanobot, executado pelo gateway como um job cron chamado dream. Ele não é um job de embeddings nem de índice vetorial: a Kunavo não fornece um modelo de embeddings, e o Dream não precisa de um, porque a memória persistente do nanobot consiste em arquivos simples no workspace e uma execução do Dream é tráfego comum de chat.

A issue #5781 foi aberta em 15 de setembro de 2026 por BrianMwangi21 contra o nanobot v0.3.0, em Python 3.12, com um modelo de raciocínio acessado pelo OpenRouter. O sintoma: o job Dream alternava read_file em memory/history.jsonl com read_file em um único SKILL.md, dezenas de vezes, enquanto o rastreamento de raciocínio reconsiderava onde registrar um único fato pequeno. Sete execuções registradas ao longo de aproximadamente 26 horas variaram de cerca de 25 minutos a cerca de 111 minutos; as que se aproximaram de 200 chamadas de ferramentas atingiram o limite global, e um checkpoint da sessão mostrava runtime_checkpoint.iteration: 164, fase tools_completed, na mesma chamada read_file.

Três limites de escopo devem acompanhar esses números. Eles são logs do gateway autorrelatados por um usuário, em um modelo, na v0.3.0 — nenhum mantenedor os reproduziu e ninguém refez o teste na v0.3.5. A issue está marcada como enhancement e priority: p2, não como bug, e continua aberta. E esse padrão já apareceu antes: a issue #3073, um loop quase idêntico de read_file em history.jsonl de 12 de abril de 2026, foi encerrada como não planejada. Nada disso sustenta tratar o nanobot como geralmente caro; sustenta verificar se a sua própria instalação está fazendo isso.

A chave obsoleta e o limite que está realmente ativo

Toda a confusão é uma diferença de versão, e o código-fonte resolve a questão. Leia as duas tags de lançamento em 21 de setembro de 2026:

Duas coisas tornam essa tabela fácil de interpretar errado. O 200 é duplamente verdadeiro — é o valor na configuração do autor e o padrão distribuído na linha 129 de nanobot/config/schema.py, idêntico na tag v0.3.5 e em main, portanto um leitor que nunca o definiu ainda tem 200. E ele não é documentado: uma consulta à própria referência de configuração 0.3.5 do nanobot em 21 de setembro de 2026 retornou 488.608 bytes de HTML com zero ocorrências de maxToolIterations, e o docs/configuration.md do repositório nessa tag também não contém nenhuma. O número pode ser comprovado pelo código-fonte e por um comentário de mantenedor, não por uma página de documentação — portanto, trate com desconfiança qualquer tutorial que cite um valor diferente.

modelOverride é o único recurso com uma condição de versão. Na v0.3.0, o campo existia com o comentário pendente de implementação e sem nenhum código que o resolvesse; o PR #5107, incorporado em 27 de julho de 2026, o implementou na v0.3.5. A página oficial de memória da 0.3.5 afirma que ele seleciona uma entrada nomeada de model_presets para o Dream, aceita somente nomes de presets e não oferece suporte a identificadores brutos de modelos. Essa página documenta três chaves do Dream e não menciona nenhum limite de iterações. Eis a superfície completa atual, com o bloco providers em que ela se apoia coberto na página de configuração do 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"
      }
    }
  }
}

Observe o que não está nesse arquivo: qualquer forma de limitar apenas o Dream. AgentLoop é construído uma vez com max_iterations a partir dos padrões do processo, e tanto o caminho cron do Dream quanto o caminho manual /dream chamam process_direct(...) sem um argumento de iteração, assim como os subagentes. Reduzir o limite o reduz para chat, Dream, heartbeat e subagentes em conjunto.

Diagnostique nesta ordem

Responda a estas quatro perguntas antes de alterar qualquer coisa, porque três não custam nada e a quarta informa se as três primeiras importam. As strings dos logs são o texto literal na v0.3.5; as chaves representam valores de runtime.

Você não precisa esperar duas horas pelo tick do cron para reproduzi-lo. O comando /dream executa o mesmo job sob demanda e informa a mesma distinção no chat: Dream completed in Ns. ou Dream completed in Ns; no memory changes. em caso de sucesso, contra Dream did not complete after Ns (reason); memory cursor was not advanced. quando não termina. Outra mudança da v0.3.5 importa enquanto você procura evidências: os arquivos JSONL de sessão foram movidos para a árvore sessions/<workspace-id>/ do diretório de configuração, portanto os caminhos da v0.3.0 citados na thread da issue não são onde seu checkpoint está.

Cinco recursos e o que realmente respalda cada um

Os dois IDs de modelo do autor eram deepseek/deepseek-v4-flash-0731 e openai/gpt-5.6-luna, conforme ele os escreveu via OpenRouter; esses IDs e seus preços não foram verificados aqui, portanto interprete a comparação como evidência de que o modelo decide a convergência, não como recomendação de nenhum dos dois. O upstream chegou à mesma conclusão: ao anunciar o encerramento do PR #5782 na issue #5781, chengyongru escreveu que um limite fixo de iterações do Dream não aborda o problema subjacente de convergência dependente do modelo e pode fazer com que execuções que poderiam funcionar sejam repetidamente tentadas de novo.

Quanto custa uma execução limitada: cálculo ilustrativo

Estas são contas ilustrativas de tokens, não o custo medido de uma tarefa nem um limite de cobrança. O nanobot não publica um valor de tokens por execução do Dream, portanto toda entrada aqui é uma suposição que você deve substituir pela sua própria medição. Suponha uma execução que atinge o limite em 201 turnos do assistente — a contagem da auditoria do autor — cada um reenviando um prompt mantido constante em 25,000 tokens, caracterização que ele fez do próprio workspace, não um valor publicado. Isso representa 5.03M tokens de entrada. Os tokens de saída são excluídos, e um prompt real cresce a cada resultado de ferramenta, portanto isso subestima uma execução real em duas direções simultaneamente. As tarifas são os preços atuais do catálogo da Kunavo.

A última coluna pressupõe um caso ideal que nada aqui testou: o primeiro envio à tarifa de entrada simples e todos os 200 reenvios atendidos como leituras de cache. Uma gravação de cache é cobrada pela própria tarifa, que em alguns modelos fica acima da tarifa de entrada simples; uma entrada de cache expira; e um prompt que cresce é regravado, não relido — portanto, trate a diferença entre as duas últimas colunas como o tamanho do benefício, não como uma cotação. O ponto é apenas que, em uma execução longa e repetitiva, é o reenvio, não o modelo, que consome o dinheiro.

A decisão sobre se os marcadores de cache chegam efetivamente à rede ocorre na configuração do seu nanobot, e é visível no código-fonte distribuído. Um provedor inventado em providers é tratado como um provedor compatível com OpenAI simples e deixa supports_prompt_caching com seu padrão false, portanto o cliente do nanobot não envia marcadores cache_control nesse caminho, mesmo para um ID de modelo no formato Claude. Manter o preset no provedor integrado anthropic e substituir providers.anthropic.apiBase os mantém ativos. Isso descreve o que o cliente do nanobot envia, não o que qualquer endpoint faz do próprio lado, e a Kunavo não testou o nanobot em runtime. Leia o uso retornado de uma chamada real antes de orçar um job recorrente como armazenado em cache — a documentação de cache mostra como é um cache funcionando e a referência da URL base fornece as duas convenções de endpoint.

O valor do catálogo da Kunavo é um piso de cobrança, não um teto: quando o upstream informa seu custo, a cobrança é o maior entre o custo do catálogo e o custo do upstream multiplicado pela margem aplicável. O recarregamento mínimo é $10 em crédito pré-pago — um mínimo de financiamento, não uma taxa por tarefa nem uma assinatura. Consulte detalhes de cobrança e otimização de custos para conhecer o método de medição que substitui as suposições acima.

Verifique a correção em uma execução

Altere uma coisa, execute /dream uma vez em vez de esperar pelo agendamento e verifique os três marcadores na ordem: nenhum aviso Max iterations (200) reached, uma linha cursor advanced to … em vez de cursor remains at …, e uma quantidade plausível de chamadas de ferramentas entre eles. Depois leia a cobrança registrada pela sua própria conta nessa janela, por chave e por dia, em usage; o armazenamento do nanobot conta tokens, não dinheiro. Se você estiver configurando o endpoint pela primeira vez, o quickstart e a página de configuração do nanobot cobrem os dois caminhos de protocolo, e criar uma conta Kunavo é a etapa anterior ao financiamento de uma chave. Comparando tempos de execução? nanobot vs OpenClaw coloca as duas cadências em segundo plano lado a lado, e o diretório de APIs de agentes indexa os clientes por protocolo de rede.

Perguntas frequentes

Verificado em 21 de setembro de 2026: a API do GitHub para HKUDS/nanobot e para as issues #5781, #5324 e #3073 e os pull requests #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 e #4622; o registro PyPI do nanobot-ai 0.3.5; a documentação de memória e configuração 0.3.5 do nanobot; e o código-fonte distribuído na tag v0.3.5 para cada padrão, string de log e caminho de código citado acima, comparado com a v0.3.0 onde diferem. A Kunavo não instalou nem executou o nanobot, nenhum comportamento aqui foi testado pela Kunavo e o loop da issue #5781 não foi testado novamente na v0.3.5 por ninguém. As tarifas de tokens vêm do catálogo atual e todos os valores em dólares são cálculos ilustrativos segundo as suposições declaradas.