🧾 Claude Codeはあなたのプロンプトを読む前に33kトークン送っている — 問題は固定費ではなくキャッシュの壊し方
ロギングプロキシでClaude CodeとOpenCodeの通信を計測したら、初回リクエストの固定オーバーヘッドは33k対7kだった。この数字の読み方と、実運用で本当に効くプロンプトキャッシュの話を整理する。
「hi」とだけ打っても、Claude Codeは33,000トークンをAPIに送っている。
Systimaがハーネスと モデルエンドポイントの間にロギングプロキシを挟んで、Claude Code 2.1.207とOpenCode 1.17.18のJSONペイロードを丸ごと計測した。あなたの1行が処理される前の固定オーバーヘッドは、Claude Codeが約33k(内訳: システムプロンプト約6.5k、27個のツール定義で約24k、初回スキャフォールドで約2.5k)、OpenCodeは約7k。5倍近い差だ。MCPサーバーやinstructionファイルを足した実運用構成だと、Claude Code側は75k——200kコンテキストの37.5%が、会話が始まる前に埋まっている計算になる。
この数字自体はGIGAZINEも報じていて、日本語圏でも「Claude Codeは重い」という文脈で回っていた。でも毎日 claude -p のバッチジョブを予算管理しながら回している身としては、この読み方はちょっと雑だと思っている。
固定33kは、実はほぼタダになる
Anthropic APIにはプロンプトキャッシュがあって、キャッシュ済みプレフィックスの読み取りは通常価格の0.1x。システムプロンプトとツール定義は毎リクエスト同一の先頭部分なので、2回目以降は33kのほとんどが90%引きで読まれる。「33k×リクエスト数がまるごと課金される」わけではない。固定費の絶対値だけ見て騒ぐのは、家賃を毎日払っていると勘違いするのに近い。
本当に見るべきは元記事の後半、キャッシュ効率の節だ。キャッシュはプレフィックスがバイト単位で同一のときだけ効く。OpenCodeはリクエストの先頭が安定していて再利用率が高い。一方Claude Codeはセッション中にプレフィックスが変わる場面があり、そのたびにキャッシュを書き直す。書き込みは読み取りと逆にプレミアム課金(5分TTLで1.25x、1時間TTLで2x)なので、壊した回数だけ損失が積もる。記事は同一タスクで最大54倍のキャッシュ書き込みが発生したケースを挙げている——この54xは単一出所の極端値なので鵜呑みにはしないが、方向性としては実感と合う。
自分のジョブ基盤でも、コスト削減で一番効いたのはモデル変更ではなくこれだった。
壊れる例: セッション途中でMCPサーバーを追加 → ツール定義が変わる
→ それ以降の全プレフィックスが無効化 → 書き込み課金やり直し
ツール定義を途中で変えない。メッセージ履歴を再整形しない。この2つを守るだけで、33kの固定費は月額のノイズに沈む。逆に守らないと、7kのOpenCodeでも普通に高くつく。
ただし「リクエスト数」で逆転する
元記事にはClaude Code側に立つデータもある。ファイル作成と実行チェックのタスクで、Claude Codeは並列ツール呼び出しで3リクエスト(入力計121k)で終えたのに対し、OpenCodeは9リクエスト(計132k)かかった。1発が重くても、往復が少なければ総量で勝つことがある。レイテンシは往復回数に比例して伸びるので、体感速度でも効く。
つまりこの比較、「太っているが歩数が少ない」対「軽いが歩数が多い」なんですよね。どちらが安いかはワークロード次第で、単発の質問なら7kが勝ち、多段のエージェントタスクなら33kが逆転しうる。
Systimaの計測はトークン量だけを指標にしていて、生成されるコードの質は測っていない点は差し引いて読むべきだ。それでもロギングプロキシで実ペイロードを見るという手法は誰でも真似できる。自分のハーネスが毎回何を送っているか、一度も見たことがないなら見てみるといい。請求書の読み方が変わりますよ。