9つのコーディングハーネス対あなたのラップトップ

コーディングハーネスがAPIコールをローカルモデルに置き換えることを検討したことがあるなら、おそらくがっかりしたことでしょう。あなたは素早くllama-benchを実行し、毎秒Xトークンを見ることができると思ったでしょう。そのベンチマークは、これらのハーネスを実際に使用した時の感覚を教えてくれません。開発体験は非常にばらつきがあります。応答を見る前に何分も待ったかもしれません。うまくいっていたのに、途中で停止し始めたかもしれません。「このプリフィルは何だ、私の時間をすべて奪っているのか？」それはあなたのせいではありません。ほとんどのコーディングハーネスは、ローカルモデルを念頭に置いて設計されていません。これは、他のチームの優れた仕事に対する非難ではありません。私は、データセンターをlocalhostに置き換えた場合に何が起こるかを確実に測定しようとしています。問題に対してある程度の不適切なツールが予想されます。塩を加えてください：私は、Apple Silicon上のQwen 3.8 27Bに特化して最適化されたコーディングハーネスであるchadをいじっていました。ラップトップの物理学ほとんどのハーネスは、3つの方法でlocalhostに反抗します。大きなシステムプロンプトとツールスキーマ。あなたのラップトップが毎秒90トークンで読み込み、約10トークンで書き込むと仮定しましょう。これらは、コーディングハーネスの各ループのプリフィルと生成の部分を表します。これらの速度では、プロンプトの1,000トークンごとに、モデルが書き込みを開始する前にカーソルを見つめる約11秒に相当します。LLMが作業を行う前に、システムプロンプト全体とロードされたツールスキーマを読み込みます。piハーネスでは、この組み合わせはQwen 3.8 27Bで2,008トークンでしたが、Opencodeでは合計18,046トークンでした。プリフィルレートが平均10kトークン/秒のデータセンターGPUを持っている場合、大きな違いは気づかないでしょう。これは0.2秒対1.8秒に縮小されます。ラップトップでは？それは、測定された22秒と226秒の違いです。耐えられない！より小さなコンテキストウィンドウ。LLMがシステムプロンプトの読み込みを終えた後、作業を行うためのメモリ内に有限のコンテキストウィンドウが残ります。それはあなたが思っているよりも小さく、あなたのハーネスはその一部を既に消費しています。コンテキストの量は、開始時のメモリ量とモデルの重みのサイズによって異なります。ここには多くの変数がありますが、32,000トークンは、合理的なラップトップで合理的なモデルを使用した場合に残るスペースとして妥当な推測です。その32,000トークンの予算のうち、piハーネスのためにどれだけ残っていますか？94% - 管理可能に見えます。Opencode？既に18,046トークンが消費されているため、実際に作業するためのコンテキストは44%しか残っていません。サイドリクエストの習慣。従来のローカルクライアント/リモートサーバーパターンでは、ハーネスはデータセンターサーバーに好きなだけサイドリクエストを行うことができます。あなたのラップトップはクライアントでもサーバーでもあります。最良の場合、それらのサイドリクエストはローカルモデルをキューに入れ、待機させます。最悪の場合、それらは繰り返し長いプリフィルを引き起こします。24のタスクで、opencodeは33（セッションタイトルと概要）、crushは51、dshは24を起動しました。ほぼすべてのリクエストがエージェントのターンと重複していました。モデルは、opencodeとcrushでそれぞれ壁時計時間の125%と114%の間、「ビジー」状態でした。1つのGPUで2つのリクエストが同時に実行されていました。ハーネスの結果私は9つのハーネスを、それぞれ独自の自動承認モードで、同一の1文のプロンプトを使用して、一連の8つのExercism演習にかけました。各タスクは、llama.cpp（ビルド10470）で提供されるQwen 3.8 27Bモデルの3ビット量子化を備えた同一のM4 MacBook Pro（24GB、macOS 26.6.2）を利用しました。同じllama-serverが各ハーネスによって共有され、共通のプロキシがQwen（temperature=1.0、top_k=20、top_p=0.95、min_p=0.05）に推奨されるサンプリングレジームを強制しました。各セッションは、4つのスロットにまたがって提供される同じ32,768のユニファイドキャッシュを持っていました。以下に報告されるすべての数値は、プロキシを通じて読み取られたllama-server自身の会計であり、ハーネスの自己報告ではありません。ただし、*でマークされた2行（チャドのインプロセスMLXエンジン、サーバーを観測できないため、チャド自身のプリフィルトレースから同じ定義で取得）は例外です。最初のトークンまでの待機時間：システムプロンプト、ツールスキーマ、および最初のリクエストに対するサーバーのプリフィル時間です。待機時間/後続ターン：最初のターン以降の同じ一時停止で、サイドリクエストは除外されます。キャッシュ再利用：後続ターンの各部分がプレフィックスキャッシュから提供される割合です。経験トークン/秒：プリフィルとツールの時間を含めた、タスク全体の生成トークンを壁時計時間で割ったものです。夜間では最大50%のばらつきがあるため、アーム間の差は発見ではありません。パス：Exercismタスクのゲートです。これらは単純なPythonタスクなので、ランキングとして解釈しないでください。Tは1,200秒のキャップでのタイムアウトを示します。ハーネスバージョンツール税：ターン-1プロンプト（トークン）最初のターンまでの待機時間、ターン1待機時間/後続ターン（中央値・90パーセンタイル）キャッシュ再利用経験トークン/秒パス（ゲート）mini-swe-agent 2.4.6 1 1,171 12.2秒 3.6秒・21秒 96% 8.0 11/24 (14 T) pi 0.80.3 4 2,008 21.6秒 1.3秒・22秒 99% 8.1 19/24 (7 T) cline 3.0.60–61 26 5,876 64.1秒 9.9秒・52秒 94% 7.3 17/24 codex 0.151.0 10 7,804 87.8秒 9.6秒・28秒 94% 6.9 19/24 (5 T) dsh 0.1.1-rc.2 25 8,052 94.4秒 2.2秒・34秒 99% 7.2 18/24 goose 1.50.0 18 9,617 110.3秒 1.0秒・22秒 100% 8.0 22/24 (3 T) crush 0.92.0 26 16,263 199.8秒 1.8秒・40秒 100% 5.8 18/24 (8 T) opencode 1.17.12 10 18,046 225.7秒 4.6秒・44秒 99% 5.7 15/24 (13 T) chad (llama.cpp) 2.0.3 5 2,563 25.6秒 0.8秒・19秒 99% 7.9 24/24 chad (MLX, serial) * 2.0.3 5 2,566 4.7秒 1.0秒・19秒 99% 12.4 21/24 (3 T) chad (MLX, dflash2) * 2.0.3 5 2,562 4.6秒 0.9秒・36秒 99% 17.4 22/24 (3 T) 私の経験では、ハーネスは3つのグループに分けられました。[ ] 軽量で安定している（pi、mini-swe-agent、chad）。これらのハーネスは、システムプロンプトが簡潔で、キャッシュ再利用率が96〜99%です。データセンターまたはローカルモデルのバックエンドで、ほぼそのまま動作します。唯一の注意点は、mini-swe-agentはExercismタスクの11/24しかパスせず、タイムアウトが最も多かったことです。重いが規律がある（dsh、cline、codex、goose）。長いシステムプロンプトまたは多数のツールスキーマの組み合わせ効果。それらのプレフィックスはバイト単位で安定しているため、一度開始すると許容範囲内になります。（gooseは1.50.0でこのグループを獲得しました。以前のリリースでは、毎ターン1分解像度のタイムスタンプが最初のユーザーメッセージに再レンダリングされていました。これにより、キャッシュ再利用率が78%に低下しました。）開始が重い（crush、opencode）。アクティビティが表示される前に3〜4分待つことになります。chadのケースこれらのハーネスはどれもひどく設計されていません。Opencodeの18kシステムプロンプトは、APIの背後で展開される最先端モデルに役立つためです。crushの26のツールスキーマは、200kのコンテキストがあり、プリフィルが瞬時であれば問題ありません。これらの選択はすべて、プリフィルが事実上無料である環境で行われました。ローカル速度では、これらすべてが崩壊します。