Nanobot-Endlosschleifen und Tokenverbrauch: Einen begrenzten Dream-Lauf diagnostizieren

Ein nanobot-Lauf, der wie eine Endlosschleife aussieht, ist begrenzt: Im ausgelieferten Quellcode von v0.3.5 ist jeder Agent-Turn durch agents.defaults.maxToolIterations auf standardmäßig 200 begrenzt, und ein Maintainer erklärt öffentlich, dass es sich nicht um eine buchstäblich unendliche Schleife handelt. Das eigentliche Problem ist der Tokenverbrauch, weil ein Lauf, der diese Obergrenze erreicht, 201 Assistant-Turns protokolliert und bei jedem Turn einen wachsenden Prompt erneut sendet. Zu klären, welche dieser Situationen vorliegt, ist eine Diagnose mit vier Fragen; die nachweislich belegte Lösung ist kein Konfigurationswert.

Entfernen Sie zunächst den naheliegenden Hauptverdächtigen. Der Upstream-Bericht ist Issue #5781, dessen Titel auf dream.maxIterations verweist, und PR #5782 trägt den Titel „fix(dream): enforce configured iteration limit“. Dieser Schlüssel existiert in v0.3.5 nicht, und der PR wurde am 16. September 2026 ohne Merge geschlossen. Ein darauf basierendes Tutorial konfiguriert nichts.

Eine Abgrenzung, weil die Suchabfrage den falschen Tracker hervorbringt. Diese Seite handelt von HKUDS/nanobot, MIT, installiert als PyPI-Paket nanobot-ai – 0.3.5, Python 3.11 oder neuer, hochgeladen am 15. September 2026. obot-platform/nanobot ist ein anderes Go-Projekt, dessen README den Wartungsmodus mit deaktivierten Issues erklärt; seine Issue-Nummern sind hier kein Beleg. Und pip install nanobot, ohne Suffix, installiert ein nicht verwandtes Paket für Roboternavigation.

Was gemeldet wurde und gegen welche Version

Dream ist nanobots geplanter Job zur Speicherkonsolidierung, der vom Gateway als Cron-Job mit dem Namen dream ausgeführt wird. Es handelt sich nicht um einen Embedding- oder Vektorindex-Job: Kunavo stellt kein Embedding-Modell bereit, und Dream benötigt auch keines, da nanobots dauerhafter Speicher aus einfachen Dateien im Arbeitsbereich besteht und ein Dream-Lauf gewöhnlicher Chatverkehr ist.

Issue #5781 wurde am 15. September 2026 von BrianMwangi21 gegen nanobot v0.3.0 eingereicht, unter Python 3.12 mit einem über OpenRouter erreichten Reasoning-Modell. Das Symptom: Der Dream-Job wechselte Dutzende Male zwischen read_file bei memory/history.jsonl und read_file bei einem SKILL.md, während der Reasoning-Trace erneut darüber beriet, wo eine einzelne kleine Information abgelegt werden sollte. Sieben Läufe über etwa 26 Stunden dauerten ungefähr 25 bis ungefähr 111 Minuten; die Läufe nahe 200 Tool-Aufrufen stießen an das globale Limit, und ein Sitzungs-Checkpoint zeigte runtime_checkpoint.iteration: 164, Phase tools_completed, beim selben Aufruf read_file.

Drei Einschränkungen des Geltungsbereichs gehören zu diesen Zahlen. Es handelt sich um die selbst gemeldeten Gateway-Logs eines Benutzers, mit einem Modell und unter v0.3.0 — kein Maintainer hat sie reproduziert, und niemand hat sie unter v0.3.5 erneut getestet. Das Issue ist mit enhancement und priority: p2 gekennzeichnet, nicht mit bug, und weiterhin offen. Dieses Muster ist außerdem schon zuvor aufgetreten: Issue #3073, eine nahezu identische read_file-Schleife bei history.jsonl vom 12. April 2026, wurde als nicht geplant geschlossen. Nichts davon rechtfertigt die Annahme, nanobot sei generell teuer; es spricht dafür zu prüfen, ob die eigene Installation dieses Verhalten zeigt.

Der veraltete Schlüssel und die tatsächlich aktive Grenze

Die gesamte Verwirrung ist eine Versionslücke, und die Quelle klärt sie. Gelesen an den beiden Release-Tags am 21. September 2026:

Zwei Dinge führen leicht dazu, diese Tabelle falsch zu verstehen. Die 200 stimmt in zweierlei Hinsicht — sie ist der Wert in der Konfiguration des Meldenden und der ausgelieferte Standardwert in Zeile 129 von nanobot/config/schema.py, identisch am v0.3.5-Tag und auf main, sodass auch ein Leser, der ihn nie gesetzt hat, 200 verwendet. Außerdem ist sie undokumentiert: Ein Abruf von nanobots eigener Konfigurationsreferenz 0.3.5 am 21. September 2026 lieferte 488.608 Bytes HTML mit null Vorkommen von maxToolIterations, und auch die Datei docs/configuration.md im Repository enthält an diesem Versions-Tag keine Vorkommen. Die Zahl lässt sich aus dem Quellcode und einem Maintainer-Kommentar belegen, nicht aus einer Dokumentationsseite — behandeln Sie daher jedes Tutorial, das eine andere Zahl nennt, mit Skepsis.

modelOverride ist das einzige Heilmittel mit einer Versionsvoraussetzung. In v0.3.0 existierte das Feld mit dem Kommentar Implementierung ausstehend, aber ohne jeglichen auflösenden Code; PR #5107, am 27. Juli 2026 zusammengeführt, implementierte es für v0.3.5. Die offizielle Speicherseite zu 0.3.5 besagt, dass damit ein benannter Eintrag aus model_presets für Dream ausgewählt wird, nur Preset-Namen akzeptiert werden und rohe Modellkennungen nicht unterstützt werden. Diese Seite dokumentiert drei Dream-Schlüssel und erwähnt nirgendwo ein Iterationslimit. Hier ist die vollständige aktuelle Oberfläche, einschließlich des providers-Blocks, auf den sie sich stützt, abgedeckt auf der nanobot-Einrichtungsseite:

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

Beachten Sie, was in dieser Datei nicht enthalten ist: eine Möglichkeit, nur Dream zu begrenzen. AgentLoop wird einmal mit max_iterations aus den Prozessstandards erstellt, und sowohl der Dream-Cron-Pfad als auch der manuelle /dream-Pfad rufen process_direct(...) ohne Iterationsargument auf, ebenso wie Subagenten. Das Senken des Limits senkt es gleichzeitig für Chat, Dream, Heartbeat und Subagenten.

In dieser Reihenfolge diagnostizieren

Beantworten Sie diese vier Fragen, bevor Sie etwas ändern, denn drei davon kosten nichts und die vierte zeigt, ob die ersten drei überhaupt relevant sind. Die Log-Zeichenketten sind der wörtliche Text in v0.3.5; die geschweiften Klammern enthalten Laufzeitwerte.

Sie müssen nicht zwei Stunden auf den Cron-Tick warten, um das Problem zu reproduzieren. Der Befehl /dream führt denselben Job auf Abruf aus und meldet im Chat dieselbe Unterscheidung: Dream completed in Ns. oder Dream completed in Ns; no memory changes. bei Erfolg, gegenüber Dream did not complete after Ns (reason); memory cursor was not advanced., wenn er nicht fertig wird. Eine weitere Änderung in v0.3.5 ist bei der Suche nach Belegen wichtig: Sitzungs-JSONL-Dateien wurden in den sessions/<workspace-id>/-Baum des Konfigurationsverzeichnisses verschoben, daher befinden sich die im Issue-Thread genannten Pfade aus v0.3.0 nicht dort, wo Ihr Checkpoint liegt.

Fünf Stellschrauben und was jeweils tatsächlich belegt ist

Die beiden Modell-IDs des Meldenden waren deepseek/deepseek-v4-flash-0731 und openai/gpt-5.6-luna, wie er sie über OpenRouter angegeben hat; diese IDs und ihre Preise wurden hier nicht geprüft. Lesen Sie den Vergleich daher als Beleg dafür, dass das Modell die Konvergenz bestimmt, nicht als Empfehlung für eines der beiden. Upstream kam zum selben Schluss: Bei der Ankündigung des Abschlusses von PR #5782 zu Issue #5781 schrieb chengyongru, dass ein festes Dream-Iterationslimit das zugrunde liegende, modellabhängige Konvergenzproblem nicht behebt und dazu führen kann, dass ansonsten brauchbare Läufe wiederholt werden.

Was ein begrenzter Lauf kostet: beispielhafte Berechnung

Dies ist eine beispielhafte Tokenberechnung, keine gemessenen Aufgabenkosten und keine Abrechnungsobergrenze. nanobot veröffentlicht keine Tokenzahl pro Dream-Lauf, daher ist jede Eingabe hier eine Annahme, die Sie durch Ihre eigene Messung ersetzen sollten. Nehmen wir einen Lauf an, der das Limit bei 201 Assistant-Zügen erreicht — der Anzahl im Audit des Meldenden — wobei jeder einen konstant gehaltenen Prompt mit 25.000 Tokens erneut sendet, seiner Beschreibung seines eigenen Arbeitsbereichs, nicht einer veröffentlichten Zahl. Das sind 5,03M Eingabetokens. Ausgabetokens sind ausgeschlossen, und ein realer Prompt wächst mit jedem Tool-Ergebnis, daher unterschätzt dies einen realen Lauf in zweierlei Hinsicht gleichzeitig. Die Tarife sind aktuelle Preise aus dem Kunavo-Katalog.

Die letzte Spalte setzt einen Best Case voraus, den hier nichts getestet hat: die erste Sendung zum normalen Eingabetarif und alle 200 erneuten Sendungen als Cache-Lesevorgänge. Ein Cache-Schreibvorgang wird zu seinem eigenen Tarif abgerechnet, der bei manchen Modellen über dem normalen Eingabetarif liegt; ein Cache-Eintrag läuft ab; und ein wachsender Prompt wird neu geschrieben statt erneut gelesen — betrachten Sie daher die Differenz zwischen den letzten beiden Spalten als Größe des möglichen Vorteils, nicht als Angebot. Der einzige Punkt ist, dass bei einem langen, repetitiven Lauf die erneute Sendung — nicht das Modell — das Geld kostet.

Ob Cache-Markierungen überhaupt über die Leitung gesendet werden, wird in Ihrer nanobot-Konfiguration entschieden und ist im ausgelieferten Quellcode sichtbar. Ein erfundener Provider-Schlüssel unter providers wird als einfacher OpenAI-kompatibler Provider behandelt und lässt supports_prompt_caching auf dem Standardwert false, sodass nanobots Client auf diesem Pfad keine cache_control-Markierungen sendet, selbst bei einer Claude-ähnlichen Modell-ID. Wenn das Preset beim integrierten Provider anthropic bleibt und providers.anthropic.apiBase überschrieben wird, bleiben sie erhalten. Das beschreibt, was nanobots Client sendet, nicht was ein beliebiger Endpunkt auf seiner Seite tut, und Kunavo hat nanobot nicht zur Laufzeit getestet. Lesen Sie die zurückgegebene Nutzung eines echten Aufrufs, bevor Sie einen wiederkehrenden Job als gecacht budgetieren — die Caching-Dokumentation zeigt, wie ein funktionierender Cache aussieht, und die Referenz zur Basis-URL nennt beide Endpunktkonventionen.

Der Betrag aus Kunavos Katalog ist eine Abrechnungsuntergrenze, keine Obergrenze: Wenn der Upstream seine Kosten meldet, ist die Rechnung der größere Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem jeweils geltenden Aufschlag. Die minimale Aufladung beträgt $10 als Prepaid-Guthaben — eine Mindestfinanzierung, keine Aufgaben- oder Abonnementgebühr. Siehe Abrechnungsdetails und Kostenoptimierung für die Messmethode, die die obigen Annahmen ersetzt.

Die Korrektur in einem Lauf überprüfen

Ändern Sie eine Sache, führen Sie dann einmal /dream aus, statt auf den Zeitplan zu warten, und prüfen Sie die drei Markierungen der Reihe nach: keine Max iterations (200) reached-Warnung, eine cursor advanced to …-Zeile statt cursor remains at …, und dazwischen eine plausible Anzahl von Tool-Aufrufen. Lesen Sie anschließend die von Ihrem eigenen Konto für dieses Zeitfenster erfassten Kosten nach Schlüssel und Tag in Nutzung; nanobots Speicher zählt Tokens, kein Geld. Wenn Sie den Endpunkt zum ersten Mal konfigurieren, behandeln der Schnellstart und die nanobot-Einrichtungsseite beide Protokollpfade, und ein Kunavo-Konto zu erstellen ist der Schritt vor der Finanzierung eines Schlüssels. Vergleichen Sie stattdessen Laufzeiten? nanobot vs. OpenClaw stellt die beiden Hintergrundintervalle gegenüber, und das Verzeichnis der Agent-APIs ordnet Clients nach Drahtprotokoll.

Häufig gestellte Fragen

Geprüft am 21. September 2026: die GitHub-API für HKUDS/nanobot sowie für die Issues #5781, #5324 und #3073 und die Pull Requests #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 und #4622; der PyPI-Eintrag für nanobot-ai 0.3.5; nanobots Speicher- und Konfigurationsdokumentation zu 0.3.5; sowie der ausgelieferte Quellcode am v0.3.5-Tag für jeden oben zitierten Standardwert, Log-Text und Codepfad, verglichen mit v0.3.0, wo sie sich unterscheiden. Kunavo hat nanobot weder installiert noch ausgeführt, kein Verhalten hier wurde von Kunavo getestet, und die Schleife aus Issue #5781 wurde von niemandem unter v0.3.5 erneut getestet. Token-Tarife stammen aus dem aktuellen Katalog, und jede Dollarzahl ist eine beispielhafte Berechnung unter den angegebenen Annahmen.