アイドルエージェントが1日5000万トークンを消費した理由と改善方法

Reddit上のOpenClawユーザーが、LLM API使用量が6日間で1100万から5100万トークンに急増し、合計1億9600万トークンに達したと報告。そのほとんどがアイドル状態のエージェントによって無駄に消費されていた。原因は、OpenClawのハートビート機能が30分ごとに、忘れ去られた「main」というエージェントを呼び出し、22万5千トークンのセッション履歴を読み込んで「HEARTBEAT_OK」と返答していたことだった。
リークの兆候:cacheReadの支配
トランスクリプト分析から、2つの数字が浮かび上がった:
- トークンの95%がcacheRead — モデルが新しい作業をする代わりに、古い会話履歴を再読み込みしていた。
- 全トークンの56%が、もはや使用されていない「main」という単一のエージェントによるものだった。
ハートビートは1日48回実行され、そのたびに数ヶ月前のセッションを読み込んでいた。ハートビートを無効にするために意図された空のHEARTBEAT.mdですら、そのビルドでは効果がなかった。
修正方法:2つのステップ
- 肥大化したセッションをクリアする。 アイドルエージェントのセッションファイルを消去。次回のハートビートは白紙状態から開始される。不要なセッションだけを削除し、実際のDMやチャットセッションは保持すること。
- 再蓄積を防ぐ。 1回のクリアだけではハートビートがセッションに追加し続けるため効果が続かない。設定変更で対応:
heartbeat every: "0m"を設定してハートビート自体を完全にオフにする(エージェントが何もしない場合)、またはisolatedSession: trueとlightContext: trueを設定し、各ハートビートをフル履歴(約10万トークン以上)ではなく、新鮮で小さなコンテキスト(約2〜5千トークン)で実行する。
補足:他のエージェントも、セッションIDがそのビルドで実際には新しく開始されていなかったため、拡大し続けるセッションを再利用していた。ジョブ間でセッションをリセットすることで、各実行をクリーンに保つことができる。
教訓
- アイドルエージェントは無料ではない——肥大化したセッションでのハートビートは、実際の作業よりもコストがかかる可能性がある。
- ほとんどのトークンが
cacheReadなら、新しい作業ではなく履歴の再読み込みに支払っている。 - 「オフ」が実際にオフであることを確認せよ——報告されたビルドでは、空の
HEARTBEAT.mdはハートビートを止められなかった。 - ターンごとのトランスクリプトを読め;トークン使用量は入力/出力/cacheReadごとに記録されている。
ユーザーはこれらの設定変更によりトークン使用量を半分以上削減した。
📖 全文ソース: r/openclaw
👀 See Also
OpenClaw 2026.9.1移行:r/openclawからのレガシーマルチエージェントアップグレードノート
あるユーザーが、OpenClaw 2026.7.1-2から2026.9.1へのスムーズなアップグレードを記録しています。設定の移行、スキーマの更新、マルチエージェントの修正などを、Codexを使って約30分で完了しました。

1000時間の経験から得た実践的AIコーディング戦略
Redditの投稿では、AIコーディングエージェントを効果的に使用するための具体的なプロンプティングレベルとワークフロー戦略が概説されており、AIをジュニア開発者として扱うこと、段階的な実装、指示ファイルの使用などが含まれています。

修正自托管Docker版OpenClaw中的“导航不支持”和浏览器插件错误
VPS(例:Hostinger)でOpenClawをセルフホスティングする際に発生するEACCES権限エラー、Playwrightの欠落、Chromiumバイナリ問題のステップバイステップ修正方法。

リバースエンジニアリングされたソースからのClaude Codeのプロダクションエンジニアリングパターンの分析
開発者が、Claude CodeのTypeScriptソースコード約50万行をリバースエンジニアリングし、実際の負荷、実際の資金、実際の攻撃者という条件下で現れるプロダクションエンジニアリングパターンを記録した19章からなる技術ハンドブックを作成しました。