主旨

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	合計
v2.1.98	169,514	49,726	49,726
v2.1.100	168,536 (-978 B)	69,922	69,922
v2.1.101	171,903 (+2,389 B)	約72,000	約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:

cache_creation_input_tokens の40%の overhead は、新規の週次の cap の40%を早く消費する。 古い5時間の rolling cap で快適に作業していた利用者が、同じ作業の流れで新規の週次の cap を超過の見込み。
6/15 以前の workaround (v2.1.98 への downgrade) は auto-update と衝突する。 提出者の articulate: 「v2.1.98 は v2.1.104 の install の後で local の versions の樹に保留されない」。今日 downgrade した利用者は、明日には古い binary が silent に削除済の可能性、workaround の有効期間は限定的。
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つ:

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

関連の資源

起票46917 の本文 (原本、提出者の HTTP proxy の手法と数値の articulation)
英語の独立な分析の Gist (本記事の英語版、1,389単語)
cc-safe-setup の cache-tier-logger.sh (MIT、turn ごとの cache_creation の取得の hook)
claude-code-logger@1.0.2 (npm、HTTP proxy + body の取得の道具、提出者の道具で著者は別)

著者の財務の利害の開示

著者 (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日