如何選擇適合的 Claude 模型：Fable 5.2、Opus 5.5、Sonnet 5.5 與 Haiku 5.5 的任務、成本與效率指南

模型效能與成本概覽

選 Claude 模型時，主要看兩件事：能力和成本。目前所有現行模型都支援工具使用與圖片輸入。

Fable 5.2 的輸出速度比 Fable 5.1 快最多 30%。Opus 5.5 在 SWE-bench Pro 基準測試中，不同努力設定（effort setting）的表現與成本各不相同。中等努力設定下，Opus 5.5 的得分比高努力設定低約 2.5 分，成本只有後者的約 70%。低努力設定下，得分比高努力設定低約 8 分，成本約為三分之一。若選超高努力設定（xhigh），得分比高努力設定高約 1.4 分，成本則是高努力設定的 2.5 倍。

Sonnet 5.5 的運行速度比 Sonnet 5 快 30%。在 SWE-bench Pro 的同一子集中，若先以低努力設定執行 Opus 5.5，再把失敗的任務改用高努力設定重跑，可通過約 97% 的任務，每項任務成本約 0.17 美元；相比之下，全部任務都用高努力設定執行，通過率為 95.3%，每項任務成本為 0.29 美元。

定價機制與快取讀取

Opus 5.5 與 Fable 5.2 在 Claude API 上都提供快速模式（fast mode），輸出速度較高，但定價有溢價。快取讀取（cache read）費用方面，Opus 5.5 每百萬個 token 收費 0.20 美元，Fable 5.2 相同，也是每百萬個 token 0.20 美元。Sonnet 5.5 的快取讀取費用則是每百萬個 token 0.10 美元。

以 Opus 5.5 的任務成本為例，上下文長度為 150K tokens 時，單次回合的快取讀取成本約 0.03 美元；上下文長度為 20K tokens 時，成本約 0.004 美元。Haiku 5.5 是唯一一個 token 價格會隨提示詞（prompt）長度變動的模型。

多代理協作與架構選擇

工作量超過單一上下文視窗時，可以採用多代理協作模式。做法是由一個頂級模型主導，把任務拆開，同時交給多個較便宜的代理處理，最後再合併回傳的結果。前文提到的子代理（Subagents）負責處理次要任務，由一個主要模型維持對話線程。Claude Managed Agents 的多代理協調功能，提供一個協調代理和一組工作代理。

以 Opus 5.5 當主導模型，搭配最多 25 個 Sonnet 5.5 工作代理，成本比單獨使用預設努力設定的 Opus 5.5 低約三分之一，得分則與單獨使用 Opus 5.5 大致相同。不過，如果任務只是單一的依賴步驟鏈，或工作量放得進單一上下文視窗，就不該用這個模式，因為規劃與合併的成本會超過省下的金額。這個模式適合處理大於單一上下文視窗的工作。

技術實作與注意事項

Opus 5.5 與 Fable 5.2 都具備「始終思考」（always think）的特性。Fable 5.2 把保留思考（preserved thinking）功能擴展到所有 API 帳戶。使用 Fable 5.2 時，只要思考區塊之前的內容有任何變更，包括系統提示詞、工具或較早的訊息，API 就會拒絕請求並回傳 400 錯誤，除非使用者選擇放棄受影響的思考內容。

如果是透過 Claude Code、Claude Agent SDK 或 Claude Managed Agents 建構請求，不需要做任何變更。如果是自行編寫程式碼並編輯歷史記錄，則應維持追加寫入（append-only）模式，並在切換前先測試。