7月12日、systima.aiが「Claude Code Sends 4.7x More Tokens Than OpenCode Before Reading Your Prompt」と題した記事を公開した。AIコーディングツールのAPIコストが「なぜか想定より高い」と感じているエンジニアに向けて、ツールとモデルエンドポイントの間にロギングプロキシを挟み、実際に流れるリクエストペイロードを計測した検証記事だ。

結論から言うと、Claude Codeはユーザーが1文字も入力する前の時点で、すでに約32,800トークンを消費している。同一モデルで比較したOpenCode（GitHubで公開されているオープンソースのCLIコーディングエージェント）の約6,900トークンと比べると、約4.7倍の差だ。コストダッシュボードが想定外に高い原因の多くが、この「起点の違い」にある。

計測手法と条件

systima.ai（AIシステムのコスト最適化を専門とするスタートアップ）は、ロギングプロキシをハーネス（各ツール）とモデルエンドポイントの間に挟み、すべてのリクエストペイロードと使用量ブロックを記録した。

harness (Claude Code / OpenCode)
  → logging proxy（リクエストペイロードと使用量ブロックをキャプチャ）
    → model endpoint

テスト条件は、Claude Code 2.1.207とOpenCode 1.17.18を共にclaude-sonnet-4-5（Anthropicが2026年7月にリリースした最新ソネットモデル）に固定。MCPサーバーなし、ユーザー設定なし、メモリなし、命令ファイルなしのクリーンな環境から始め、変数を一つずつ追加していく形で測定している。

ユーザーが何も入力する前に、すでに4.7倍の差がある

最初のタスクは「Reply with exactly: OK」という22文字の指示だ。この結果が核心をつく。

Claude Codeのツール群には、コーディングのコア機能に加えてCronCreate、Monitor、Taskファミリー、ワークツリー管理、プッシュ通知といったバックグラウンドエージェント・オーケストレーション基盤が含まれる。最初のユーザーメッセージには、委任のためのエージェントタイプカタログ、利用可能なスキルカタログ、ユーザーコンテキストの3つのリマインダーブロックが自動注入される。ツールスキーマが支配的であり、Claude Codeの〜33,000トークンのうち約24,000トークンがツール定義だ。

プロンプトキャッシュが「節約策」にならない理由

「プロンプトキャッシュを使えばコストは下がるはず」という期待への答えも、データが出ている。キャッシュが有効に機能するにはプレフィックスが安定している必要があるが、ここでも差は顕著だった。

OpenCodeは全リクエスト・全セッションにわたってバイト単位で同一のプレフィックスを出力した。同一タスクを3セッション実行しても、2回目以降はキャッシュ書き込みがゼロで、すべてキャッシュ読み取りで済んだ。

Claude Codeはセッション内で複数の異なるリクエストクラスを生成し、会話が進むにつれて<system-reminder>ブロックが追加されるなど、プレフィックスが変化した。その結果、同一タスクでOpenCodeの最大54倍のキャッシュ書き込みトークンを記録したケースもある。キャッシュ書き込みはキャッシュ読み取りより1.25倍高額なため、これがコストダッシュボードが想定外に上昇する直接原因になる。

さらに、キャッシュが一切効かないコストが3つある。TTL（5分）を超えた際の再書き込み（少し席を外すだけで全スタックが再プライムされる）、リクエスト数に比例するキャッシュ読み取り料金、そしてコンテキストウィンドウの消費だ。最後が特に見落とされやすい。約85,000トークンのブートストラップは200,000トークンウィンドウの40%以上を常時占有し、実際のコードに使えるスペースを圧迫する。コンテキスト消費はキャッシュの影響を一切受けない。

現実の設定が加わると、さらに膨らむ

ベースラインだけでも差は大きいが、実運用に近い設定を重ねると数字はさらに跳ね上がる。

命令ファイル（AGENTS.md / CLAUDE.md）：本番リポジトリの72KBの命令ファイルを追加すると、両ハーネスともに1リクエストあたり約20,000トークン増加した。注意点として、Claude Code 2.1.207はAGENTS.mdを無視し、CLAUDE.mdにリネームして初めて読み込んだ。サイレントに無視されるため、想定通りに動作しているか境界で検証する必要がある。

MCPサーバー（Model Context Protocol準拠の外部ツール接続サーバー）：小規模なサーバー1台あたり約1,000〜1,400トークン。5台追加するとClaude Codeで4,900トークン、OpenCodeで6,967トークン増加した。

サブエージェント：最も大きな乗数がここだ。2つのサブエージェントに並列委任したところ、直接実行で121,000トークンだったタスクが513,000トークンになった。4.2倍の乗数だ。各サブエージェントが自身のブートストラップコストを持ち、その出力トランスクリプトを親エージェントが再度消費するためだ。

「全部乗せ」の実測値：OpenCodeで11台のMCPサーバー（メール・カレンダー、タスク管理等）と72KBの命令ファイルを組み合わせた場合、ユーザーが1文字も入力する前のコールドキャッシュ書き込みが90,817トークン（179ツール、277KBのスキーマ）に達した。Claude Codeは4台のMCPサーバーと命令ファイルで約75,000トークン（118ツール、311KB）だった。

多段タスクではClaude Codeが逆転することもある

Claude Codeが常に高コストかというと、そうでもない。FizzBuzzの実装・実行・テスト・修正ループでは、Claude Codeが3リクエストで完了したのに対しOpenCodeは9リクエスト（+1タイトル生成）を要した。Claude Codeはファイル書き込みとスクリプト実行を1回のパラレルツール呼び出しにまとめたためだ。累積入力トークンはClaude Codeが約121,000、OpenCodeが約132,000と逆転した。「メーターの起点が高いかどうか」と「セッション全体でいくら使うか」は別の話であり、タスクの性質によってどちらが有利かは変わる。

Claude Codeはリッチなオーケストレーション基盤を毎回丸ごと送信する設計、OpenCodeは最小限を安定して送る設計という構造的な違いが、この計測で明確になった。コスト・レイテンシ・コンテキスト予算のいずれも、ベースラインのトークン消費量に直接影響される。「なぜコストが上がっているのか」をデータで把握したいなら、APIの境界でプロキシを挟んで計測するアプローチが有効だ。

詳細はClaude Code Sends 4.7x More Tokens Than OpenCode Before Reading Your Promptを参照していただきたい。