Nanobot infinite loops and token usage: diagnose a capped Dream run

A nanobot run that looks like an infinite loop is a bounded one: in the shipped v0.3.5 source every agent turn is capped by agents.defaults.maxToolIterations, whose default is 200, and a maintainer states on the record that this is not a literally infinite loop. The token usage is the real problem, because a run that reaches that ceiling logs 201 assistant turns and resends a growing prompt each time. Sorting out which of those you have is a four-question diagnosis, and the fix that has evidence behind it is not a configuration value.

Start by deleting the obvious lead. The upstream report is issue #5781, whose title points at dream.maxIterations, and PR #5782 is titled "fix(dream): enforce configured iteration limit". That key does not exist in v0.3.5, and the PR was closed unmerged on September 16, 2026. A tutorial built on it configures nothing.

One disambiguation, because the query surfaces the wrong tracker. This page is about HKUDS/nanobot, MIT, installed as the PyPI package nanobot-ai — 0.3.5, Python 3.11 or newer, uploaded September 15, 2026. obot-platform/nanobot is a different Go project whose README declares maintenance mode with issues disabled; its issue numbers are not evidence here. And pip install nanobot, with no suffix, installs an unrelated robot navigation package.

What was reported, and against which version

Dream is nanobot's scheduled memory-consolidation job, run by the gateway as a cron job named dream. It is not an embedding or vector-index job: Kunavo serves no embedding model, and Dream does not need one, because nanobot's durable memory is plain files under the workspace and a Dream run is ordinary chat traffic.

Issue #5781 was filed on September 15, 2026 by BrianMwangi21 against nanobot v0.3.0, on Python 3.12 with a reasoning model reached through OpenRouter. The symptom: the Dream job alternating read_file on memory/history.jsonl with read_file on one SKILL.md, dozens of times, while the reasoning trace re-deliberated where to file a single small fact. Seven runs logged over about 26 hours ranged from roughly 25 minutes to roughly 111 minutes; the ones near 200 tool calls were hitting the global cap, and a session checkpoint showed runtime_checkpoint.iteration: 164, phase tools_completed, on the same read_file call.

Three scope limits belong with those numbers. They are one user's self-reported gateway logs, on one model, on v0.3.0 — no maintainer reproduced them, and nobody has re-tested on v0.3.5. The issue is labelled enhancement and priority: p2, not bug, and it is still open. And this shape has surfaced before: issue #3073, a near-identical read_file loop on history.jsonl from April 12, 2026, was closed not planned. None of that supports treating nanobot as generally expensive; it supports checking whether your own install is doing this.

The deprecated key, and the boundary that is actually live

The whole confusion is a version gap, and the source settles it. Read at the two release tags on September 21, 2026:

Two things make that table easy to get wrong. The 200 is doubly true — it is the value in the reporter's config and the shipped default at nanobot/config/schema.py line 129, identical at the v0.3.5 tag and on main, so a reader who never set it still has 200. And it is undocumented: a fetch of nanobot's own 0.3.5 configuration reference on September 21, 2026 returned 488,608 bytes of HTML with zero occurrences of maxToolIterations, and the repository's docs/configuration.md at that tag has none either. The number is provable from source and from a maintainer comment, not from a documentation page — so treat any tutorial quoting a different figure with suspicion.

modelOverride is the one remedy with a version gate. In v0.3.0 the field existed with the comment pending implementation and no resolving code at all; PR #5107, merged July 27, 2026, implemented it for v0.3.5. The official 0.3.5 memory page states that it selects a named entry from model_presets for Dream, accepts preset names only, and that raw model identifiers are not supported. That page documents three Dream keys and mentions no iteration limit anywhere. Here is the complete current surface, with the providers block it leans on covered on the nanobot setup page:

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

Note what is not in that file: any way to bound Dream alone. AgentLoop is constructed once with max_iterations from the process defaults, and both the Dream cron path and the manual /dream path call process_direct(...) with no iteration argument, as do subagents. Lowering the cap lowers it for chat, Dream, heartbeat and subagents together.

Diagnose in this order

Answer these four before changing anything, because three of them are free and the fourth tells you whether the first three matter. The log strings are the literal text in v0.3.5; the braces are runtime values.

You do not have to wait two hours for the cron tick to reproduce it. The /dream command runs the same job on demand and reports the same distinction in chat: Dream completed in Ns. or Dream completed in Ns; no memory changes. on success, against Dream did not complete after Ns (reason); memory cursor was not advanced. when it does not finish. One other v0.3.5 change matters while you are hunting for evidence: session JSONL files moved under the configuration directory's sessions/<workspace-id>/ tree, so the v0.3.0 paths quoted in the issue thread are not where your checkpoint lives.

Five levers, and what each one is actually backed by

The reporter's two model ids were deepseek/deepseek-v4-flash-0731 and openai/gpt-5.6-luna as he wrote them via OpenRouter; those ids and their prices were not checked here, so read the comparison as evidence that the model decides convergence, not as a recommendation of either one. Upstream reached the same conclusion: announcing the closure of PR #5782 on issue #5781, chengyongru wrote that a fixed Dream iteration cap does not address the underlying model-dependent convergence problem and may cause otherwise viable runs to be retried repeatedly.

What a capped run costs: illustrative arithmetic

These are illustrative token arithmetic, not a measured task cost and not a bill ceiling. nanobot publishes no per-run token figure for Dream, so every input here is an assumption you should replace with your own measurement. Assume one run that reaches the cap at 201 assistant turns — the count in the reporter's audit — each resending a prompt held flat at 25,000 tokens, which is his characterisation of his own workspace, not a published figure. That is 5.03M input tokens. Output tokens are excluded, and a real prompt grows with each tool result, so this understates a real run in two directions at once. Rates are live Kunavo catalog prices.

The last column assumes a best case that nothing here tested: the first send at the plain input rate and all 200 resends served as cache reads. A cache write is billed at its own rate, which on some models sits above the plain input rate; a cache entry expires; and a prompt that grows re-writes rather than re-reads — so treat the gap between the last two columns as the size of the prize, not as a quote. The point is only that on a long repetitive run the resend, not the model, is where the money goes.

Whether cache markers reach the wire at all is decided in your nanobot config, and it is visible in the shipped source. An invented provider key under providers is treated as a plain OpenAI-compatible provider and leaves supports_prompt_caching at its default of false, so nanobot's client sends no cache_control markers on that path even for a Claude-shaped model id. Keeping the preset on the built-in anthropic provider and overriding providers.anthropic.apiBase keeps them on. That is a statement about what nanobot's client sends, not about what any endpoint does on its own side, and Kunavo has not runtime-tested nanobot. Read one real call's returned usage before budgeting a recurring job as cached — the caching doc shows what a working cache looks like and the base URL reference gives both endpoint conventions.

Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. The minimum top-up is $10 in prepaid credit — a funding minimum, not a task fee or a subscription. See billing details, and cost optimization for the measurement method that replaces the assumptions above.

Verify the fix on one run

Change one thing, then run /dream once rather than waiting for the schedule, and check the three markers in order: no Max iterations (200) reached warning, a cursor advanced to … line rather than cursor remains at …, and a plausible tool-call count in between. Then read the charge your own account recorded for that window, per key and per day, in usage; nanobot's store counts tokens, not money. If you are configuring the endpoint for the first time, the quickstart and the nanobot setup page cover both protocol paths, and creating a Kunavo account is the step before funding a key. Comparing runtimes instead? nanobot vs OpenClaw puts the two background cadences side by side, and the agent API directory indexes clients by wire protocol.

FAQ

Checked September 21, 2026: the GitHub API for HKUDS/nanobot and for issues #5781, #5324 and #3073 and pull requests #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 and #4622; the PyPI record for nanobot-ai 0.3.5; nanobot's 0.3.5 memory and configuration documentation; and the shipped source at the v0.3.5 tag for every default, log string and code path quoted above, compared against v0.3.0 where the two differ. Kunavo has not installed or run nanobot, no behaviour here is Kunavo-tested, and the loop of issue #5781 has not been re-tested on v0.3.5 by anyone. Token rates come from the live catalog and every dollar figure is illustrative arithmetic at the stated assumptions.