モデルの使い分けやプロンプトの工夫を重ねても、そもそも最初の1往復に固定費がかかっているなら効果は頭打ちになる。Hacker Newsで話題になった実測レポートは、その固定費の正体が「モデル」ではなく「ハーネス」自体の設計にあることを示していた。
Claude CodeとOpenCodeの実測比較（約33,000トークン vs 約7,000トークン）が示す「ハーネス固定費」という論点と、モデルの単価を使い分けるだけでは埋まらない部分をどう考えるか。
systima.aiのブログ記事（Hacker Newsで100pt超の話題）が、Claude CodeとOpenCodeという2つのAIコーディングエージェントに同じ最初のプロンプトを投げ、実際に送信されたリクエストのトークン量をログで比較した。結果、Claude Codeは約33,000トークンを消費してから、ようやくユーザーの入力を処理し始めていた。同条件のOpenCodeは約7,000トークンだったという。
この差はモデルの性能や賢さの差ではない。ツール定義・システムプロンプト・キャッシュされたコンテキストといった、エージェントを動かす土台のプログラム（ハーネス）自体が最初から背負っている固定費の違いだと分析されている。
記事はこの差の要因を、モデルではなくharness設計に求めている。
Claude Codeは大きな固定コンテキスト（システムプロンプトや多数のツール定義）を初回から丸ごと送っている可能性が高く、キャッシュのヒット率や粒度の設計次第で、会話開始時点のオーバーヘッドがそのまま料金・レイテンシに乗る。
使えるツールの数が多いほど、各ツールのスキーマ・説明文がプロンプトに含まれる。モデルが実際のユーザー指示を読む前の「前置き」が、ツールが増えるほど長くなる構造そのものが固定費の一部になる。
OpenCodeはより薄いハーネスとして設計されており、同じ作業をこなすにも前置きが少ない。ツールの数を絞る、システムプロンプトを簡潔にするといった設計判断の差が、そのまま実測値の差に出ている。
ここが核心。「モデルを賢く・安く使い分ける」だけでは埋まらないコストがある。それはモデルを選ぶ前、会話が始まる前に、ハーネスそのものが背負っている固定費だ。
以前この場で書いた「読む仕事に高いモデルを使わない」という運用ルールは、タスクの性質に応じてモデルの単価を変える工夫だった。しかし今回の実測が示すのは、モデルを何にしようと、ハーネス自体が持つ固定のオーバーヘッド（この場合は約3.3万トークン）はそのまま乗る、ということだ。単価の最適化と、固定費の最適化は別の軸になる。
この数字を自分の環境にそのまま当てはめる必要はないが、示唆は具体的だ。使っているツールの数を必要最小限に絞る、長大な指示ファイルを肥大化させたままにしない、といった「ハーネス側の減量」が、モデル選択とは別の場所で効いてくる可能性がある。
複数のツール・MCPサーバーを繋いでAIエージェントを運用しているなら、同じ固定費が積み上がっている可能性が高い。