Nanobot の無限ループとトークン使用量：上限に達した Dream 実行を診断する

無限ループに見えるnanobotの実行は有限です。提供されたv0.3.5のソースでは、すべてのエージェントターンにagents.defaults.maxToolIterationsによる上限があり、デフォルトは200です。メンテナーも公に、これは文字どおりの無限ループではないと述べています。本当の問題はトークン使用量です。上限に達する実行ではアシスタントターンが201回記録されるうえ、毎回、増大するプロンプトが再送信されます。あなたの状況を切り分けるには4つの質問があり、証拠のある修正は設定値ではありません。

まず、明らかな手掛かりを除外します。上流の報告はissue #5781で、タイトルはdream.maxIterationsを示しており、PR #5782のタイトルは「fix(dream): enforce configured iteration limit」です。このキーはv0.3.5には存在しません。PRは2026年9月16日に未マージのままクローズされました。これに基づくチュートリアルは何も設定していません。

1点、切り分けが必要です。検索結果は誤ったトラッカーを表示します。このページの対象はHKUDS/nanobot（MIT）で、PyPIパッケージnanobot-aiとしてインストールされます。バージョンは0.3.5、Python 3.11以降、アップロード日は2026年9月15日です。obot-platform/nanobotは別のGoプロジェクトで、READMEにはメンテナンスモードでissueは無効と記載されています。そのissue番号はここでの証拠にはなりません。また、接尾辞のないpip install nanobotは、無関係なロボットナビゲーションパッケージをインストールします。

報告された内容と対象バージョン

Dreamはnanobotのスケジュール実行されるメモリ統合ジョブで、dreamという名前のcronジョブとしてゲートウェイが実行します。これは埋め込みジョブでもベクトルインデックスジョブでもありません。Kunavoは埋め込みモデルを提供しておらず、Dreamにも必要ありません。nanobotの永続メモリはワークスペース内の通常のファイルであり、Dreamの実行は通常のチャットトラフィックだからです。

issue #5781は2026年9月15日、BrianMwangi21によってnanobot v0.3.0に対して登録されました。Python 3.12上で、OpenRouter経由で到達した推論モデルを使用していました。症状は、Dreamジョブがmemory/history.jsonlに対するread_fileと、1つのSKILL.mdに対するread_fileを何十回も交互に実行するというものです。その間、推論トレースは1つの小さな事実をどこに記録するかを再検討していました。約26時間にわたる7回の実行は、およそ25分からおよそ111分でした。ツール呼び出しが200回近くに達した実行はグローバル上限に達しており、セッションチェックポイントには同じread_file呼び出し上でruntime_checkpoint.iteration: 164、フェーズtools_completedと記録されていました。

これらの数字には、3つのスコープ上の制限があります。これは、1人のユーザーが自己申告したゲートウェイログであり、1つのモデル、v0.3.0におけるものです。メンテナーは再現しておらず、v0.3.5で再テストした人もいません。issueのラベルはenhancementとpriority: p2であり、bugではなく、現在もオープンです。また、この形状は以前にも現れています。2026年4月12日のissue #3073は、history.jsonl上のほぼ同一のread_fileループで、not plannedとしてクローズされました。これらはいずれもnanobotが一般的に高コストだという根拠にはなりません。自分のインストール環境がこの状態になっていないか確認する根拠になります。

非推奨キーと、実際に有効な境界

混乱の全体像はバージョンの差であり、ソースが結論を示しています。2026年9月21日に2つのリリースタグを確認した結果は次のとおりです。

この表は2つの理由で間違えやすいものです。200は二重の意味で正しい値です。報告者の設定にある値であり、v0.3.5タグおよびmainにおけるnanobot/config/schema.py行129の提供時デフォルトでもあります。そのため、自分で設定していない読者にも200が適用されます。また、ドキュメント化されていません。2026年9月21日にnanobot自身の0.3.5設定リファレンスを取得したところ、HTMLは488,608バイトで、maxToolIterationsの出現回数は0でした。そのタグにおけるリポジトリのdocs/configuration.mdにもありません。この数値はソースとメンテナーのコメントから証明できますが、ドキュメントページからは証明できません。そのため、異なる数値を引用するチュートリアルには注意してください。

modelOverrideはバージョンによる制限がある唯一の対処法です。v0.3.0ではこのフィールドが実装待ちというコメント付きで存在していましたが、プリセット名を解決するコードはまったくありませんでした。2026年7月27日にマージされたPR #5107が、v0.3.5向けにこれを実装しました。公式の0.3.5メモリページには、Dream用にmodel_presetsから名前付きエントリを選択し、プリセット名のみを受け付け、生のモデル識別子はサポートしないと記載されています。このページにはDreamのキーが3つ記載されており、反復上限についてはどこにも触れていません。ここに現在の完全なインターフェースを示します。依存するprovidersブロックについては、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"
      }
    }
  }
}

そのファイルにないものに注意してください。Dreamだけを制限する方法はありません。AgentLoopはプロセスのデフォルトからmax_iterationsを使って1回だけ構築され、Dreamのcronパスと手動の/dreamパスはいずれも、サブエージェントと同様に反復引数なしでprocess_direct(...)を呼び出します。上限を下げると、チャット、Dream、ハートビート、サブエージェントのすべてで上限が下がります。

この順序で診断してください

変更する前に、次の4点を確認してください。3つは無料で確認でき、4つ目は最初の3つが重要かどうかを判断できます。ログ文字列はv0.3.5のリテラルテキストで、波括弧は実行時の値です。

再現のためにcronのティックを2時間待つ必要はありません。/dreamコマンドを実行すれば、同じジョブをオンデマンドで実行し、チャット内で同じ区別を報告します。成功時はDream completed in Ns.またはDream completed in Ns; no memory changes.、完了しない場合はDream did not complete after Ns (reason); memory cursor was not advanced.です。証拠を探す際に重要なv0.3.5の変更がもう1つあります。セッションJSONLファイルは設定ディレクトリのsessions/<workspace-id>/ツリー配下に移動しました。そのため、課題スレッドに記載されたv0.3.0のパスは、チェックポイントの場所ではありません。

5つの調整項目と、それぞれを実際に裏付ける根拠

報告者がOpenRouter経由で記述した2つのモデルIDはdeepseek/deepseek-v4-flash-0731とopenai/gpt-5.6-lunaでした。これらのIDと価格はここでは確認していないため、比較はモデルが収束を決めるという根拠として読んでください。どちらか一方の推奨ではありません。上流側も同じ結論に達しました。issue #5781でPR #5782の終了を発表した際、chengyongruは、固定されたDream反復上限ではモデル依存の根本的な収束問題に対処できず、本来実行可能な実行が繰り返し再試行される可能性があると記述しました。

上限に達した実行のコスト：説明用の計算

これは測定済みのタスクコストでも請求上限でもなく、説明用のトークン計算です。nanobotはDreamの実行ごとのトークン数を公開していないため、ここで使う値はすべて仮定であり、自分の測定値に置き換える必要があります。報告者の監査で数えられた、上限に達する1回の実行を想定します。これは201回のアシスタントターンで、各ターンが25,000トークンで一定のプロンプトを再送するとします。これは公開値ではなく、報告者自身のワークスペースについての説明です。入力トークンは5.03Mです。出力トークンは含めていません。また、実際のプロンプトは各ツール結果によって大きくなるため、この計算は実際の実行を2つの方向で同時に過小評価します。料金は現在のKunavoカタログ価格です。

最後の列は、ここではテストしていない最良ケースを仮定しています。最初の送信は通常の入力料金で、200回の再送はすべてキャッシュ読み取りとして処理されるケースです。キャッシュ書き込みには独自の料金がかかり、一部のモデルでは通常の入力料金より高く設定されています。キャッシュエントリには有効期限があり、増大するプロンプトは再読み取りではなく再書き込みになります。そのため、最後の2列の差は見込める節約幅として扱い、見積書として扱わないでください。要点は、長く反復的な実行では、費用の大部分をモデルではなく再送が占めるということだけです。

キャッシュマーカーが実際に送信されるかどうかは、nanobotの設定で決まり、同梱ソースで確認できます。providers配下の、作成したプロバイダキーは通常のOpenAI互換プロバイダとして扱われ、supports_prompt_cachingはデフォルトのfalseのままになります。そのため、Claude形式のモデルIDであっても、そのパスではnanobotのクライアントはcache_controlマーカーを送信しません。組み込みのanthropicプロバイダ上でプリセットを維持し、providers.anthropic.apiBaseを上書きすれば、マーカーは維持されます。これはnanobotのクライアントが送信する内容についての説明であり、各エンドポイントが自身の側で行う処理についてではありません。また、Kunavoはnanobotを実行時テストしていません。定期ジョブをキャッシュ済みとして予算化する前に、実際の1回の呼び出しで返された使用量を確認してください。キャッシュに関するドキュメントには機能するキャッシュの状態が、ベースURLリファレンスには2つのエンドポイント方式が示されています。

Kunavoのカタログ金額は上限ではなく請求下限です。上流側が料金を報告すると、請求額はカタログ料金と、該当するマークアップを乗じた上流料金のうち高い方になります。最低トップアップ額は$10の前払いクレジットです。これは資金補充の最低額であり、タスク料金でもサブスクリプション料金でもありません。請求の詳細と、上記の仮定を置き換える測定方法についてはコスト最適化を参照してください。

1回の実行で修正を検証する

1つだけ変更してから、スケジュールを待たずに/dreamを1回実行し、3つのマーカーを順番に確認します。Max iterations (200) reached警告がないこと、cursor remains at …ではなくcursor advanced to …行が出ること、その間のツール呼び出し数が妥当であることです。次に、その時間帯について自分のアカウントに記録された請求額を、使用状況でキー別・日別に確認します。nanobotのストアが数えるのはトークンであり、金額ではありません。エンドポイントを初めて設定する場合は、クイックスタートとnanobotセットアップページで両方のプロトコル方式を説明しています。キーへの入金前に行う手順はKunavoアカウントの作成です。実行環境を比較する場合は、nanobotとOpenClawの比較で2つのバックグラウンド周期を並べて確認でき、エージェントAPIディレクトリではクライアントを通信プロトコル別に検索できます。

よくある質問

2026年9月21日確認：HKUDS/nanobotのGitHub API、issue #5781、#5324、#3073、pull request #5782、#5107、#5325、#5442、#5407、#3077、#4522、#5344、#3701、#4154、#3735、#3921、#4622、nanobot-ai 0.3.5のPyPIレコード、nanobot 0.3.5のメモリおよび設定ドキュメント、ならびにv0.3.5タグの同梱ソースにある、上記で引用したすべてのデフォルト値、ログ文字列、コードパスを確認し、2つが異なる箇所についてはv0.3.0と比較しました。Kunavoはnanobotをインストールも実行もしておらず、ここで述べる挙動はKunavoによるテスト済みではありません。また、issue #5781のループは、誰によってもv0.3.5で再テストされていません。トークン料金は現在のカタログから取得し、すべてのドル金額は記載した仮定に基づく説明用の計算です。