皆がClaude Codeはトークンを無駄にすると言っていますが、実際にどれほど消費するのでしょうか？今回、ついに誰かが数字を算出しました。
最近、Composioチームによる興味深い比較実験がありました。彼らは同じモデルを Kimi K3を、それぞれ異なる3つのエージェントフレームワーク（harness）—Claude Code、Hermes、—で実行する Kimi コード——合計で28の完全に同じタスクをテストしました。
結果、3つのharnessのタスク成功確率はほぼ同じです： Kimi コードは28個中22個が成功、Hermesは21個、Claude Codeは20個。差はそれほど大きくない。
真に差を生むのは、トークンの消費量です。同じタスクを異なるハーネスで実行した場合、トークン使用量は最大で30倍まで差がつくことがあります！
中央値に基づくと、 Kimi コードは約6.1万トークン、Hermesは約6.7万トークン、一方Claude Codeは直ちに34万トークンに達し、ほぼ Kimi コードの6倍。
按 Kimi K3は、100万入力トークンあたり3ドルの価格で計算されます（エージェントワークフローにおける入力トークンは通常95％程度を占めます）。1タスクあたりの平均コストは次の通りです： Kimi Codeは0.22ドル、Hermesは0.28ドル、Claude Codeは2ドルに達しています。差は明確です。
速度も異なります。中央値の所要時間では、Hermesが最速で179秒です。 Kimi コード297秒；Claudeコード348秒。
したがって、最も速いのはHermesで、最もtokenを節約できるのは Kimi コード、両者は重複していません。
Composioチームは、エージェントのコストを削減したい場合、モデルをすぐに変更するのではなく、まず使用しているハーネスを見直すべきだという明確な結論を導いた。彼らのデータによると、ハーネス自体でコストに9倍の差が生じる一方、モデルの性能はほぼ同等である。
セバスチャン・ラシュカもこの結果を見て投稿し、これは彼が以前にQwen3.6を用いて観察した結果と類似していると述べた：Claude Codeは成功率がほぼ同じであるにもかかわらず、トークン使用量は他の多くのハーネスの2〜3倍である。
彼はいくつかの可能性を挙げました：最適化が十分でないのか、バグがあるのか、それとも意図的にこのような設計にしているのか（より難しいタスクで役立つ可能性があるため）？彼は、さらに時間をかけて丁寧に調査する必要があると述べました。
その後、彼は先月自らローカルのコーディングエージェントに関する記事を執筆した際の観察を追加した。そのとき、Claude Code がなぜより多くのトークンを使用するのかを分析し、その差異は出力トークンではなく入力トークンに主に由来することを発見した。つまり、Claude が内容を2倍書いているわけではない。ログによると、Claude のハーネスはマルチラウンドのインタラクション中に、以前のメッセージ、ツール呼び出し、コマンド出力、ファイル内容など、より多くのコンテキストをモデルに繰り返し投入している。例えば、ある回の実行では、入力トークンが約57.8万に対し、出力は約4500トークンで、25ラウンドにわたった。したがって、より妥当な説明は、Claude のハーネスがマルチステップエージェントの実行中に、プロンプト側の履歴を累積またはより大きなものとして計上していることである。
これらのテスト結果は、harnessの重要性がモデル自体と同等であるという無視できない傾向を示しているようだ。
最近の論文（AIエージェントプラットフォームを手がけるWriter社による）は、制御変数実験を通じて、モデルを変更するよりもハーネス層を変更した方がコスト削減効果が高く、すべてのモデルに利益をもたらすことを体系的に示した。
具体的には、22の企業タスクと6つの基礎モデル（Claude Sonnet 4.6、Gemini 3.1、Gemini Flash 3.5、Qwen 3.6、GLM 5.1、Palmyra X6）を固定した状態で、編成層のみを従来のプロダクションレベルのエージェントループからWriter自社のHarnessに置き換えるという厳密な「制御変数」実験を実施しました。
実験結果によると、各タスクの平均コストは41%低下（0.21ドル→0.12ドル）、中央値遅延は44%短縮（48秒→27秒）、トークン消費量は38%削減（14.2k→8.8k）されました。一方、タスク完了品質はほぼ横ばい（0.78→0.81）であり、サンプルサイズが小さいため有意差とは見なせません。コストパフォーマンス面では、1ドルあたりの品質向上が82%に達し、100万トークンで処理できるタスク数は54.9から92.0へ大幅に増加しました。
したがって、モデルが「水・電気・ガス」になった後、harness があなたの電気代の決定要因となるエアコンなのか？言い換えれば、以前は「モデルが製品だ」と言われていたが、今は「harness が製品だ」ということか？
ハーネスがこれほど重要であるなら、以降の勘定もさらに細かくすべきではないでしょうか？
誰かが、既存のベンチマークに「harness 税」を追加する必要があると指摘しました。特に、ツールの呼び出しと再試行がループに入ると、この税が線形に増加しないことを考慮すると重要です。
言い換えれば、将来的なエージェントコンテストの前半は「実行できるかどうか」が勝負だが、後半は「同じことをどれだけ効率よく行えるか」が勝負になる——そのコスト削減の鍵はモデルではなく、ハーネスにある。
エージェントを実行している过程中、似たような体験をしたことはありますか？コメント欄でご意見をお聞かせください。
本文は微信公众号「機械の心」（ID：almosthuman2014）より、著者：機械の心