FrontierHarness Eval - 9 harnesses, same model, cost varies 17x
Show HN: FrontierHarness Eval – 9 harness, same model, cost per pass varies 17x
FrontierHarness Evalは、同一モデルと同一ランタイムを使用し、同一のソフトウェアエンジニアリングタスクを9種類のハーネスで評価する包括的なベンチマークです。全360回の試行はコールドスタートから開始し、キャッシュの偏りを排除。品質リーダーはCodex（成功率66.7%）、コストリーダーはExo Harness（タスクあたり$1.05）で、コスト差は最大17倍に達します。開発者はこの結果を参考に、品質とコストのバランスに優れたハーネスを選択できます。
同一モデル、同一タスクで、ハーネスの選択によってコストが最大17倍も変わる——これは、開発者がツール選びで大きな最適化の余地を持っていることを示しています。
HNでの議論
46- vidarh
Kimi に対してテストすることは、数値を大幅に歪める可能性があります。Kimi には、例えば Claude や GPT にはない、特別な動作を必要とする癖がいくつかあります。「変な」モデルで動作させることを前提に作られたハーネスは、Kimi がツール呼び出しループに陥りがちな傾向などに対処する必要があります。主に Anthropic のモデルを扱うように作られたハーネスは、そのような対処は不要です。ブログで「Kimi Code にホームアドバンテージはない」と主張するのは、危うい仮定のように思えます。私は最新の Kimi Code をあまり深く調べていませんが、以前の Kimi CLI には、明らかにその動作を回避することに特化したツールがいくつか含まれていました。彼らのチェックポイントと「dmail」メカニズムを自分のハーネスにコピーしたところ、Kimi でのパフォーマンスは劇的に向上しましたが、Anthropic のモデルに対してはまったく違いがありませんでした。だからといって、このデータが無価値というわけではありません。Clade Code を Kimi に対して使うべきでないのは明らかです。しかし、その有用性は大幅に制限されます。
- joshheitzman
コストが中央値としてのみ提供されているのを見て、がっかりしました。プロバイダーはすべてのタスクに対して請求を行い、平均値にタスク数を掛ければ合計に戻せます。しかし、中央値ではそれが不可能であり、中央値は平均値よりも低い可能性が高いため、実際のコストを過小評価していると思います。
- nijave
システムプロンプトを制御して試すのも興味深いでしょう。ただし、明らかにハーネスが提供するものと、モデルがその使用方法について受け取る指示との間には、ある程度の関連性があります。
- nsingh2
Pi のようなものを含めることに関して一つ問題があるのは、それが意図的に最小限の構成であることです。Pi を何らかの基本的なカスタム拡張機能（サブエージェント、チェックリストなど）なしで使う人はいないと思うので、このベンチマークは現実的なセットアップを代表していない可能性があります。また、アブレーション試験のようなものも見てみたいです。例えば、Codex のどの部分がパフォーマンスに最も貢献しているのか、そしてそれらを Pi のようなものでより最小限に再現できるのか、などです。
- markbao
これは素晴らしい。人々はいつもハーネスの重要性を語りますが、ハーネスのベンチマークはほとんどありません。同じくコメントしている方に同意します。「ハーネス×モデル」の比較が必要です。人々はいつも Cursor のハーネスには何か秘密のソースがあると言いますが、それがどう比較されるのか見てみたいです。これを作って、実際のギャップを埋めてくれてありがとうございます！