0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeのトークンが20Kも余計に消えていた——cache_creationのinflationを30秒で発見する方法

0
Last updated at Posted at 2026-05-22

主旨

Claude Code の利用者の集まりで2026年4月12日に投稿された 起票46917 は、同じ request の payload (実機で978 bytes 少ない側) で v2.1.100 以降が v2.1.98 と比べて約20,000 tokens 多い cache_creation_input_tokens を消費する事実を、HTTP の proxy の body の取得の経路で実機で確認した。server 側の version-specific な変更、利用者の側で停止の経路が無い、加えて20K tokens は model の context window に入る (請求の段だけではない) 構造。

本記事は46917 を中核に、3件の関連の起票を1つの structural class (server 側の挙動の変更で、利用者の側からは上流の regression に見える経路) に integration し、6月15日の課金の改定の3つの interaction、利用者の側の取得の道具の2件、利用者の側で fix 不可能の articulate を整理する。英語の独立な分析の Gist (https://gist.github.com/yurukusa/e7ddbcf900d54028d4d271831bc99cca、 1,389単語、MIT) の日本語の利用者の集まりへの直接の到達の経路。

46917 の発見の整理

提出者の実機の事例:

version request の payload (bytes) cache_creation_input_tokens cache_read 合計
v2.1.98 169,514 49,726 0 49,726
v2.1.100 168,536 (-978 B) 69,922 0 69,922
v2.1.101 171,903 (+2,389 B) 約72,000 0 約72,000

v2.1.100 は v2.1.98 と比べて978 bytes 少ない payload を送るが、20,196 tokens 多く請求される。 利用者の側の payload の差は問題ではなく、server 側で request を受領した後に発生する inflation の事実。別の口座での同じ version の cross-account の検査で500 tokens 未満の noise、口座ではなく version に紐付く。

実機の対話の mode の取得の経路でも整合。40件以上の過去の session の取得で bimodal の分布 (group A: 約50K、group B: 約71K) が確認、group B は v2.1.100 以降の cold-cache の --print の整数で整合。

何が load-bearing か

20K tokens は cache_creation_input_tokens で、metadata ではない。model の context window に入る。利用者は書いていない。利用者は何かを inspect する経路が無い。CLAUDE.md と、対話の歴史と、道具の結果と、context window の中で競合する。請求の段は1つの懸念で、context の汚染は別の懸念。

4件の起票の structural class

46917 の shape は、直近の Claude Code の cost-transparency の起票の集まりの中の1つの instance である class の articulation:

server 側の挙動の変更 (routing、system prompt の注入、prompt cache の key の形) で、利用者の側からは上流の model の regression や環境の quota の cut に見える経路。

同 class の4件の起票:

  • #46917 (2026-04-12、cache_creation の20K の inflation)
  • #38335 (2026-03-24、Max plan の5時間の cap が同じ作業で1-2時間で消費の急速な合図)。利用者の側の workaround は0件、server 側の原因の articulate は0件
  • #60093 (2026-05-18、5月5日から7日の窓で model が silent に Opus に経路、1,050米ドルの過剰請求の事案)。利用者の側の在中の合図は0件、利用者は請求の段で発見
  • #60428 (2026-05-19、Slack の MCP の道具が約1時間後に silent に脱落、claude mcp list は引き続き「Connected」 を報告)。直接の請求の関連は弱いが、同じ shape (server 側の状態が invisible に変化、utility の頁は古い状態を表示)

統合の性質。利用者の observable の表面 (CLI の出力、status の line、集計の dashboard) と、実機の費用と context を駆動する server 側の状態が、decoupled の構造。 利用者は inspect 不可能の inflation を支払い、選択していない model に routing され、disable していない道具を喪失する。唯一の signal は下流の症状 (請求、挙動の変化、道具の不在の error) で、複数の可能性の原因がある経路。

6月15日の課金の改定との3つの interaction

Anthropic の課金の構造は2026年6月15日に変更される。移行の文書は cap の再計算 (週次の token の budget、model 固有の倍率、opt-in の機能の budget への請求) で articulate される。46917 の class の shape は、同改定と3つの方向で interact:

  1. cache_creation_input_tokens の40%の overhead は、新規の週次の cap の40%を早く消費する。 古い5時間の rolling cap で快適に作業していた利用者が、同じ作業の流れで新規の週次の cap を超過の見込み。

  2. 6/15 以前の workaround (v2.1.98 への downgrade) は auto-update と衝突する。 提出者の articulate: 「v2.1.98 は v2.1.104 の install の後で local の versions の樹に保留されない」。今日 downgrade した利用者は、明日には古い binary が silent に削除済の可能性、workaround の有効期間は限定的。

  3. model routing の class (#60093) は財務の load が増加する。 新規の課金の構造で、Sonnet から Opus への undisclosed な routing の変化の請求の結果は、異なる、加えて token 1件あたり大きい。Opus 4.7 と Sonnet 4.6 の倍率の差は非自明で、silent な routing の判定が silent な乗算に変化。

46917 の発見は現在 Anthropic から日付の articulate が0件、workaround は脆弱の合図。6月15日 (本記事の起稿から23日後) で、利用枠の plan の Claude Code の利用者の全件が新規の課金の構造に移行。cache inflation が cost の事案として重要の窓は閉じつつある (cap の cliff の事案に変化)。

利用者の側の instrumentation

提出者の道具 (HTTP の proxy + body の取得) は inflation の検出の最厳密の経路。proxy を起動したくない利用者向けの2件の lighter-touch の代替:

1. 同 session の中の cache_creation を turn ごとに記録

PostToolUse の hook で input の JSON の tool_response.usage.cache_creation_input_tokens の field を読む (新規の Claude Code の version の Stop の event の中で field が存在)、turn ごとに記録。参照の実装: cc-safe-setup の cache-tier-logger.sh (MIT)。1週間の継続の実行、cache_creation を時間軸に plot、version の境界の段の step-function の合図を見る経路。

2. cross-version の A/B の --print mode の経路

2件の Claude Code の binary (例: v2.1.98 と v2.1.104) を既知の path に固定、同じ trivial な prompt (--print "1+1") で両方で実行、response の usage の object を diff。提出者の methodology の短縮形、version の対ごとに約30秒で数値を取得可能。

routing の変化の class (#60093) の対応の instrumentation は、turn ごとの model-id の取得。tool_response.model の field は実機の各 turn の model を報告、session が Sonnet 4.6 を予期して任意の turn で claude-opus-4-7[1m] を観察した場合、routing の判定が invisible に発生済の合図。session の中で model-id の変化を flag する hook で、silent な upgrade を請求の前に捕捉の経路。

利用者の側で fix 不可能の articulate

46917 の inflation 自体は利用者の側で patch 不可能。20K の追加の tokens は request の client の出口の後で server 側で挿入、client は inflation の検出 (上記の instrumentation の経路) は可能、inflation の除去は不可能。完全な fix は Anthropic の側で次の3つの選択肢の1つ:

  1. 追加の cache_creation_input_tokens が何を表すか (system prompt の拡張? 道具の集まりの再注入? それ以外?) の文書化、利用者が請求と context の汚染の判定の経路を持つ状態。
  2. request ごとの opt-out (X-CC-Skip-Server-Injection: 1 の様式の header) の提供、v2.1.100 以前の挙動を inflation の機能の対価で選択可能。
  3. inflation を利用者の側で toggle 可能の feature の flag に紐付け、trade-off の articulate。

3件の全件で operator 側ではなく Anthropic 側の判定。現在の workaround (downgrade) は operator 側だが上記の有効期間の問題の合図。

methodology の articulation

46917 の提出者の証拠は請求の事案で珍しく厳密: HTTP の proxy で body の取得、cold-cache の再現、byte の段の payload の比較、cross-account の cross-check、40件以上の歴史の session の bimodal な分布。同 methodology は class に再利用可能 — server 側の inflation を疑う任意の operator が同 instrumentation を実行、比較可能の数値の出力。提出者の claude-code-logger@1.0.2 は npm で公開、起動は1件の command。

同程度の証拠は、任意の operator 側の cost の議論で Anthropic の support との load-bearing の artifact。「expected より quota を多く使用」 は曖昧な complaint、「同じ request の payload で v2.1.100 と v2.1.98 の cold-cache の --print の起動の cache_creation_input_tokens の差は20,196 tokens 多い」 は測定可能の主張。

主張しない事 / 主張する事

本記事は主張しない:

  • inflation が意図的 (legitimate な変更 — 豊富な道具の集まりや改善された system prompt 等 — の副作用の可能性)
  • v2.1.98 と v2.1.100 以降の利用者の側の質の差が追加の tokens に原因 (提出者は差を観察、原因の isolate は不可能)
  • v2.1.100 以降の使用の全件が bad (新規の version は古い側に無い機能を提供、trade-off は operator ごと)

本記事は主張する:

  • inflation は再現可能で version-specific (提出者の証拠が articulate)
  • inflation は context window に入る (請求の段だけではない、cache_creation_input_tokens の field の意味から)
  • inflation は server 側の cost-transparency の structural class の1件、6/15 以降の課金の構造で重要性が増加
  • operator 側の instrumentation で inflation の surface は可能、除去は不可能 (load-bearing の fix は Anthropic の側の文書化または opt-out)

関連の資源

著者の財務の利害の開示

著者 (yurukusa) は本分析に関連する2件の有料の商品を販売する: 19米ドルの Claim-Verify Handbook (130件の operator/claim/runtime の gap の corpus、本記事の structural class は同書の覆う「公開の表面が runtime の状態から decoupled」 の pattern の1件) と、19米ドルの Migration Playbook Edition 2 (2026年6月15日の課金の改定の判定の枠組み、第6章で cache の inflation と quota の cap の interaction を直接 articulate)。cc-safe-setup の open-source の repository (MIT) は cache-tier-logger.sh の turn ごとの取得の hook を公開。

46917 の再現の道具 (claude-code-logger@1.0.2) は著者の道具ではない、著者への credit。本記事と英語の Gist は無料の MIT、2件の本の購入を要求しない。

— yurukusa、2026年5月23日

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?