Opus よりも Fable を安く利用する方法

私たちは Opus 4.8 を Fable 5 に置き換えたところ、Devin の請求額が下がりました。

Fable 5 はトークンあたりのコストが Opus 4.8 の 2 倍ですが、新しい Fusion アーキテクチャを使用して FrontierCode 1.1 で両方のモデルを実行したところ、Fable の方がコストが低くなりました。当然ながら、スコアも高くなりました。この記事では、その理由と、エージェントの作業に対する価格設定への影響について説明します。

はじめに

コードエージェントを運用する人なら誰でも、強力なモデルほど良い結果が得られる一方で、コストがかかることを知っています。

Devin Fusion を導入した際、私たちは脱出方法を示しました。最先端モデルを指揮役にし、より安価で高速なサイドキックに委任させることで、最先端レベルのパフォーマンスを 35% 低いコストで実現する方法です。

しかし、リードモデルがほとんどの作業を委任した場合、そのトークンあたりの価格が依然として請求額を支配するのでしょうか？ Fable 5 は Opus 4.8 よりもトークンあたり 2 倍のコストがかかるため、Fable 主導のエージェントのコストは高くなるはずです。これを確かめるために、FrontierCode 1.1 で 4 つの構成にわたって 3,000 回の評価セッションを実行しました。Fable と Opus がリード役を務め、それぞれに同じ安価なサイドキックを使用した場合と使用しない場合です。

純粋な実行は直感通りに動作します。Fable は Opus を上回るスコア (60.8 vs 55.4) を獲得し、コストも高くなります。優れたモデル、大きな請求額。

サイドキックを有効にした実行では、状況が興味深くなります。

同じサイドキックを使用した場合、コストの順位が逆転します。Fable + Sidekick は Opus + Sidekick よりもコストが低く ($1.86 vs $2.04)、スコアも高くなっています (60.7 vs 54.6)。 純粋な Fable と比較すると、Fable + Sidekick はコストを 54% 削減し、スコアはほぼ変わりません。

トークンあたり 2 倍のプレミアムは注目すべき間違った数値であることが判明しました。エージェントのコストは、リードモデルが実行するターン数、引きずるコンテキストの量、そして何よりも、自分自身で行わないと判断する内容によって決まります。その違いは管理スタイルにあります。Opus はインターンに細かく指示する管理職のようなもので、Fable は有能なエンジニアに任せる管理職です。

セットアップ

Fusion のサイドキックアーキテクチャがどのように機能するかを簡単におさらいします。リードエージェントはセッションを所有し、ユーザーと対話し、計画を立て、作業をレビューし、コミットします。また、タスクを委任するための永続的な サイドキック サブエージェントも持っています。リードは平易な言葉でハンドオフブリーフを作成し、はるかに安価なモデルを搭載したサブエージェントが自身のコンテキスト内でそれを実行し、報告します。リードは結果をレビューし、次のアクションを決定します。

コストがどこに行くのかを調べるために、2 つのことを行いました。まず、3,000 セッションすべての LLM 呼び出しを解析しました。どのモデルが話していたか、どのツールを呼び出したか、読み書きしたトークンの数、各呼び出しのコストです。次に、40 のタスクを詳しく調べました。Fable が劇的に安かったタスク、Opus が安かったタスク、そして中間からランダムにサンプリングしたタスクです。それぞれについて、Fable 主導の実行と Opus 主導の実行を並べて分析し、軌跡を調べてどこにコストがかかっているかを観察しました。

エージェントのコスト

実験におけるリードとサイドキックのコスト分割は以下の通りです。

Fable は Opus よりもサイドキックに多く費やしています (実行あたり $0.27 多い)。しかし、自分自身 には $0.45 少なく費やしています。Fable のリードは 1 回の実行あたり 11.5 ターン (Opus は 26.5 ターン) で、出力トークンは 3 分の 1 (6.1k vs 19.0k)、入力トークンも 3 分の 1 です。Fable はトークンあたりのコストが大幅に高いものの、コンテキスト管理とターン数で勝っています。

Fable のトークン節約は、作業を完全に回避することから生まれます。興味深いことに、Fable 主導の実行の 81% では、リードがコード編集を 1 回も行いません。Opus の場合、それが当てはまるのは実行の 24% のみです。Fable 主導の実行の 13% では、リードがリポジトリファイルを一度も読んでいません。

インターンとマイクロマネージャー vs エンジニアとマネージャー

この差が興味深い理由は次の通りです。両方のリードが同じ回数 (実行あたり約 3 回) 委任しています。呼び出しごとのログは、Fable が単により多く委任しているという簡単な説明を否定しています。異なるのは、いつ、何を 委任するかです。Fable の最初のハンドオフは早い段階で行われます。Opus は、長時間の単独探索と実装を行った後、遅い段階で委任することがよくあります。その時点では、設計上の決定はすでに行われ、重要なファイルはコンテキスト内にあり、高コストの作業は終わっています。

典型的な Fable 主導の実行では、リポジトリに対していくつかの偵察アクションを実行し、実装、テスト、リントのループ全体を委任する仕様レベルのブリーフを 1 つ作成します。次に、git show で差分を確認し、コミットします。

典型的な Opus 主導の実行では、20 ～ 45 ターンの単独探索、設計、実装を行い、最後に機械的な後処理のために 1 回のハンドオフを行います。

Fable のセッションでの 最初のアクション がハンドオフである場合もあります。同じタスクで、2 つのリードは次のように開始しました。

明らかな修正は Opus にもっと探索を委任させることですが、その動作を強制するとパフォーマンスが低下する傾向があります。調査を安全に委任できる場合と、自分で行う必要がある場合を見極めること自体が判断力です。委任を強制されたモデルはその判断力を獲得できず、間違ったものを委任するだけです。

各モデルの管理スタイルは、ハンドオフのブリーフ自体にも現れます。Opus が実装を委任するときは指示を出し、Fable は設計ドキュメントを作成します。

委任はコストを移動させるだけでなく、作業の質も変えます。上記のハッシュタスクはその顕著な例です。タスク仕様では、ハッシュ関数がポインタの長さに対して O(1) であることが要求されていました。Opus は手動で実装し、その要件をどこにも書き留めませんでした。途中で制約を忘れ、線形時間の実装を出荷し、スコアは 25 でした。対照的に、Fable は高レベルの制約を使用して委任しました。そのブリーフには「operator() はポインタの長さに対して O(1) でなければなりません。完全なトークンスキャンは禁止」とありました。サイドキックはこれを正常に実装し、スコアは 94 でした。

このパターンはタスク全体に一般化されることがわかりました。Fable のハンドオフは制約、エッジケース、「完了」の定義を列挙し、自身の労力を節約しながら、サイドキックが安価かつ正確に実装を完了できるようにしました。

ハンドオフ後

残りの半分は、リードエージェントがサイドキックから返ってきた作業をどう処理するかです。両方のリードは、同じ安価なチェック (git diff/git show の 2 ～ 3 回の呼び出し) を実行することがよくあります。しかし Opus はそこで止まりません。サイドキックのファイルを自身のコンテキストに引き込む頻度が 2 倍高く、リード価格で修正編集を行う頻度が 4 倍高くなります。極端な場合、サイドキックの作業を元に戻して手動で書き直しました。

Opus の不信感は正確性も向上させません。いくつかの評価タスクでは、Fable の 1 回の差分レビューで実際のサイドキックのバグを発見し、Opus が頻繁に頼るリードレベルの書き換えではなく、別の安価なハンドオフを選択しました。

委任が役に立たない場合

Fable の委任戦略は普遍的に有用というわけではありません。タスクに委任可能なコンポーネントがない場合に失敗します。次のようなタスクは分解が難しいように見えました。

• 意思決定から出荷までの間に委任するものがない、リードモデルのターンがわずかしか含まれていない短いタスク。
• 根本原因の追求が長い判断の連続であるシリアルデバッグタスク。ここでは、蓄積されたコンテキスト こそが 作業です。

注目すべきは、これらのタスクでは Fable がほとんど委任しないことです。優れたブリーフを書くのと同じ判断力が、いつ書くべきでないかも知っています。しかし、タスクにハンドオフする価値のあるものが何もない場合、委任はコストに対しててこ入れできません。

本番環境では、Fusion は別のレイヤーでこれを処理します。委任はどの作業が高価なモデルに残るかを制御し、ルーティングは高価なモデルがそもそも関与するかどうかを決定します。

まとめ

この実験を始めたときは、Fable の 2 倍のプレミアムがコストをどれだけ増加させるかを測定することを期待していました。驚いたことに、Fable の効果的な委任により全体的なコストが実際に減少しました。実装を詳細に指定するのではなく制約と結果を指定し、自分で修正する代わりにフィードバックを与え、ほとんどの場合コードにまったく触れませんでした。これらは優れたマネージャーの習慣です。

サイドキックモデルがより安く、より良くなるにつれて、より多くの作業をそれらに任せることができるようになります。フロンティア価格に値するものとして残るのは判断力です。何を構築するか、何を制約するか、誰がそれを書くべきか。