同じモデルでもハーネス次第でコスト5倍、ClaudeモデルにClaude Codeは不要かもしれない
HarnessTax: How Much Does the Harness Matter for Coding Agents?
UC BerkeleyとArenaの研究チームが、7モデル×3ハーネス（Claude Code、Codex CLI、Pi）の21組をSWE-bench LiteとTerminal-Bench 2.0で評価。ハーネス選択は成功率にほとんど影響しない一方、コストは最大5倍変動することが判明した。Piは4つのツールだけでParetoフロンティアに到達し、12比較中9比較でプロバイダー純正以外のハーネスが最高成功率を記録。デフォルトのハーネスをそのまま使うことで生じる「ハーネスタックス」に警鐘を鳴らす。
同じモデルが、最大5倍のコストで同程度の成功率を達成できる。
HNでの議論
84- nojs
ハーネスのベンチマークはもっとちゃんとしたものが必要だ。主要なハーネスをすべてのオープンソースモデルに対してベンチマークした信頼できる情報源はないようだ。
Piに関する議論がいつもコスト/トークン数ばかりを指標にしているのも残念だ。Piは驚くほどトークン効率が良いが、トークン数を気にしないならopencodeや他のものと比べてどうなのか？
自分の経験では、ハーネスは主にツール呼び出しの失敗や不正な編集などを防ぐための磨き込みであり、全体的な「知能」にはそれほど違いをもたらさない。ただ、opencodeはスレッドごとに強制的に追加コンテキストを通すため、素のPiよりも愚かなエラーに対して少し堅牢なようだ。
- lukax
もっと重要なのは、対象モデルがファインチューニングされたツールを使うことだ。
例えばClaudeモデルでファイルを編集するならEdit(file_path, old_string, new_string, replace_all)を使うべきだが、GPTモデルならapply_patch_call(patch)を使うべきだ（patchは独自文法のカスタムパッチ文字列）。
新しいモデルはネイティブのハーネスツール呼び出しは得意だが、デフォルトツールに似たカスタムツールは苦手になっているようだ。
https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/
- Yashjain413
ツールがやることすべて——実行ループやコンテキスト管理からフィードバックまで——を見ると、これは本当に重要だと思う。ハーネスは基本的に根本的な真実の源だ。
コーディングエージェントで気づいたのは、単純なタスクならかなり単純なハーネスでも扱えることが多いということだ。しかし隠れたコストは本当にコンテキスト周りにある。面白いことに、2つの異なるハーネスが同程度のモデル呼び出し回数でも、消費するコンテキスト量は大きく異なることがある。
最近、Claude CodeとPiを比較した論文を見かけて、この点に触れていたと思う。より多くのコンテキスト、より多くのツール、焦点を絞ったコンテキスト、より単純なループ——これらすべてが、モデル呼び出し回数が似ていても、コストとパフォーマンスに大きく違いをもたらしうる。
- Supermancho
ここでの「ハーネス」という用語が「エージェント」という用語と混同されて使われているのは気がかりだ。それはさておき、重要な要素はたくさんある。「ハーネス」のコンテキスト、実行パターン（並列か逐次か）、他のモデルに委譲する能力などだ。
最適なハーネスは並行実行＋サブエージェントを使い、1つのモデルに縛られない。これらの戦術によって、ネイティブのエージェントコンテキスト（指示）に関係なく、コストとパフォーマンスは大きく影響を受ける。この種の単一ハーネス分析は浅く、誤解を招く。ただし「プロバイダー固有の最適化が最良の組み合わせを保証するわけではない」という発見は、測り方にもよるが、おそらく正しい。
これは出発点だ。
- corv
自分の発見はこの研究と一致している。
コーディングハーネスを持つことは重要だが、ハーネス間の違いは誇張されている。
個人的には、OpenCodeをPydantic-AIの薄いラッパーに置き換えた。Pi-AgentのPython版に相当するもので、Hermes経由のヘッドレス利用向けだ。
どれも仕事はこなすだろう——ただ、アクセス制御のために分離しておくのが好みなだけだ。
ハーネスの表面積を極小に保つと、自分の理解を保ち、好みのワークフローに楽に適応できるという副次的な利点もあった。