OpenClawのAndroid通知転送が1日で127.8Mトークンを消費

r/openclawのユーザー（/u/ultraneutral72）が、予想外に高額なトークン請求の原因をAndroidの通知転送に突き止めた。2026年10月1日、このユーザーのOpenClawインスタンスは1日で合計127,825,724トークンを記録した。しかも、エージェントと積極的に対話していたわけではなかった。

構成

• CachyOS/Linux上のOpenClaw 2026.9.7
• メインエージェント: ネイティブCodexランタイム上のopenai/gpt-6-astra
• 通知転送を有効にしたSamsung Galaxy S25
• 30分ごとのハートビート
• 大量に蓄積されたメインセッション履歴

ログからわかったこと

Androidの充電通知（com.android.systemui、キーcharging_state）がnotifications-eventウェイクとして転送されていた。一部の時間帯ではこれが約30秒ごとに発火し、そのたびにモデル呼び出しが発生していた。エージェントは多くの場合no_changeやNO_REPLYと応答していたが、そうした返信にもトークンが消費されていた。多くのターンではheartbeat_respondツール呼び出しに続いて、さらに別のモデル応答が含まれていた。

ある28分間のウィンドウには56ターン、使用量記録付きの112モデル応答、そして約1490万トークンが含まれていた。イベントは同じ充電インジケーターを、更新されたバッテリー残量や残り充電時間とともに運び続けていた。

2026年10月1日の内訳

• 合計127,825,724トークン
• キャッシュ済み入力トークン125,030,400
• 非キャッシュ入力トークン2,734,313
• 出力トークン61,011
• 記録されたトークンの約87%が通知トリガーのターンに関連
• 約12%がスケジュールされたハートビートに関連

ユーザーは、累積スレッドカウンターに頼るのではなく、OpenClawのトランスクリプト記録とネイティブ使用量記録に対して合計を照合し、応答IDを重複排除したうえで応答ごとの使用量を合算した。

重要な但し書き

合計のおよそ98%はキャッシュ済み入力だった。これはトークン量の測定であり、1億2780万トークンが非キャッシュの全額レートで請求されたという主張ではない。ユーザーは今のところゲートウェイを停止し、既存のPythonエネルギー表示ジョブを独立したシステムタイマーに移した。制御されたビフォーアフター試験はまだ実施されていない。

未解決の疑問

• これは設定の問題なのか、バグなのか？
• 進行中のシステム通知更新がエージェントを起動する前に、それらをフィルタまたはデバウンスする推奨方法はあるか？
• バックグラウンドイベントは、蓄積されたメインセッションではなく、分離されたより小さなコンテキストで実行すべきか？

Android通知をOpenClawに転送しているなら、次に使用量ダッシュボードを見る前に、charging_stateのような変化の多いシステムキーがエージェントループに到達していないか確認しよう。