Claude Codeが7日で$10,007燃やしていた話
自分のClaude Code運用を7日分ログから洗ったら、API換算で$10,007.22、このうち$2,726.01が「修正可能な浪費」 であることが具体的に特定できた。本記事はその経緯と、自作ツール cc-token-diet の中身、そして読者が同じ計測を5秒で回すための手順を残す。
前提: 筆者はMax 20x ($200/月)で定額なので、$10,007がそのままカードに乗るわけではない。ただしこの数字は**「自分が今使っているcontext intensity をAPI従量換算するといくらになるか」**の量的指標で、Max/Proの枠を食い潰すスピード感と強く相関する。1時間でquotaが溶ける体感と、この$数字は同じものを別表記しているだけ。
なぜ新しいツールを書いたか
既存の類似ツールで十分確かめられるかを先に調べた。
| ツール | 何を返すか | 何を返さないか |
|---|---|---|
| ccusage (13.2k★) | 総額 / 期間別集計 / PDF export | 浪費パターンの特定、修正案 |
| cc-cost-check | コミット/時間/日ごとのコスト | どのセッションが問題か |
| cc-cost-forecast | 月末時点のAPI換算予測 | 現在の浪費を止める方法 |
「総額は分かる、でもどこから手を付ければいいか分からない」という穴が残っていた。そこで筆者は、ローカルの ~/.claude/projects/ 配下に Claude Code が書き出す .jsonl ログを直接パースし、具体的な浪費パターン3種 × 各セッションの$換算 × 対応する設定変更 を返す CLI を書いた (yurukusa/cc-token-diet, MIT)。
使い方は1行。
npx github:yurukusa/cc-token-diet
ネットワーク通信はなし。APIキーも不要。既に手元にあるログを読むだけ。
実行して出てきた数字 (筆者自身のログ、7日間)
📉 cc-token-diet report (last 7 days)
────────────────────────────────────────────────────────
Sessions analysed: 312 Assistant turns: 36973
Input: 457.8K Output: 7.36M
Cache read: 5.21B Cache write: 87.15M
API-equivalent spend: $10007.22 (Opus 4.x pricing)
↳ On Max/Pro you pay the flat subscription; this is context intensity
↳ On Sonnet divide by ~5. The patterns stay the same either way.
Cache hit ratio: 98.4% (higher is better, aim >85%)
🔥 Waste patterns:
❗ 87 runaway session(s) (>100 assistant turns) (≈ $2726.01 wasted)
Fix: Long single sessions bloat context exponentially.
Use /compact or restart for each logical task.
See: Token Book ch3 (context management)
🌡️ Hottest sessions:
$513.26 2026-04-19 projects-cc-loop 955 turns / 157min
$499.34 2026-04-16 -home-namakusa 898 turns / 3898min
$431.08 2026-04-20 projects-cc-loop 1103 turns / 180min
読みどころは4点ある。
(1) 総額 $10,007 / 7日 = 月換算 $42,887
Max 20xの月額$200に対して214倍。つまり筆者は、定額枠の頭を常に200倍速度で叩いている。これが「朝起きたらquotaが半分消えていた」現象の正体。
(2) Cache hit ratio 98.4%
これは良い数字。目安は85%以上で、筆者のケースはそれをクリアしている。CLAUDE.md / tools / system prompt が安定していて、毎ターンのcache writeが最小限であることを示す。ここが低いと別の最適化（CLAUDE.md圧縮、agent定義の整理）が効く。
(3) Runaway sessions 87個 = $2,726
ここが最大の発見。100ターン超の長時間セッションが7日で87個あり、そこで$2,726分のcontext intensityが消えていた。1セッションあたり$30前後の「気付かずに溶かしていた」塊が、週に数十個単位で発生していた計算。
(4) 単一セッション最大 $513 / 155分
最も熱かったセッションは projects-cc-loop で 955ターン・155分。/compact が間に合わなかったか、意図せず長時間走り続けたセッション。この1つだけでMax 20x の 2.5ヶ月分の枠相当を溶かしている。
浪費の3パターン (cc-token-dietが見ている軸)
ツールは .jsonl を読んで次の3軸でセッションを分類する。どれも既存研究・Issue報告で裏が取れているもの。
パターン1: Cache write ratio > 30%
毎ターン cache を書き直していると、安定 context の 約12.5倍 のコストになる。原因:
- CLAUDE.md が肥大化して更新が頻発
- サブエージェント定義が毎ターン変わる
- MCP tool定義のシャッフル
- v2.1.36-2.1.87 の Dynamic Tool Descriptions バグ (v2.1.89で修正済みだが影響期間長い)
Fix: CLAUDE.md を2,000字以下に圧縮 / MCP tool を必要な物だけ enable / CLI を v2.1.89 以上に更新。
パターン2: Verbose output (turn平均 >3K output tokens)
モデルに「全部説明して」「詳細にまとめて」と頼んだセッションで発生しやすい。output tokenはcache readの50倍 高い ($75/MTok vs $1.50/MTok) ので、長い回答を求めると一瞬で積み上がる。
Fix: system promptで「簡潔に / 箇条書きで / コードのみ」を明示 / 説明系タスクと実装系タスクをセッション分離。
パターン3: Runaway sessions (>100 assistant turns)
今回の筆者の事例。1セッションが長くなると context が指数的に膨らみ、各ターンが読み込む/書き込むtoken量が増える。100ターン超は実測で本人の手元データでも明確な分断点になっていた。
Fix: 1セッション = 1タスク原則を徹底 / /compact を積極的に使う / /clear で logical タスクごとにリセット / PreCompact hook で自動 snapshot を取っておく。
「どの設定を変えたか」実測
上記3パターンのうち、筆者の場合は (3) が主因と特定できたので、次の3点を即反映した。
変更1: /compact タイミングを前倒し
従来: 自動 auto-compact (200Kコンテキスト境界) に任せていた
変更後: 50ターン or 30分経過で明示的に /compact を叩く
これはそのままでもOKだが、PreCompact hook を入れて conversation の summary をローカルファイルに書き出すようにした。再開時に要点だけ Claude に戻せるので再構築コストが下がる。
変更2: 1タスク1セッションを徹底
「今のタスクが終わったら、次のタスクは必ず /clear してから」をhook (Stop event) で強制。hook 実装例:
#!/bin/bash
# stop-clear-reminder.sh (PostToolUse/Stop event)
# 100ターン超のセッションで終了した時に /clear を提案
TURN_COUNT=$(jq '.conversation_length // 0' <<< "$CC_INPUT")
if [ "$TURN_COUNT" -gt 100 ]; then
echo "⚠ このセッション ${TURN_COUNT}ターン。次のタスク前に /clear 推奨" >&2
fi
exit 0
変更3: CLAUDE_CODE_DISABLE_1M_CONTEXT=1 を zshrc に追加
1M context variantは200K境界でauto-compactしない。silent switch (#49541) を経由して気付かずに1Mに入ってしまうと、runaway化が加速する。最初から1Mを選べなくする方が安全。
echo 'export CLAUDE_CODE_DISABLE_1M_CONTEXT=1' >> ~/.zshrc
再計測
3つの変更を反映して3日後に再実行した結果、runaway session 数は87→28、waste $は $2,726→$742 に減った (同じ利用量での比較)。完全にゼロにはならない ( Claude自身が長時間thinkingに入るケースは手元のhookでは防げない) が、自分側の運用起因の浪費は2/3程度削れた。
ツールが何をしないか
-
サーバーに送らない: 全てローカル処理。1 CLI file (
cli.mjs) で完結。依存なし。 - 実課金額は返さない: あくまでOpus 4.x公称レートでの "API換算" 値。Max/Pro定額の実際の請求とは別物。
- Sonnet前提なら 出力を約5で割る。パターン自体は同じ。
まとめ
- 自分のClaude Code運用7日分を ログレベルで洗ったら $10,007 API換算 / うち $2,726 が修正可能な浪費 だった
- 浪費の主因は「1セッションが100ターン超 = runaway」。87個検出
-
/compact前倒し + 1タスク1セッション hook + 1M disable で $2,726 → $742 に削減 - ツールは yurukusa/cc-token-diet で公開。
npx github:yurukusa/cc-token-dietで5秒で実行可能。ローカルログだけ読む
次の一歩
上記で書いた3パターンの各症状ごとの対策は、Token Book (¥2,500) に10章で体系化している。特にch3 (context management) と ch8 (症状別対策48件) が本記事の実測データを補完する。
無料で試すなら:
- Token Checkup (yurukusa.github.io/cc-safe-setup/token-checkup.html): 10問診断で自分のトークン消費パターンを5分で把握
- cc-token-diet (github.com/yurukusa/cc-token-diet): 本記事で使ったCLI。1コマンドで実数値を確認
「総額は見えているけど、どこから直せばいいか分からない」状態から、「次に変える設定はこの3つ」に落とし込むための道具として使ってほしい。