Anthropic 當前 Claude 模型怎麼選：Fable、Opus、Sonnet、Haiku 對比

Anthropic 當前的 Claude 模型線已經不再只是「Haiku 快、Sonnet 均衡、Opus 最強」這麼簡單。到 2026 年 7 月，官方主推的幾類模型包括 Claude Fable 5、Claude Opus 4.8、Claude Sonnet 5、Claude Haiku 4.5，以及受限開放的 Claude Mythos 5。

如果只想快速選型，可以先記住一句話：日常開發和多數 Agent 任務優先試 Sonnet 5；複雜企業級 Agent 和高難編碼用 Opus 4.8；追求最高能力再看 Fable 5；低延遲和成本敏感任務用 Haiku 4.5；Mythos 5 不是通用產品，只面向批准客戶。

當前主要模型一覽

這裡的 MTok 指 million tokens，也就是百萬 token。價格還會受 prompt caching、batch、資料駐留、雲平台區域等因素影響，表格只放最常用的基礎輸入/輸出價格。

Fable 5：最高能力，但不是預設首選

Claude Fable 5 是 Anthropic 當前「廣泛發布」模型裡能力最高的一檔。官方給它的定位是 next-generation intelligence for long-running agents，也就是面向長流程 Agent 的下一代高能力模型。

它適合這些場景：

• 長時間、多步驟、需要自主推進的 Agent 工作流。
• 複雜研究、複雜程式碼遷移、跨系統規劃。
• 需要最高推理能力和大上下文的企業任務。
• 不太敏感於成本和延遲的高價值任務。

但 Fable 5 不一定適合作為預設模型。它價格最高，延遲也更慢。除非任務確實需要最高能力，否則從 Sonnet 5 或 Opus 4.8 開始測試通常更穩。

還要注意一點：Fable 5 使用 adaptive thinking，而且是 always on。這意味著它會自動決定什麼時候推理、推理多少；這對複雜任務有幫助，但也會讓成本和回應時間更依賴任務本身。

Opus 4.8：複雜編碼和企業 Agent 的穩妥選擇

Claude Opus 4.8 處在 Fable 5 和 Sonnet 5 之間。官方建議，如果不確定複雜 Agent 編碼和企業工作該用什麼模型，可以從 Opus 4.8 開始。

它的優勢是：

• 1M token 上下文。
• 128k token 最大輸出。
• 複雜編碼、瀏覽器 Agent、電腦使用和企業工作流表現強。
• 價格只有 Fable 5 的一半。
• 支援 adaptive thinking。

Opus 4.8 適合放在「高難任務預設模型」的位置。程式碼庫級重構、複雜 PR 修復、企業資料分析、多工具 Agent、長文檔推理等，都可以先用 Opus 4.8 做基準。

如果任務非常難，Opus 4.8 不夠，再升級 Fable 5；如果任務量很大、成本壓力明顯，再下放到 Sonnet 5。

Sonnet 5：最適合日常預設的模型

Claude Sonnet 5 是當前最值得關注的預設候選。它的定位是 best combination of speed and intelligence，也就是速度和智能的平衡點。

它適合：

• 日常編碼和程式碼審查。
• 文件整理、研究助理、知識工作。
• 中等複雜度 Agent。
• 企業內部自動化流程。
• 需要控制成本但又不能犧牲太多品質的 API 應用。

Sonnet 5 的最大變化，是把許多過去更接近 Opus 級別的 Agent 能力下放到 Sonnet 價格區間。它同樣支援 1M token 上下文和 128k token 最大輸出，延遲比 Opus 更快。

價格方面，Sonnet 5 到 2026 年 8 月 31 日前有首發優惠：輸入 $2 / MTok，輸出 $10 / MTok。2026 年 9 月 1 日起恢復到標準價格：輸入 $3 / MTok，輸出 $15 / MTok。即便按標準價，它仍然明顯低於 Opus 4.8。

如果要給大多數團隊一個起點，我會把 Sonnet 5 放在第一位：先用它覆蓋 70% 到 80% 的任務，再把真正困難的任務升級到 Opus 4.8 或 Fable 5。

Haiku 4.5：高吞吐、低延遲、低成本

Claude Haiku 4.5 是當前 Claude 主線裡最快的模型，官方定位是 fastest model with near-frontier intelligence。

它適合：

• 分類、抽取、摘要、格式轉換。
• 批量處理短文本。
• 客服、工單、內容審核等高吞吐場景。
• 對延遲非常敏感的互動式產品。
• 不需要 1M 上下文的輕量任務。

它的限制也很清楚：上下文是 200k tokens，最大輸出是 64k tokens，低於 Fable、Opus 和 Sonnet 的 1M / 128k。對長程式碼庫、複雜多文檔分析、長流程 Agent 來說，Haiku 4.5 不應該是首選。

但如果任務是「量大、簡單、需要快」，Haiku 4.5 的性價比非常直接：輸入 $1 / MTok，輸出 $5 / MTok。

Mythos 5：不要當成普通可選項

Claude Mythos 5 和 Fable 5 共享規格與價格，但它不是通用可用模型。Anthropic 文件把它標為 limited availability，僅面向 Project Glasswing 中獲批客戶。

換句話說，如果你只是做常規 API 選型，通常不需要把 Mythos 5 放進候選列表。除非你已經是獲批客戶，或者透過 Anthropic、AWS、Google Cloud 等帳號團隊取得訪問權限，否則它不是一個可以直接替換 Fable 5 的模型。

怎麼選：按任務複雜度分層

可以按下面這個順序選：

1. 預設先試 Sonnet 5
   適合大多數編碼、文件、Agent、企業自動化任務。

2. 任務明顯複雜時升到 Opus 4.8
   例如長程式碼庫、多工具、多步驟、需要穩定執行和較強推理的場景。

3. 追求最高能力時試 Fable 5
   適合高價值、長流程、失敗成本高、對價格不那麼敏感的任務。

4. 高吞吐輕任務用 Haiku 4.5
   適合分類、抽取、摘要、客服、批處理和低延遲互動。

5. Mythos 5 只在有權限時考慮
   它不是普通開發者預設可選項。

遷移和成本上的兩個細節

第一，較新的 Claude 模型使用了新 tokenizer。Anthropic 文件說明，Opus 4.7 及之後的 Opus、Fable 5、Mythos 5、Mythos Preview 和 Sonnet 5 的 tokenizer 會讓相同文本大約多出 30% token。做成本估算時，不能只看每百萬 token 單價。

第二，1M 上下文不等於每次都應該塞滿上下文。Fable 5、Opus 4.8、Sonnet 5 都支援 1M token，上下文很大，但工具調用、快取、輸出和多輪 Agent 都會疊加成本。實際部署時，更好的做法是：

• 常用系統提示和長背景用 prompt caching。
• 長文檔先分塊抽取，再交給高能力模型做綜合判斷。
• 簡單步驟交給 Haiku 或 Sonnet，關鍵決策再升級 Opus / Fable。
• 用真實任務跑小樣本，而不是只看官方 benchmark。

一個簡單結論

Claude 當前的模型線已經很清楚：

• Fable 5：最高能力，適合最難和最高價值任務。
• Opus 4.8：複雜 Agent 編碼和企業任務的強力選擇。
• Sonnet 5：最適合日常預設，能力、速度和價格平衡。
• Haiku 4.5：最快最便宜，適合大規模輕任務。
• Mythos 5：受限可用，不當作常規選項。

如果你正在給產品或內部工作流選 Claude 模型，最實用的策略不是直接追最高檔，而是把任務分層：Haiku 處理輕量批量任務，Sonnet 5 做預設執行層，Opus 4.8 處理複雜 Agent 和高難編碼，Fable 5 留給最難、最貴、最值得的那一小部分任務。

模型路由建議

給 Claude 模型做選型時，最好不要只做「一個預設模型」。更實用的方式是設計一套路由規則：輕量批處理走 Haiku，日常編碼和知識工作走 Sonnet，複雜倉庫任務和多步驟 Agent 走 Opus，最高價值、最高難度任務再升級到 Fable。

路由規則可以先簡單一點。例如摘要、分類、欄位抽取優先 Haiku；PR review、文件生成、普通程式碼修改優先 Sonnet；跨模組重構、事故復盤、複雜規劃優先 Opus；如果 Opus 連續失敗或任務價值很高，再交給 Fable。

還要給每一檔設定退出條件。模型輸出不確定、工具調用失敗、測試連續不過、上下文超過閾值、任務涉及權限或生產資料時，都應該觸發人工確認，而不是繼續自動推進。

成本評估方法

模型價格表只能做粗算。真實成本取決於上下文長度、快取命中率、重試次數、輸出長度和人工返工時間。一個更貴的模型如果一次完成率高，可能比便宜模型多次重試更省。

建議為每類任務記錄三項資料：平均 token 成本、平均人工驗收時間、失敗後升級模型的比例。跑兩週之後，通常就能看出哪些任務該放在 Sonnet，哪些任務值得上 Opus 或 Fable。

參考資料：

• Claude Models overview
• Claude Pricing