Fable vs Opus：委派架构如何让更贵的模型更省钱

Fable 像帶著資深工程師的經理，早早交派、寫清楚規格、少親自動手；Opus 則像帶實習生的微觀管理者。本文源自 Joon Lee X 文章，用 3,000 場評測拆解背後的成本結構。

（前情提要：Anthropic 推出「Claude for Small Business」：瞄準中小企業 AI 自動化工作，幫你催發票、算薪水..）

（背景補充：Anthropic 要求實名 KYC 驗證！Claude 部分功能將需上傳身分證件，合規壓力擴大）

我們把 Opus 4.8 換成 Fable 5，而 Devin 的帳單反而降低了。

Fable 5 每 token 的成本是 Opus 4.8 的兩倍。但當我們用全新的 Fusion 架構，在 FrontierCode 1.1 上同時跑這兩個模型時，Fable 反而更便宜。不意外地，它的分數也更高。這篇文章會解釋為什麼，以及這對「為 agentic 工作定價」意味著什麼。

引言 每個跑程式 agent 的人都知道，更強的模型會給你更好的結果，但你得吞下成本。

當我們推出 Devin Fusion 時，我們展示了一條出路：讓一個前沿模型坐鎮指揮，讓它把工作委派給一個更便宜、更快的副手，於是你能以低 35% 的成本，獲得前沿等級的表現。

但一旦主導模型把大部分工作都委派出去，它每 token 的單價還會主宰整張帳單嗎?Fable 5 每 token 的成本比 Opus 4.8 貴兩倍，所以由 Fable 主導的 agent 照理說應該更貴。為了找出答案，我們在 FrontierCode 1.1 上跑了 3，000 場評測工作階段，橫跨四種配置：Fable 與 Opus 各自坐上主導席，並各自在「有」與「沒有」同一個便宜副手的情況下執行。

純粹的執行(pure runs)表現完全如直覺所料：Fable 的分數勝過 Opus(60.8 對 55.4)，成本也更高。更好的模型，更大的帳單。

有副手加持的執行，才是事情變得有趣的地方。

在給定同一個副手的情況下，成本排序反轉了：Fable + 副手比 Opus + 副手更便宜($1.86 對 $2.04)，分數卻更高(60.7 對 54.6)。和純粹的 Fable 相比，Fable + 副手把成本砍掉 54%，分數卻幾乎沒變。

配置 分數 每次執行成本(平均) Fable 5(low)+ 副手 60.7 $1.86 Opus 4.8(medium)+ 副手 54.6 $2.04 Fable 5(low) 60.8 $4.03 Opus 4.8(medium) 55.4 $3.06 結果證明，「每 token 貴兩倍」是個看錯了的數字。一個 agent 的成本，主要取決於主導模型走了多少回合、拖著多少上下文一起走，以及最重要的——它決定「不」自己做哪些事。差別歸結到管理風格：Opus 表現得像個帶著實習生的微觀管理者；Fable 則像個帶著能幹工程師的經理。

實驗設定 快速複習一下 Fusion 的副手架構如何運作。主導 agent 擁有整個工作階段：它和使用者對話、規劃、審查工作，並提交(commit)。它還有一個常駐的副手子 agent 用來委派任務。主導模型用白話寫下一份交接簡報，而由一個便宜得多的模型驅動的子 agent，在它自己的上下文裡執行，並回報結果。主導模型審查結果，決定接下來怎麼做。

為了找出成本流向哪裡，我們做了兩件事。第一，我們解析了全部 3，000 場工作階段裡的每一次 LLM 呼叫：是哪個模型在說話、它呼叫了什麼工具、讀寫了多少 token，以及每次呼叫花了多少錢。第二，我們挑了 40 個任務做更近距離的觀察：Fable 明顯更便宜的那些、Opus 明顯更便宜的那些，以及另一批來自中間地帶的隨機樣本。對每一個，我們把 Fable 主導的執行和 Opus 主導的執行並排分析，檢視它們的軌跡，觀察錢花到哪裡去了。

一個 agent 的成本 以下是在我們的實驗中，成本如何在主導模型與副手之間分配： 主導 $ 副手 $ 每次總成本 $ 主導每次回合數 主導輸入 token(累計) Fable + 副手 $1.28 $0.58 $1.86 11.5 545k tok Opus + 副手 $1.73 $0.31 $2.04 26.5 1，679k tok Fable 花在副手上的錢比 Opus 多——每次執行多花 $0.27。但它花在自己身上的錢少了 $0.45。Fable 的主導每次執行走 11.5 個回合，對比 Opus 的 26.5 個；寫出的 output token 只有三分之一(6.1k 對 19.0k)，消耗的 input token 也只有三分之一。Fable 每 token 明顯更貴，卻在上下文管理和回合數上勝出。

Fable 的 token 節省，來自於它乾脆地避開了工作。有趣的是，在 81% 由 Fable 主導的執行裡，主導模型從頭到尾沒有做過任何一次程式碼編輯。對 Opus 來說，只有 24% 的執行是如此。在 13% 由 Fable 主導的執行裡，主導模型甚至從未親自讀取過任何一個 repo 檔案。

帶實習生的微觀管理者 vs 帶資深工程師的經理 讓這個落差變得有趣的地方在於：兩個主導模型委派的次數一樣多，每次執行大約 3 次交接。逐次呼叫的日誌，推翻了「Fable 只是單純委派得比較多」這個簡單解釋。真正不同的，是它們「何時」委派、「委派什麼」。Fable 的第一次交接來得很早。

Opus 則常常很晚才委派，在一長段獨自探索與實作之後；到那時候，設計決策都已做完、重要檔案都已進了它的上下文，昂貴的工作也已經做完了。

一場典型的、由 Fable 主導的執行，會先對 repo 做幾個偵察動作，然後寫一份規格等級的簡報，把整個「實作 + 測試 + lint」的迴圈一次委派出去。接著一個 git show 來審查 diff，然後提交。

一場典型的、由 Opus 主導的執行，則會歷經...