Claude 模型怎麼選，是不少開發者與團隊導入時最常卡關的問題。根據 Claude 官方部落格發布最新的選型指南，建議預設從 Opus 5.5 搭配 medium effort 起步，再依任務難度降級到 Sonnet 5.5、Haiku 5.5，或升級到 Fable 5.2。
這篇指南將「該用哪個模型、effort 開多高、什麼時候混用、換模型前要檢查什麼」串成一套可以照著做的決策流程。您可以以下依序整理選用表、價格規格、成本權衡、混用技巧與遷移注意事項。
官方建議的預設組合是 Opus 5.5 加上 medium effort
官方指南目前列出四款一般可用的模型與一款受限模型：
- Claude Haiku 5.5：定位在高流量、成本敏感的任務。
- Claude Sonnet 5.5：速度快、能力足夠，適合範圍明確的工作。
- Claude Opus 5.5：複雜程式設計與知識工作的主力模型，也是 Claude Code 的預設模型。
- Claude Fable 5.2：針對最具企圖心、開放式的技術工作，例如困難的程式、金融與科學專案。
- Claude Mythos 5.2：最強的模型，用於網路安全與生命科學研究，需要透過驗證計畫才能取得。
降級、升級與調整 effort 的三條原則
官方的核心建議有幾個原則：第一，預設起點是 Opus 5.5 搭配 medium；第二，範圍明確的日常工作（例如修 bug、依規格開發功能）降到 Sonnet 5.5，分類、路由、抽取這類大量簡單任務降到 Haiku 5.5；第三，最困難的程式、金融、科學專案，或 Opus 5.5 開到 high 仍不夠用時，升級到 Fable 5.2，長時間無人值守的任務也適合用它。
其中最值得記住的是「先調 effort，再換模型」。根據官方說明，effort 是比模型更細緻的成本與能力調節器，較高的 effort 能讓模型思考更久、多呼叫工具並自我檢查。但也是會有一些負面影響，如增加延遲，而且補不上模型本身缺乏的知識或技能，另外，超過 high 再加一級時，成本可能已經接近直接換更大的模型，需要多次嘗試。
依任務挑模型，官方給了一張起手式對照表
官方把常見工作拆成多種情境，並為每一種標出建議的起始模型與 effort，方便團隊直接拿來當第一輪測試的設定：
| 任務類型 | 起始模型 | 起始 effort |
|---|---|---|
| 日常工程、除錯、多 PR 功能開發 | Opus 5.5 | medium，再試 high |
| 分類、路由、標記、大量抽取 | Haiku 5.5 | medium |
| 搜尋檔案、讀 log、摘要的子代理 | Haiku 5.5 或 Sonnet 5.5 | 模型預設 |
| 聊天與互動式工作階段 | Sonnet 5.5（簡單大量聊天可用 Haiku 5.5） | low 或 medium |
| 範圍明確的程式工作（修 bug、規格驅動） | Sonnet 5.5 | medium，困難時 high |
| 日常文件、投影片、試算表 | Sonnet 5.5 | high（Claude Code 中為 medium） |
| 重複執行的代理任務（調查、審查、起草） | Sonnet 5.5 | medium |
| 電腦操作與視覺密集流程 | Opus 5.5 | medium |
| 大型重構、遷移、架構規劃、帶領多個子代理 | Fable 5.2 | medium，再試 high |
| 深度研究、科學或量化分析 | Fable 5.2 | medium，再試 high |
| 不確定時 | Opus 5.5 | medium |
簡單來說，可以從這張表歸納出分工邏輯：做錯了容易被發現、量又大的工作交給 Haiku 5.5 或 Sonnet 5.5，需要視覺理解與電腦操作的流程交給 Opus 5.5，牽涉大範圍規劃與深度研究的工作才動用 Fable 5.2。實際導入時，只要先判斷手上的任務落在哪一列，就能很快找到合理的起點。
四款模型的價格、規格比較
以下是官方列出的 API 標價與規格，價格單位為每百萬 tokens：
| 項目 | Haiku 5.5 | Sonnet 5.5 | Opus 5.5 | Fable 5.2 |
|---|---|---|---|---|
| 定位 | 高流量、低成本 | 快速、能力足夠 | 日常主力 | 最具企圖心的技術工作 |
| 相對延遲 | 最快 | 快 | 中等 | 中等 |
| 輸入 / 輸出價格 | $0.10 / $0.50（100K 以內） $0.50 / $2.50（超過 100K） | $2 / $10 | $4 / $20 | $8 / $40 |
| 快取讀取價格 | $0.01（100K 以內） $0.05（超過 100K） | $0.10 | $0.20 | $0.20 |
| 上下文視窗 | 1M | 1M | 1M | 1M |
| 最大輸出 | 128K | 128K | 128K | 128K |
| API 預設 effort | medium | high（Claude Code 為 medium） | medium | high（Claude Code 為 medium） |
| Fast mode | 否 | 否 | 是 | 是 |
四款模型的上下文視窗與最大輸出完全相同，差別只在價格、速度與能力；Haiku 5.5 是唯一依提示長度分級計價的模型，短提示時的輸入價約為 Sonnet 5.5 的二十分之一，但如果每次呼叫都是長提示，就應該比較「每完成一個任務的成本」，而不是只看標價；Fable 5.2 的 token 單價是 Opus 5.5 的兩倍，不過快取讀取價格相同；Fast mode 目前只有 Opus 5.5 與 Fable 5.2 提供。
單價高不等於單任務更貴，所以要先調 effort 再換模型
官方用基準測試說明每完成任務成本才是重點
標價只是成本的一半，真正該看的是完成一個任務總共花了多少。官方舉了幾個例子：在 Terminal-Bench 3.0 上，Opus 5.5 以 high 取得 58.9%，前代 Fable 5.1 以 max 取得 58.0%，卻多用了一倍的 token；在 FrontierCode 2.0 上，Fable 5.2 以 high 與 Opus 5.5 以 max 的表現相近（45.3% 對 45.5%），成本卻約少一半。換句話說，較貴的模型配上較低的 effort，有時反而比較便宜的模型硬開高 effort 更划算。
官方也提醒，花費往往集中在少數困難任務上：在一個 20 題的搜尋基準中，只有兩題就吃掉 43% 的花費。速度方面，Fable 5.2 的輸出速度比 Fable 5.1 快最多 30%，Sonnet 5.5 則比前一代 Sonnet 快 30%。
至於 effort 本身的取捨，官方以 SWE-bench Pro 為例：Opus 5.5 在 medium 比 high 低約 2.5 分，成本約為七成；在 low 低約 8 分，成本約為三分之一；在 xhigh 則高約 1.4 分，成本卻是 high 的 2.5 倍。這組數字說明，往上加一級的邊際效益遞減得很快。
先用 low 全部跑一遍，只把失敗的任務用 high 重跑
如果任務的結果可以自動檢查（例如測試是否通過），官方建議先全部用 low 執行，再只把失敗的任務以 high 重跑。在同一個子集上，這個做法約有 97% 通過、每題約 $0.17；全部直接用 high 則是 95.3% 通過、每題約 $0.29，等於更便宜、通過率還更高。
要提升模型能力時，依這個順序處理
官方建議的順序是：先確認模型有辦法自我驗證，例如能跑測試、建置或腳本；接著把 effort 提高一級；最後才換更高階的模型，而且換上去之後，起始 effort 應該低於原本小模型所用的設定。
快取讓長上下文沒有想像中昂貴
長上下文每一輪都會重送，但長任務的輸入大多以快取讀取計費。150K 上下文的一輪快取讀取約 $0.03，20K 則約 $0.004。因此比較合理的做法是：讓昂貴的主模型保持精簡的上下文，把冗長的閱讀工作交給便宜的子代理去做。
混用模型時，快取與思考區塊是最容易踩到的地方
切換模型的時機與方式
快取屬於寫入它的模型，所以中途換模型後，第一輪會重新付一次快取寫入費用。官方建議在 Claude Code 先執行 /compact，或帶著簡短的計畫開新的工作階段；在 API 上則以一份工作摘要來開啟新模型的對話。
思考區塊（thinking blocks）的相容性也會影響切換：Opus 5.5 可以讀取 Sonnet 5.5 與 Haiku 5.5 的思考區塊，Sonnet 5.5 可以讀取 Haiku 5.5 的，Fable 5.2 則可以讀取 Opus 5.5、Sonnet 5.5 與 Haiku 5.5 的。
另外，也要注意往下降級時會失去較早的推理過程，無法讀取的區塊會被 API 丟棄，但請求本身仍會成功。
把子代理放到小模型上
子代理在自己的上下文中執行，並以其所屬模型的費率計費，所以把讀 log、跑測試、找檔案這類做錯了也容易發現的工作交給 Haiku，是最直接的省錢方式；程式編輯與判斷則留給主模型。官方提供的範例，是把下面這個檔案存成 .claude/agents/log-reader.md：
---
name: log-reader
description: Reads test output and logs, and reports each failing case. Use after a test run.
tools: Read, Grep, Glob, Bash
model: haiku
---
Read the logs you're given. For each failure, report the file, the test name and the first error line. Don't edit any files.另外，Claude Code 內建的 Explore 子代理會沿用工作階段所用的模型；想省成本的話，可以自訂一個 model: haiku 的 Explore 子代理。要注意的是，haiku 這個別名在 Anthropic API 上已經指向 Haiku 5.5（需要 Claude Code v2.1.293 以上），但在 Bedrock、Google Cloud、Microsoft Foundry 與 Claude Platform on AWS 上仍然指向 Haiku 4.5。
opusplan 與 Advisor 工具的實測結果
官方對幾種常見的混用設計態度相當保守。opusplan 別名是用 Opus 規劃、再用 Sonnet 執行，但官方的建議方向剛好相反，並提醒先在自己的任務上測試再採用。Advisor 工具（beta）是讓便宜的 executor 搭配較強的 advisor，官方指出在提供的四種組合中，沒有任何一種明顯勝過單獨的 executor；其中一組測試加入 advisor 後提升 1.7 分，成本卻約為 2.1 倍，差距接近雜訊範圍。
真正有效的組合是主導者加上大量並行工作者
相較之下，大量工作的委派效果比較明確：由 Opus 5.5 擔任主導者，搭配最多 25 個並行的 Sonnet 5.5 工作者，在一個約 2,200 萬 tokens 的缺陷搜尋基準上，成本比單獨使用 Opus 5.5 少約三分之一，分數相近。不過官方也說明，如果工作是單一的依賴鏈，或本來就能放進一個上下文裡，這種做法就不適用。
遷移到新模型之前，先檢查這些相容性問題
換模型不只是改一個模型名稱，官方列出了幾項需要事先確認的行為差異：
- Fable 5.2 的保留思考：如果思考區塊之前的內容（系統提示、工具或較早的訊息）有變動，API 會回傳 400 錯誤，除非選擇捨棄受影響的思考內容。透過 Claude Code、Claude Agent SDK 或 Claude Managed Agents 使用時不需要修改；自行編輯歷史訊息的程式，則應該改成附加式（append-only）。
- 思考功能：Opus 5.5 與 Fable 5.2 一律會思考，關閉會回傳錯誤；Sonnet 5.5 預設思考，可以用
between_tools限制在工具呼叫之間；Haiku 5.5 預設思考，在high或以下的 effort 可以關閉。由於回應可能以思考區塊開頭，讀取內容時應該依type判斷區塊類型。 - 強制使用工具：
tool_choice設為any或tool在 Sonnet 5.5、Opus 5.5、Fable 5.2 上會回傳 400，應該改用auto，並把工具標示為strict: true。 - 電腦操作：上述模型只透過
computer_toolset_20260801工具集支援。 - 從 Haiku 4.5 遷移到 5.5：
budget_tokens改用 effort；非預設的temperature、top_p、top_k需要移除；messages必須以 user 輪結尾。 - 安全回退：Opus 5.5、Sonnet 5.5、Fable 5.2 會經過安全分類器審查，最常在網路安全與生物學內容上觸發。在 Claude Code 中被標記的請求可能改由舊模型重跑，Fable 5.2 的網路安全請求會回退到 Opus 4.8，生物學請求則回退到 Opus 5。
如果系統同時使用多個模型，官方建議以最嚴格的那個模型的標準來建構請求，這樣各步驟就能自由升降級而不必改程式；路由規則很簡單時，應該由程式碼而不是模型來決定該用哪個模型。
與其看排行榜，不如拿自己的任務實際量測
官方最後給了一套四步驟的評估流程，適合在導入前先跑過一輪：
- 抽取真實任務，並為每個任務寫好結果檢查，例如測試通過、工單關閉、資料列數正確。
- 每個候選模型以 2 到 3 種 effort 執行，每次都在獨立的工作階段中進行，避免共用快取，並從回應的
usage欄位記錄每個任務的成本。 - 繪製「分數對花費」的圖表，只有在勝過所有單一模型的情況下，才保留多模型方案。
- 勝出的設定先以部分真實流量做影子測試（shadow），再正式切換。
在 Claude Code 裡有更快的檢查方式：用 /model 在兩個模型上各跑一次同一個待辦任務，再比較 /usage 回報的結果。
對一般開發團隊來說，這份指南的實用結論
把整份指南收斂成可以直接執行的做法，大致是三件事。第一，不確定時就從 Opus 5.5 的 medium 開始，不要一開始就挑最大的模型或最高的 effort；第二，先替任務建立可自動檢查的結果，再用「先 low、失敗再 high」的方式壓低成本；第三，把讀 log、搜尋檔案這類工作拆給 Haiku 或 Sonnet 子代理，讓昂貴的主模型保持精簡的上下文。
至於是否需要多模型組合，官方的態度是用數據說話：只有當它在分數與花費上勝過任何單一模型時才值得保留。對還在評估要不要導入 Claude 的團隊而言，這份官方選型指南提供的不是單一答案，而是一套能用自己的任務驗證答案的方法。
