title: Claude 模型怎麼選？官方建議從 Opus 5.5 的 medium 開始，再依任務升降級到 Sonnet、Haiku 或 Fable --- **Category** - [AI](https://www.soft4fun.net/category/tech/ai) - [新聞](https://www.soft4fun.net/category/tech/news) - [科技](https://www.soft4fun.net/category/tech) **Tag** - [Claude](https://www.soft4fun.net/tag/claude) - [Claude Code](https://www.soft4fun.net/tag/claude-code) - [Fable](https://www.soft4fun.net/tag/fable) - [Opus](https://www.soft4fun.net/tag/opus) - [Sonnet](https://www.soft4fun.net/tag/sonnet) **圖片清單** - ![claude-desktop-update](https://cf.img.soft4fun.net/2026/07/claude-desktop-update-scaled.jpg "claude-desktop-update") --- Claude 模型怎麼選，是不少開發者與團隊導入時最常卡關的問題。根據 Claude 官方部落格發布最新的選型指南，建議預設從 [Opus](https://www.soft4fun.net/tag/opus) 5.5 搭配 `medium` effort 起步，再依任務難度降級到 [Sonnet](https://www.soft4fun.net/tag/sonnet) 5.5、Haiku 5.5，或升級到 [Fable](https://www.soft4fun.net/tag/fable) 5.2。 這篇指南將「該用哪個模型、effort 開多高、什麼時候混用、換模型前要檢查什麼」串成一套可以照著做的決策流程。您可以以下依序整理選用表、價格規格、成本權衡、混用技巧與遷移注意事項。 ## 官方建議的預設組合是 Opus 5.5 加上 medium effort 官方指南目前列出四款一般可用的模型與一款受限模型： - **Claude Haiku 5.5**：定位在高流量、成本敏感的任務。 - **Claude Sonnet 5.5**：速度快、能力足夠，適合範圍明確的工作。 - **Claude Opus 5.5**：複雜程式設計與知識工作的主力模型，也是 [Claude Code](https://www.soft4fun.net/tag/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。 如果系統同時使用多個模型，官方建議以最嚴格的那個模型的標準來建構請求，這樣各步驟就能自由升降級而不必改程式；路由規則很簡單時，應該由程式碼而不是模型來決定該用哪個模型。 ## 與其看排行榜，不如拿自己的任務實際量測 官方最後給了一套四步驟的評估流程，適合在導入前先跑過一輪： 1. 抽取真實任務，並為每個任務寫好結果檢查，例如測試通過、工單關閉、資料列數正確。 2. 每個候選模型以 2 到 3 種 effort 執行，每次都在獨立的工作階段中進行，避 用快取，並從回應的 `usage` 欄位記錄每個任務的成本。 3. 繪製「分數對花費」的圖表，只有在勝過所有單一模型的 況下，才保留多模型方案。 4. 勝出的設定 以部分真實流量做影子測試（shadow），再正式切換。 在 Claude Code 裡有更快的檢查方式：用 `/model` 在兩個模型上各跑一次同一個待辦任務，再比較 `/usage` 回報的結果。 ## 對一般開發團隊來說，這份指南的實用結論 把整份指南收斂成可以直接執行的做法，大致是三件事。第一，不確定時就從 Opus 5.5 的 `medium` 開始，不要一開始就挑最大的模型或最高的 effort；第二，先替任務建立可自動檢查的結果，再用「先 `low`、失敗再 `high`」的方式壓低成本；第三，把讀 log、搜尋檔案這類工作拆給 Haiku 或 Sonnet 子代理，讓昂貴的主模型保持精簡的上下文。 至於是否需要多模型組合，官方的態度是用數據說話：只有當它在分數與花費上勝過任何單一模型時才值得保留。對還在評估要不要導入 Claude 的團隊而言，這份[官方選型指南](https://claude.dev/blog/which-claude-model-should-you-build-with/)提供的不是單一答案，而是一套能用自己的任務驗證答案的方法。 - [分享到 Facebook(在新視窗中開啟) Facebook](https://www.soft4fun.net/tech/ai/claude-model-selection-guide-opus-5-5-medium-sonnet-haiku-fable.htm?share=facebook) - [分享到 Threads(在新視窗中開啟) Threads](https://www.soft4fun.net/tech/ai/claude-model-selection-guide-opus-5-5-medium-sonnet-haiku-fable.htm?share=threads) - [分享到 X(在新視窗中開啟) X](https://www.soft4fun.net/tech/ai/claude-model-selection-guide-opus-5-5-medium-sonnet-haiku-fable.htm?share=x)