OpenClaw 節約ガイド：月に 2 万円節約した方法

この記事を読むのに必要な時間は 16 分

古いものを繰り返し読ませない

原文タイトル：なぜ私のOpenClawセッションは1日で2150万トークンを焼却したのか（そして実際に修正された内容）
原著者：MOSHIII
翻訳：Peggy，BlockBeats

Editor's Note: With the rapid spread of Agent applications, many teams have noticed a seemingly abnormal phenomenon: while the system appears to be running normally, the token costs are continuously rising unnoticed. This article, through the breakdown of a real OpenClaw workload, reveals that the cause of cost explosion often does not come from user input or model output, but from the overlooked cached prefix replay. The model repeatedly reads a vast historical context in each call, resulting in massive token consumption.

The article combines specific session data to demonstrate how large intermediate artifacts such as tool outputs, browser snapshots, JSON logs, etc., are continuously written to historical context and repeatedly read in the agent loop.

Through this case study, the author proposes a clear optimization approach: from context structure design, tool output management to compaction mechanism configuration. For developers building Agent systems, this is not only a technical troubleshooting record, but also a practical money-saving strategy.

Below is the original text:

I analyzed a real OpenClaw workload and discovered a pattern that I think many Agent users will recognize:

The token usage looks very "active."

The replies also look normal.

But the token consumption suddenly exploded.

Here is the breakdown of the structure, root cause, and the actual viable repair path of this analysis.

TL;DR

The biggest cost driver is not too long user messages but the massive cached prefix being replayed repeatedly.

From session data:

Total tokens: 21,543,714

cacheRead: 17,105,970 (79.40%)

input: 4,345,264（20.17%）

output: 92,480（0.43%）

In other words, the majority of the cost of inference is not in processing new user intent, but in repeatedly reading a vast historical context.

The "Wait, How Did We Get Here?" Moment

I originally thought high token usage came from: very long user prompts, heavy output generation, or expensive tool invocations.

But the dominant pattern is:

input: a few hundred to a few thousand tokens

cacheRead: each call 170k to 180k tokens

In other words, the model is rereading the same huge stable prefix every turn.

Data Scope

I analyzed data from two levels:

1. Runtime logs
2. Session transcripts

It is important to note:

Runtime logs are mainly used to observe behavioral signals (e.g., restarts, errors, configuration issues)

Exact token statistics come from the usage field in session JSONL

Scripts used:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

Generated analysis files:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

トークンの実際の使用先はどこにありますか？

1）セッション集中

あるセッションの使用が他を大きく上回りました：

570587c3-dc42-47e4-9dd4-985c2a50af86：19,204,645 トークン

その後、急激な減少がありました：

ef42abbb-d8a1-48d8-9924-2f869dea6d4a：1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5：649,584

2）挙動集中

トークンの主な出どころは：

toolUse：16,372,294

stop：5,171,420

問題の主要な原因は、通常のチャットではなく、ツール呼び出しのループにあります。

3）時間集中

トークンのピークはランダムではなく、数時間帯に集中しています：

2026-03-08 16:00：4,105,105

2026-03-08 09:00：4,036,070

2026-03-08 07:00：2,793,648

巨大なキャッシュプレフィックスには何が含まれていますか？

会話内容ではなく、主に大規模な中間生成物が含まれています：

巨大な toolResult データブロック

非常に長い推論 / 思考のトレース

大規模な JSON スナップショット

ファイルリスト

ブラウザの取得データ

サブエージェントの会話記録

最大セッション内での文字数はおおよそ次の通りです：

toolResult:text：366,469 文字

assistant:thinking：331,494 文字

assistant:toolCall：53,039 文字

これらのコンテンツが履歴コンテキストに保持されると、その後の各呼び出しでキャッシュプレフィックスを通じて再度読み込まれる可能性があります。

具体例（セッションファイルから）

非常に大きなコンテキストブロックが以下の場所で繰り返し出現しました：

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

大規模なゲートウェイ JSON ログ（約 3.7 万文字）

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

ブラウザースナップショット + セキュアなラッピング（約 2.9 万文字）

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

大きなファイルリスト出力（約 4.1 万文字）

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

session/status スナップショット + 大規模なプロンプト構造（約 3 万文字）

「重複コンテンツの浪費」vs「キャッシュ再生負荷」

また、1回の呼び出し内の重複コンテンツの割合を測定しました：

重複率約：1.72%

確かに存在しますが、主要な問題ではありません。

真の問題は：キャッシュプレフィックスの絶対的な大きさがあまりにも大きいことです

構造は：巨大な履歴コンテキスト、各ラウンドの呼び出しで再読み込み、上記にわずかな新しい入力を追加しています

したがって、最適化の重点は重複ではなく、コンテキスト構造の設計にあります。

Agent ループでこの問題が特に発生しやすい理由は何ですか？

3 つのメカニズムが重なり合います：

1、多くのツール出力が履歴コンテキストに書き込まれます

2、ツールのループにより大量の短い間隔呼び出しが発生します

3、接頭辞の変化が非常に小さい → キャッシュは毎回再読み込みされます

コンテキストの縮約が安定的にトリガーされない場合、問題は急速に拡大します。

最も重要な修正戦略（影響でソート）

P0—巨大なツール出力を長期コンテキストに挿入しないでください

超大規模ツール出力に対して：

・サマリーを保持 + 参照パス / ID

・元のペイロードをファイルアーティファクトに書き込み

・チャット履歴に完全な元文を保持しないでください

これらのカテゴリを優先的に制限してください：

・大規模な JSON

・長いディレクトリリスト

・ブラウザの完全なスナップショット

・サブ Agent の完全な記録

P1—縮約メカニズムが実際に機能していることを確認してください

このデータでは、互換性の問題が繰り返し発生しています：縮約キーが無効です

これにより最適化メカニズムが静かに無効になります。

正しい手順：バージョン互換性のある構成のみを使用します

次に、次の手順を実行してください：

openclaw doctor --fix

起動ログを確認して、縮約が受け入れられたことを確認してください。

P1—推論テキストの永続化を減らす

繰り返しの推論が長い推論テキストを避けます

本番環境では、完全な推論ではなく簡潔なサマリーを保存してください

P2—プロンプトキャッシングデザインの改善

目標は cacheRead を最大化することではありません。目標は、コンパクトで安定した、高付加価値のプレフィックスでキャッシュを使用することです。

建議：

· 安定したルールをシステムプロンプトに組み込む

· 安定しないデータを安定したプレフィックスに入れない

· 各ラウンドでの大量のデバッグデータの注入を避ける

実践的な損切り計画（明日取り組む場合）

1、最も cacheRead の割合が高いセッションを特定する
2、暴走セッションに対して /compact を実行する
3、ツールの出力に切り捨てと artifact 化を追加する
4、変更ごとにトークン統計を再実行する

重要な KPI を追跡する：

cacheRead / 総トークン数

ツール使用の平均 Total/call

100k 以上のトークン呼び出し数

最大セッションの割合

成功のサイン

最適化が効果を発揮した場合、以下が見られるはずです：

100k 以上のトークン呼び出しが明らかに減少

cacheRead の割合が低下

toolUse の呼び出し重みが低下

単一セッションの支配度が低下

これらの指標に変化が見られない場合、コンテキスト戦略が依然として緩すぎることを意味します。

再現実験コマンド

python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt

python3スクリプト/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt