Claude Opus 5 完整解析：計價、effort 與實務取捨
Claude Opus 5 是 Anthropic 於 2026 年 7 月 24 日發布的高階模型，定位於複雜代理式程式開發與企業工作，標準價格為每百萬輸入 token US$5、輸出 token US$25。本文解析其 effort 五階調校、Fast mode 與相鄰模型取捨。
作者：褚崇名（Sliven）
本頁目錄
- 本文重點
- 目錄
- 1. Claude Opus 5 是什麼：定位、發布與 model ID
- 2. 為什麼要校正「三層」認知：現行比較表已有四款主力模型
- 3. 三種計價模式：標準、Batch、Fast mode
- Token 單價不等於實際帳單
- 4. Effort 五階：low 到 max 的調校代價
- 怎麼實際挑 effort：固定測資、逐級比較
- 5. Adaptive thinking 預設開啟：與 Opus 4.8 的差異
- 6. Fast mode 什麼時候值得兩倍價
- 7. 相對 Fable 5 的取捨：半價接近峰值表現
- 一種可測試的模型分流方式
- 8. 相對 Sonnet 5 的取捨：什麼情況值得多付
- 9. 評測數字怎麼讀才不會被誤導
- 讀評測的一張檢查清單
- 10. 在台灣的取得方式與配額：API、雲端平台、訂閱方案
- 不同部署管道的差異
- 11. 什麼情況不要選 Opus 5
- 12. 判斷框架：用五個問題縮小候選
- 模型路由的實作要點
- 13. 常見誤解與快速澄清
- 常見問題
- Opus 5 跟 Opus 4.8 價格一樣嗎？
- 我該不該從 Sonnet 5 升級到 Opus 5？
- Fast mode 跟標準 Opus 5 是同一個模型嗎？
- Effort 設 max 一定最好嗎？
- Priority Tier 能加速 Opus 5 嗎？
- Opus 5 的知識截止到什麼時候？
- 結論與下一步
Claude Opus 5 是 Anthropic 於 2026 年 7 月 24 日發布的高階模型，定位於複雜的代理式程式開發與企業工作，也是 Claude Opus 4.8 的後繼版本。在 Anthropic 現行公開模型中，Fable 5 主打最高可用能力，Opus 5 則位於 Fable 5 與 Sonnet 5 之間。
Opus 5 沿用 Opus 4.8 的 API 單價，但改成預設啟用 adaptive thinking，並提供 low、medium、high、xhigh、max 五種 effort。這讓模型選擇不再只有「換哪一款」，還要考慮同一款模型該用多少推理資源。本文聚焦這項取捨，不重複 Claude 生態總覽或 Sonnet 5 的日常使用範圍。
本文重點
- Opus 5 於 2026 年 7 月 24 日發布，Claude API model ID 為
claude-opus-5，沒有日期後綴；標準價格為每百萬輸入 token US$5、輸出 token US$25。 - 它支援 low、medium、high、xhigh、max 五種 effort；Claude API 與 Claude Code 的預設值都是 high，省略
thinking參數時會啟用 adaptive thinking。 - Anthropic 公布的 CursorBench 3.2 結果顯示，Opus 5 在 max effort 下與 Fable 5 峰值分數相差不到 0.5%，每項任務成本約為後者一半。
- Fast mode 是研究預覽功能，價格為每百萬輸入 token US$10、輸出 token US$50，輸出 token 速度最高可達標準模式的 2.5 倍；它不保證首個 token 同步加快。
- Anthropic 最新模型比較表列出 Fable 5、Opus 5、Sonnet 5 與 Haiku 4.5。這四款模型的價格、速度與適用工作不同，不能只用「愈高階愈好」來選。
目錄
- Claude Opus 5 是什麼：定位、發布與 model ID
- 為什麼要校正「三層」認知：現行比較表已有四款主力模型
- 三種計價模式：標準、Batch、Fast mode
- Effort 五階：low 到 max 的調校代價
- Adaptive thinking 預設開啟：與 Opus 4.8 的差異
- Fast mode 什麼時候值得兩倍價
- 相對 Fable 5 的取捨：半價接近峰值表現
- 相對 Sonnet 5 的取捨：什麼情況值得多付
- 評測數字怎麼讀才不會被誤導
- 在台灣的取得方式與配額：API、雲端平台、訂閱方案
- 什麼情況不要選 Opus 5
- 判斷框架：用五個問題縮小候選
- 常見誤解與快速澄清
- 常見問題
- 結論與下一步
1. Claude Opus 5 是什麼：定位、發布與 model ID
Claude Opus 5 於 2026 年 7 月 24 日發布，Claude API model ID 是 claude-opus-5。這是沒有日期後綴的固定 model ID，命名方式與 claude-opus-4-8、claude-sonnet-5 相同。
根據 Anthropic 官方公告與模型文件，Opus 5 發布時已可透過 Claude API、Amazon Bedrock、Google Cloud 與 Microsoft Foundry 取得。Anthropic 的模型總覽也把 Claude Platform on AWS 列為現行模型的提供管道。消費端方面，官方在發布公告中稱它是 Claude Max 的預設模型，也是 Claude Pro 當時能力最強的可用模型。
規格方面，Opus 5 的上下文視窗是 100 萬 token，預設值就是上限，不用申請額外擴充；單次最大輸出為 12.8 萬 token。官方模型總覽列出的 reliable knowledge cutoff 與 training data cutoff 都是 2026 年 5 月。兩者代表不同概念，只是這款模型目前標示的月份相同。
官方將 Opus 5 定位為複雜代理式程式開發與企業工作使用的模型。較符合這項定位的任務包括長時間工具呼叫、多檔案功能開發、大型重構，以及需要模型規劃後持續執行的工作。若任務只是單輪問答、摘要或局部改寫，是否值得使用 Opus 5，仍要看實測差異與成本。
Opus 5 不是 Anthropic 公開模型中能力最高的一款。模型總覽把 Fable 5 列為最高可用能力的選擇，Opus 5 則強調複雜的代理式程式開發與企業工作；Sonnet 5 與 Haiku 4.5 分別偏向速度、成本與一般工作負載。
理解 Opus 5 的定位，要先弄清楚代理式（agentic）系統和一般單輪問答的差別。單輪模型回答一次就結束，成本就是那一次的 token；代理式系統會透過模型以外的工具與編排機制規劃步驟、呼叫工具、讀到錯誤再修正，一次任務可能經過多輪互動。這時除了單價，還要計算整段任務累積的 token、工具呼叫與重試次數。
這也是為什麼 effort 與 max_tokens 會影響 Opus 5 的採購判斷。同一個單價，在單輪任務上差別可能有限；在長時間代理任務中，較高 effort 帶來的 token 與延遲可能在多輪互動中持續累積。除了掛牌單價，還要看整段任務實際用了多少資源。
| 任務類型 | 典型互動 | Token 結構 | 選模型時最該看的 |
|---|---|---|---|
| 單輪問答、摘要 | 一次輸入、一次輸出 | 輸入為主，輸出短 | 單價與速度 |
| 多輪對話、寫作 | 數次往返，context 累積 | 輸入隨對話變長 | 快取折扣與 context 上限 |
| 代理式開發、長任務 | 自主規劃、工具呼叫、重試 | 多輪、thinking、工具輸出疊加 | effort 彈性、max_tokens、失敗成本 |
這張表可用來初步篩選候選模型。單輪任務通常可先測較便宜的模型；多輪或代理式工作則更需要比較 effort、max_tokens、成功率與完整成本。
2. 為什麼要校正「三層」認知：現行比較表已有四款主力模型
不少既有 Claude 介紹仍以 Opus、Sonnet、Haiku 三個名稱概括產品線。Fable 5 上線後，這套說法已不足以描述 Anthropic 現行模型比較表。
截至 2026 年 8 月 2 日，官方比較表列出 Fable 5、Opus 5、Sonnet 5 與 Haiku 4.5。Fable 5 的標準價格為每百萬輸入 token US$10、輸出 token US$50；Opus 5 為 US$5／US$25；Sonnet 5 的標準價格為 US$3／US$15，但 2026 年 8 月 31 日前有 US$2／US$10 的初期優惠；Haiku 4.5 為 US$1／US$5。價格可能調整，採購前仍應查閱 Claude 官方定價頁。
| 模型 | 標準價格（每百萬輸入／輸出 token） | 官方定位摘要 | 較適合評估的工作 |
|---|---|---|---|
| Claude Fable 5 | US$10／US$50 | 長時間代理工作的最高公開能力 | 能力優先、成本次要的高難度任務 |
| Claude Opus 5 | US$5／US$25 | 複雜代理式程式開發與企業工作 | 長任務、多檔案開發、深度分析 |
| Claude Sonnet 5 | US$3／US$15 | 速度與能力的搭配 | 一般開發、寫作與互動式工作 |
| Claude Haiku 4.5 | US$1／US$5 | 速度最快的現行模型 | 高吞吐、成本敏感的簡單任務 |
表中的 Sonnet 5 是標準價格。官方另有 2026 年 8 月 31 日前的初期優惠，輸入／輸出價格為 US$2／US$10。這種限時價格不宜當成長期預算基準。
四款模型同時存在後，Opus 5 的採購問題變成兩段：相對 Sonnet 5，多付的成本能否改善你的高難度任務；相對 Fable 5，是否需要為最高可用能力再付更高價格。這兩題都沒有通用答案，必須用自己的任務與失敗成本判斷。
關於 Sonnet 5 的日常取向與實際用法，站內另有 Sonnet 5 深度介紹；Claude 生態的整體輪廓則整理在 Claude AI 完整指南。本文集中處理 Opus 5 的 effort、計價與相鄰模型取捨。
3. 三種計價模式：標準、Batch、Fast mode
Opus 5 有標準 API、Message Batches API 與 Fast mode 三種常見使用方式。三者的差別主要在價格、等待方式與可用管道。
標準模式每百萬輸入 token US$5、輸出 token US$25，與 Opus 4.8 相同。這是一般即時 API 呼叫的基礎價格，不含 prompt caching、資料駐留、伺服器端工具或雲端平台可能產生的其他費用。
Message Batches API 以標準 token 價格的五折計費，因此 Opus 5 每百萬輸入 token 為 US$2.50、輸出 token 為 US$12.50。Batch 採非同步處理，官方表示多數批次可在一小時內完成；若個別請求未在 24 小時內完成，會到期而不計費。它適合分類、摘要、抽取或大量評測等不要求立即回應的工作。
Fast mode 是研究預覽，Opus 5 的價格為每百萬輸入 token US$10、輸出 token US$50。官方說法是輸出 token 速度最高可達標準模式的 2.5 倍，效益集中在 output tokens per second，不代表 time to first token 一定等比例縮短。
| 模式 | 價格（每百萬輸入／輸出 token） | 處理方式 | 較適合的工作 |
|---|---|---|---|
| 標準 | US$5／US$25 | 同步 | 互動式應用、即時代理任務 |
| Batch | US$2.50／US$12.50 | 非同步，多數批次一小時內完成，24 小時到期 | 批次分類、摘要、離線抽取、評測 |
| Fast mode | US$10／US$50 | 同步，輸出速度最高 2.5 倍 | 對長輸出延遲敏感且能申請到預覽權限的工作 |
Fast mode 不是另一個較強的模型。官方文件明確表示，它使用相同模型權重與行為，只改用較快的推論設定。Batch 的折扣也來自非同步處理方式，不是改用較低階模型。
Token 單價不等於實際帳單
單價是單位費率，實際帳單還會受到輸入 token、輸出與 thinking token、工具呼叫、重試次數及伺服器端工具費用影響；如果啟用了 prompt caching，也要分開計算快取寫入與命中。兩個應用即使都呼叫 Opus 5，成本仍可能相差很多。
評估預算時，比較實用的切入點是「單位任務成本」而不是「每百萬 token」。追蹤一批固定測資完成後的平均 token 與成功率，再把失敗重跑的成本攤進去，才看得到真實的單位成本。這個觀念也會在後面 effort 與模型路由兩節重複出現，因為它正是 Opus 5 採購判斷的核心。
（示意）以 Batch 處理分類工作的單價比較
下面用官方公布的單價做一個算術練習，數字為示意，不是任何實際專案的測量結果。假設每天處理 1,000 筆文件分類，每筆平均 800 個輸入 token、200 個輸出 token：
| 模式 | 輸入單價 | 輸出單價 | 每日估算 token 成本 | 說明 |
|---|---|---|---|---|
| 標準 | US$5／百萬 | US$25／百萬 | 約 US$9.00 | 即時回應，適合互動 |
| Batch | US$2.50／百萬 | US$12.50／百萬 | 約 US$4.50 | 半價，多數批次一小時內回 |
這只是單價換算。實際成本會因 token 用量、快取、工具費用與失敗重跑而不同；採購前應以自己的測資重新計算。若每天都有相同工作量，還要把每日差額換算成月成本，再評估等待時間是否能接受。
4. Effort 五階：low 到 max 的調校代價
Opus 5 支援 low、medium、high、xhigh、max 五種 effort。這個參數控制整份回應願意投入多少 token，不只影響 thinking，也會影響文字、工具呼叫與函式參數。
Claude API 與 Claude Code 預設使用 high；省略 effort 與明確指定 high 的行為相同。Anthropic 建議從 high 開始，再依自己的評測往下調整成本與延遲，或在要求較高的程式開發與代理工作中測試 xhigh、max。若要了解 Claude Code 的安裝、權限與基本操作，可參考 Claude Code 中文教學。
Effort 是行為訊號，不是固定 token 額度。提高 effort 通常會增加 token 用量與延遲，但官方沒有保證各級之間的固定倍率。實際差異取決於任務；不能把 high 到 max 寫成必然增加幾成或固定翻倍。
max_tokens 也不會隨 effort 自動放大。它是 thinking 與最終回答共用的單次輸出硬上限。官方建議在 xhigh 或 max 時設定較大的 max_tokens，避免模型在推理或工具呼叫途中撞到上限；這是開發者需要調整的請求參數，不是模型自動擴充配額。
| Effort | 官方用途摘要 | 調校時可先觀察什麼 |
|---|---|---|
| low | 優先節省 token 與時間 | 簡單查找、分類或子代理工作是否仍維持品質 |
| medium | 在品質與資源之間取平衡 | 一般代理工作能否減少成本與延遲 |
| high（預設） | 複雜推理、程式開發與代理任務 | 當作第一輪評測基準 |
| xhigh | 長時間代理與進階程式開發 | high 是否漏掉跨步驟或跨檔案問題 |
| max | 在 max_tokens 上限內採用最高能力設定 |
能力提升是否值得額外 token 與延遲 |
不要預設 max 一定最划算。Anthropic 的遷移文件也提醒，max 在簡單任務上可能過度思考，token 增加後可能出現邊際效益遞減。較穩妥的做法是固定一批真實測資，逐級比較任務成功率、token、延遲與人工修正時間。
Effort 最適合按工作類型路由，但如果同一段對話依賴 prompt caching，還要注意 effort 是逐次請求設定，變更它會使先前快取前綴失效。此時可在不同工作負載之間分流，避免在同一段長對話裡頻繁切換。
怎麼實際挑 effort：固定測資、逐級比較
Effort 沒有公式可以代，只能用自己的資料測。一個可重複的評測流程是：
- 從真實工作中抽出一批具代表性的測資，保留困難的長尾樣本，不要只用簡單題目。需要多少筆沒有通用答案，應依工作類型、風險與資料差異決定。
- 全部先用 high 跑一遍，記錄成功率、輸出 token、延遲與需要人工修正的分鐘數。
- 把 high 已經通過的簡單任務，再跑一次 medium 或 low，看是否能再壓低成本而不掉品質。
- 把 high 失敗或勉強通過的困難任務，往上測 xhigh 或 max，同時把
max_tokens開大。 - 找出成功率改善已趨緩、token 用量卻明顯增加的級距，作為設定預設值的參考。
如果測資只包含簡單任務，low 可能看起來已經夠用，卻反映不出長尾工作的失敗情況。effort 的選擇很依賴測資能否代表實際工作分布；測資偏向簡單，評估結果也會過度樂觀。
| 評測時該記錄的指標 | 為什麼重要 | 怎麼用 |
|---|---|---|
| 任務成功率 | 主要品質指標之一 | 在成功率相近的級距裡，比較成本與人工修正量 |
| 輸出 token 中位數與尾端值 | 觀察 effort 對成本分布的影響 | 同時看典型用量與長尾用量，避免平均值掩蓋極端案例 |
| 端到端延遲 | 影響互動體驗與代理步驟疊加 | 與 time to first token 分開量 |
| 人工修正分鐘數 | 失敗的隱性成本 | 換算成工資，加進單位任務成本 |
| 失敗類型分布 | 判斷是能力問題還是 prompt 問題 | 同類失敗集中在某一級以上，就是分流的切入點 |
這套流程能把籠統的模型評價，換成每一級 effort 的成功率、成本、延遲與人工修正時間，方便比較不同設定。
5. Adaptive thinking 預設開啟：與 Opus 4.8 的差異
Opus 5 與 Opus 4.8 的主要行為差異，是省略 thinking 欄位時的預設值。Opus 4.8 在沒有該欄位時不會 thinking；Opus 5 則會啟用 adaptive thinking，由模型決定每一輪是否思考以及投入多少。
從 Opus 4.8 升級時，不需要再次移除 budget_tokens 與 temperature、top_p、top_k。Opus 4.8 本來就不支援手動 extended thinking 的 thinking: {type: "enabled", budget_tokens: N}，非預設的取樣參數也已會回傳 400；這些並非 Opus 5 新增的限制。
需檢查的 breaking change 有兩項。第一，原本省略 thinking 的請求會開始使用 adaptive thinking，因此應重新檢查 max_tokens、成本與延遲。第二，Opus 5 只有在 effort 為 high、medium 或 low 時可以設定 thinking: {type: "disabled"}；若停用 thinking 又使用 xhigh 或 max，API 會回傳 400。
若要保留 Opus 4.8 的非 thinking 行為，可以在 high 以下明確停用 thinking。不過，官方遷移指南指出，Opus 5 停用 thinking 時，偶爾可能把工具呼叫寫成一般文字，或在可見輸出中出現內部 XML 標籤。可行的情況下，官方較建議保留 thinking，再用較低的 effort 控制用量。
從 Opus 4.8 遷移時，最小檢查清單如下：
- 把 model ID 從
claude-opus-4-8改成claude-opus-5。 - 找出原本省略
thinking的請求，重新量測 token、延遲與輸出截斷情況。 - 找出明確停用 thinking 的請求；若 effort 是 xhigh 或 max，改為啟用 thinking，或把 effort 降到 high 以下。
- 檢查是否使用 web fetch。官方遷移文件指出，Opus 5 目前不支援這項伺服器端工具。
- 如果組織有 Priority Tier 承諾，另行規劃容量，因為 Opus 5 不支援 Priority Tier。
若程式是從 Opus 4.6 或更早版本直接升級，才需要另外處理手動 budget_tokens 與取樣參數等舊介面差異。不要把跨多代遷移的清單誤套到 Opus 4.8。
6. Fast mode 什麼時候值得兩倍價
Fast mode 是 Opus 5 與 Opus 4.8 支援的研究預覽功能。Opus 5 的價格為每百萬輸入 token US$10、輸出 token US$50，也就是標準 token 價格的兩倍。
它使用相同模型，只改用較快的推論設定。官方標示的是「輸出 token 速度最高 2.5 倍」，而且說明加速集中在 output tokens per second，不是 time to first token。若應用最在意第一個 token 多快出現，不能只憑 2.5 倍這個數字估算體感，應先測量完整延遲分布。
Fast mode 較可能適合長輸出、互動式代理或人工正在等待模型完成的工作。是否值得兩倍價格，可比較兩件事：實測省下多少完成時間，以及這段時間對使用者流失、人工等待或系統周轉的實際成本。短回答若瓶頸在首個 token，收益可能不如標示的最高輸出速度明顯。
批次、非同步或可排隊的工作通常不需要 Fast mode。這類工作可以先評估 Batch API，以標準價格五折處理；Fast mode 則是為同步輸出速度支付溢價。兩者解決的是相反的等待需求。
Fast mode 目前要向客戶經理申請，沒有客戶經理的使用者可加入候補名單。它可用於 Claude API，包括 Claude Managed Agents；Anthropic 發布公告也提到 Claude Code 可透過 usage credits 使用。它不支援 Amazon Bedrock、Google Cloud 或 Microsoft Foundry，也不是一般請求自動享有的速度。
研究預覽代表功能、容量與存取方式可能調整。若要放進正式流程，應保留切回標準速度的路徑，並以回應中的 usage.speed 確認實際使用的是 fast 或 standard。
7. 相對 Fable 5 的取捨：半價接近峰值表現
Anthropic 在 Opus 5 發布公告中，將它描述為以一半價格接近 Fable 5 的前沿能力。對應的官方評測是 CursorBench 3.2：Opus 5 在 max effort 下，與 Fable 5 的峰值分數相差不到 0.5%，每項任務成本約為後者一半。
這項數字有三個限制。第一，官方寫的是「相差不到 0.5%」，不是「達到 Fable 5 的 99.5%」。第二，比較條件是 Opus 5 使用 max effort，對照 Fable 5 的峰值分數，不能泛化到其他 effort。第三，CursorBench 3.2 是程式開發代理評測，不代表文件摘要、客服問答或其他工作也只有同樣差距。
此外，官方比較的是每項任務成本，不只是掛牌 token 單價。Opus 5 與 Fable 5 的標準 token 單價確實相差一倍，但實際帳單仍會受輸入長度、輸出 token、effort、快取與工具使用影響。採購時應把完整任務成本算進去。
若工作要求 Anthropic 目前公開模型中的最高能力，官方模型總覽建議 Fable 5。若你的主要任務接近 CursorBench 的代理式程式開發，而且 Opus 5 在自家評測已達標，Opus 5 可能以較低成本完成工作。兩種情況之間仍需靠真實測資，而不是只看 0.5% 決定。
在大量任務中，兩款模型的價差會累積；在少量但失敗代價高的任務裡，最高能力可能比 token 單價重要。可以先用 Opus 5 跑完整評測，再把未達標的工作送到 Fable 5，不必預設所有請求都使用同一款模型。供應穩定度也值得納入評估：Fable 5 曾在 2026 年 6 月因美國出口管制命令全面暫停存取 19 天，當時 Opus 5 尚未問世，重要流程預先準備備援模型，才不會跟著停擺。
一種可測試的模型分流方式
若評測顯示 Opus 5 能處理大部分困難任務，可以先把它設為這類工作的預設，再將未達標或失敗成本特別高的工作送到 Fable 5。Fable 5 的標準輸入與輸出單價都是 Opus 5 的兩倍，因此分流規則應建立在實測結果上。
這套路由需要能偵測失敗的回饋機制，例如自動化測試、人工抽審或使用者回報。沒有這類訊號，就很難判斷哪些請求該升級。
8. 相對 Sonnet 5 的取捨：什麼情況值得多付
Sonnet 5 的標準價格為每百萬輸入 token US$3、輸出 token US$15；2026 年 8 月 31 日前，官方初期優惠為 US$2／US$10。Opus 5 則是 US$5／US$25。若要做長期預算，應以 Sonnet 5 標準價格計算，並把優惠視為限時條件。
官方沒有發布一個可套用到所有工作的「Opus 5 比 Sonnet 5 強多少」數字。Opus 5 公告中的 Frontier-Bench v0.1 比較對象是 Opus 4.8，不是 Sonnet 5；ARC-AGI 3 的三倍數字則是相對當次評測的次佳模型。兩者都不能改寫成 Opus 5 比 Sonnet 5 強兩倍或三倍。
判斷是否升級，可以先看 Sonnet 5 在實際工作中失敗的位置。如果問題集中在長時間代理、多步驟規劃、跨檔案修改或高失敗成本的任務，再用同一批測資比較 Opus 5。若兩者的成功率與人工修正時間接近，使用 Sonnet 5 較省；若 Opus 5 能穩定減少重跑或人工介入，價差才可能合理。
任務可以先分成三類：
- 單輪、結構清楚、失敗後容易重跑的工作，先以 Sonnet 5 或更便宜的模型建立基準。
- 多檔案、長工具鏈或需要理解大量專案脈絡的工作，同時測 Sonnet 5 與 Opus 5。
- 單次失敗成本很高的疑難任務，再把 Fable 5 一併納入評測。
這不是固定分級規則。官方定位只能協助挑出候選模型，最後仍要比較任務成功率、人工修改時間、延遲與完整成本。
用任務訊號反推，可以整理成一張更實用的起點對照：
| 任務訊號 | 建議先測的起點模型 | 理由 |
|---|---|---|
| 單輪、結構清楚、可重跑 | Haiku 4.5 或 Sonnet 5 | 失敗成本低，先壓單價 |
| 多檔案、長工具鏈、需理解大量脈絡 | Sonnet 5 或 Opus 5 | 脈絡與規劃開始吃重 |
| 單次失敗成本很高、疑難任務 | Opus 5，必要時 Fable 5 | 失敗代價大於 token 差價 |
這張表只提供評測起點。最後仍要用同一批測資比較成功率、人工修正量、延遲與完整成本。
| 比較軸 | Fable 5 | Opus 5 | Sonnet 5 |
|---|---|---|---|
| 標準價格（每百萬輸入／輸出 token） | US$10／US$50 | US$5／US$25 | US$3／US$15 |
| 官方定位 | 長時間代理工作的最高公開能力 | 複雜代理式程式開發與企業工作 | 速度與能力的搭配 |
| Effort | low 至 max | low 至 max | low 至 max |
| Fast mode | 官方文件未列為支援模型 | 有，研究預覽 | 無 |
| Priority Tier | 支援既有承諾 | 不支援 | 不支援 |
9. 評測數字怎麼讀才不會被誤導
Opus 5 公告中的評測數字都有特定條件。轉述時若省略比較對象、effort、成本或測試環境，數字很容易變成錯誤的採購結論。
Frontier-Bench v0.1 的官方說法是：Opus 5 在較低的單項任務成本下，表現超過 Opus 4.8 的兩倍。這不是與 Sonnet 5 的比較。Anthropic 的註腳也說明，該結果來自內部執行，使用 mini-SWE-agent harness、GKE backend，每項任務取五次嘗試的平均 reward，且特定安全分類器拒答會回退到 Opus 4.8。
ARC-AGI 3 的官方說法是 Opus 5 分數為當次次佳模型的三倍。這裡的比較對象是次佳模型，不是所有模型，也不能延伸成任何實際工作都會有三倍成功率。
CursorBench 3.2 的條件是 Opus 5 使用 max effort，與 Fable 5 峰值分數相差不到 0.5%，且每項任務成本約為一半。它不能改寫成 Opus 5 固定落後 0.5%，也不能用來推估 high、medium 或 low 的差距。
官方同一份公告還列出其他內部或合作評測，包括科學研究與安全測試。若文章需要引用這些資料，應保留原始量測項目、比較對象與單位，並註明來源是 Anthropic 或合作方，不能把百分點改寫成百分比，也不要把特定分類器結果泛化成整體安全性。
評測可作為候選模型的篩選資料，但無法取代自己的測試。CursorBench 偏向代理式程式開發；如果用途是摘要、客服或資料抽取，它的預測力有限。採購前應用固定測資做盲測，記錄成功率、人工修正時間、token、延遲與失敗類型，再決定模型路由。
讀評測的一張檢查清單
| 看到一個評測數字時，先問 | 為什麼重要 |
|---|---|
| 比較對象是哪一款模型？ | 「次佳模型的三倍」不等於「Sonnet 5 的三倍」 |
| 用的是哪一級 effort？ | max 的結果不能推回 high 或 medium |
| 成本是 token 單價還是單位任務成本？ | 兩者可能相差很多 |
| 評測領域與你的工作接近嗎？ | 程式開發評測對客服預測力有限 |
| 測試環境與拒答回退是什麼？ | 內部 harness、分類器回退都會影響數字 |
| 是官方還是第三方執行？ | 影響能否重製，以及是否單方面有利 |
若比較對象、測試條件或來源不清楚，就先不要把該數字寫進採購結論。評測可用來篩選候選模型，但不能保證某一款在你的工作上一定最好。
10. 在台灣的取得方式與配額：API、雲端平台、訂閱方案
Anthropic 的支援國家與地區清單截至 2026 年 8 月仍把台灣列在商用 API 與 Claude.ai 的支援範圍。這只代表地區可用性；實際能否購買特定方案、付款方式與帳號配額，仍以登入後顯示與官方條款為準。
開發端可透過 Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry 與 Claude Platform on AWS 取得 Opus 5。它在 Claude API 使用 claude-opus-5，Amazon Bedrock 使用 anthropic.claude-opus-5，Google Cloud 使用 claude-opus-5；Microsoft Foundry 的精確部署識別碼應以平台文件為準。各平台的區域端點、資料駐留、折扣與計價方式可能不同，不能直接把第一方 API 單價套到所有部署。
消費端方面，Anthropic 在發布 Opus 5 時稱它是 Claude Max 的預設模型，也是 Claude Pro 當時能力最強的模型。訂閱方案的用量上限不是 API token 額度，且可能依帳號、功能與地區調整；採購前應查看 Claude 方案頁與帳號內資訊。
配額方面，Opus 5 有自己的標準 rate-limit pool，不與 Opus 4.8、4.7、4.6、4.5 共用合併池。這表示兩代 Opus 的速率限制要分開監看；各組織的實際上限則依使用等級或合約而定。
Opus 5 不支援 Priority Tier。官方目前也不再販售新的 Priority Tier 容量承諾，只有既有承諾可使用到合約結束。若現有架構依賴 Opus 4.8 的 Priority Tier，升級前要另行規劃容量，不能假設承諾會自動轉到 Opus 5。
接入正式流量前，可先用低流量測試觀察每種 effort 的 token 分布、延遲、截斷與 rate limit。監控也應把標準模式、Fast mode 與舊版 Opus 分開，因為 Fast mode 另有獨立速率限制。
不同部署管道的差異
同一個 Opus 5，部署管道不同，計價、資料駐留、區域與可用功能可能不同。下表整理四個常見管道；Claude Platform on AWS 另透過 AWS Marketplace 以 Claude Consumption Units（CCU）計費，目前也不支援 Fast mode。確切規格仍以各平台官方文件為準。
| 管道 | model ID | Fast mode | 計價基礎 | 適合的採購情境 |
|---|---|---|---|---|
| Claude API（第一方） | claude-opus-5 |
有（研究預覽） | 第一方 token 單價 | 直接整合、需要最新功能 |
| Amazon Bedrock | anthropic.claude-opus-5 |
未支援 | Bedrock 計價 | 已用 AWS、要統一帳單與區域 |
| Google Cloud | claude-opus-5 |
未支援 | Google Cloud 計價 | 已用 GCP、要整合既有專案 |
| Microsoft Foundry | 官方文件列為供應管道 | 未支援 | Foundry 計價 | 已用 Azure、要企業採購流程 |
跨平台遷移時，不要假設單價、速率限制與功能完全一致。Fast mode 目前只在第一方 Claude API 提供；若團隊已使用某個雲端平台的折扣方案，也要把離開該方案的成本一併計算。
11. 什麼情況不要選 Opus 5
第一種是成本敏感的高吞吐工作。若請求數量很大，Opus 5 與 Sonnet 5、Haiku 4.5 的單價差會累積。可以先讓較便宜的模型處理簡單請求；若任務範圍清楚，也可評估小型語言模型（SLM）是否合適，只將自家評測顯示確有改善的高難度任務送到 Opus 5。
第二種是工作流程必須調整取樣參數。Opus 5 對非預設 temperature、top_p、top_k 會回傳 400。Opus 4.8 也有相同限制，因此留在 Opus 4.8 不能解決問題。若這些參數是硬性需求，應查閱官方的逐模型相容性文件；有合適的支援模型時再評估更換，否則可改用 prompt、structured outputs 等方式控制輸出。
第三種是必須使用 Priority Tier 的工作。Opus 5 不支援 Priority Tier；既有承諾也不能直接移轉。Fast mode 雖可提高輸出速度，但它是要申請權限的研究預覽，不能視為相同的容量保證。
第四種是依賴官方 web fetch 工具的流程。Anthropic 的 Opus 5 遷移指南明列 web fetch 目前不可用；若流程不能改用其他擷取方式，升級前要先處理這項功能缺口。
第五種是簡單且可重跑的任務。如果 Sonnet 5 或 Haiku 4.5 在盲測中的成功率與人工修正時間已經達標，使用 Opus 5 未必划算。判斷依據應是自己的輸出差異與完整成本，而不是模型名稱。
把上述情境收攏成一張替代對照：
| 不選 Opus 5 的原因 | 可先評估的替代 |
|---|---|
| 成本敏感、高吞吐 | Sonnet 5 或 Haiku 4.5，只把困難任務升級 |
| 必須調 temperature／top_p／top_k | 查官方逐模型相容性文件；有合適的支援模型時再更換 |
| 必須用 Priority Tier | 留在仍支援 Priority Tier 的模型，另規劃容量 |
| 依賴 web fetch | 留在支援的模型，或改用其他擷取方式 |
| 任務簡單、可重跑 | 用較便宜模型建立基準即可 |
替代表只是起點。最後該不該留或換，仍要看自己跑出來的成功率與完整成本。
12. 判斷框架：用五個問題縮小候選
前面幾節的判斷點可以整理成五個問題。它們用來縮小候選範圍，不保證直接得出單一答案。
- 任務是單輪，還是多步驟代理？單輪可先測較便宜的模型；多步驟代理再把 Opus 5 或 Fable 5 納入比較。
- 失敗一次的成本多高？失敗成本愈高，愈值得測試高階模型與較高 effort。
- 每天的請求量與單次 token 用量有多少？總 token 用量愈高，單價差對預算的影響愈大。
- 工作流程是否依賴 Priority Tier、特定取樣參數或 web fetch？這些是 Opus 5 的已知不相容點，任一為硬性需求就先排除。
- 平台是第一方 API，還是雲端平台？若需要 Fast mode，目前只有第一方 API 提供。
| 問題 | 傾向 Opus 5 | 傾向其他模型 |
|---|---|---|
| 任務型態 | 多步驟、跨檔案、長工具鏈 | 單輪、結構清楚 |
| 失敗成本 | 高，重跑很貴 | 低，可輕易重來 |
| 用量與預算 | 估算後可承受較高單位成本 | 總 token 用量大、成本敏感 |
| 工具需求 | 不依賴 web fetch／Priority Tier | 依賴上述其一 |
| 平台 | 第一方 API 或支援 Opus 5 的雲端 | 需要其他平台專屬功能 |
回答完這五題後，仍要用固定測資做盲測，比較成功率與完整成本，再決定預設模型。若沒有單一模型明顯勝出，可把多模型分流納入下一輪測試。
模型路由的實作要點
如果測資支持多模型並存，分流可能比固定使用單一模型省。簡單任務可走較便宜的模型，困難任務走 Opus 5；只有評測顯示需要更高能力的高風險任務，才送到 Fable 5。實作時要定義任務分類與失敗回饋，並保留可把特定任務切回單一模型的開關。
模型分流最需要維護的是升級與降級規則。可以先用單一模型建立基準，整理失敗案例的分布，再依結果設計升級條件；沒有回饋機制的路由，只會把原本的猜測自動化。
13. 常見誤解與快速澄清
以下整理 Opus 5 相關資訊中容易混淆的說法。每一項都要連同本文前面引用的官方條件一起理解。
| 常見說法 | 澄清 |
|---|---|
| Opus 5 比 Sonnet 5 強兩倍或三倍 | 官方沒有這個跨所有工作的數字；Frontier-Bench 是與 Opus 4.8 比，ARC-AGI 3 是與當次次佳模型比 |
| Effort 設 max 一定最好 | max 在簡單任務上可能過度思考，增加的 token 未必帶來相應的品質改善 |
| Fast mode 是更強的模型 | 同模型權重，只是改用較快的推論設定；加速集中在輸出速度 |
| 半價等於達到 Fable 5 的 99.5% | 官方寫的是「相差不到 0.5%」，不是「達到 99.5%」；且條件是 max effort |
| Batch 是用較低階模型 | 同一個 Opus 5，折扣來自非同步處理方式 |
| Priority Tier 可以加速 Opus 5 | Opus 5 不支援 Priority Tier，Fast mode 是另一回事 |
| 知識截止可以寫成單一日期 | 官方區分 reliable knowledge cutoff 與 training data cutoff，是兩個概念 |
| 升級 Opus 5 會破壞 Opus 4.8 的取樣參數行為 | Opus 4.8 本來就回傳 400，這不是 Opus 5 新增的限制 |
這張表不能替代官方文件。任何數字要寫進採購或遷移文件前，都應回頭核對原始公告、模型總覽與適用條件。
常見問題
Opus 5 跟 Opus 4.8 價格一樣嗎？
標準模式相同，都是每百萬輸入 token US$5、輸出 token US$25；Batch API 也都是標準價格五折。Fast mode 兩者同為 US$10／US$50。差別主要在 Opus 5 預設啟用 adaptive thinking，以及停用 thinking 時 effort 不能設為 xhigh 或 max。
我該不該從 Sonnet 5 升級到 Opus 5？
先比較自己的任務。長時間代理、多步驟規劃、跨檔案修改或失敗成本高的工作較值得納入 Opus 5 測試；單輪且容易重跑的工作可先留在 Sonnet 5。不要把 Opus 5 對 Opus 4.8 的官方評測數字當成 Sonnet 5 的直接比較。
Fast mode 跟標準 Opus 5 是同一個模型嗎？
是。官方文件表示兩者使用相同模型權重與行為，Fast mode 改用較快的推論設定。它的輸出 token 速度最高可達 2.5 倍，但 time to first token 不保證等比例改善。
Effort 設 max 一定最好嗎？
不一定。max 代表在 max_tokens 上限內採用最高能力設定，可能增加 token 與延遲；簡單任務還可能過度思考。先以 high 建立基準，再用固定測資比較 xhigh 與 max 的成功率和完整成本。
Priority Tier 能加速 Opus 5 嗎？
不能。Opus 5 不支援 Priority Tier。Fast mode 可以提高輸出速度，但它是需要申請的研究預覽，適用範圍與 Priority Tier 不同。
Opus 5 的知識截止到什麼時候？
官方模型總覽把 reliable knowledge cutoff 與 training data cutoff 都列為 2026 年 5 月。兩個欄位的概念不同，但 Opus 5 目前標示的是同一月份。
結論與下一步
Claude Opus 5 的標準價格是每百萬輸入 token US$5、輸出 token US$25，介於 Fable 5 與 Sonnet 5 之間。Anthropic 的 CursorBench 3.2 結果顯示，Opus 5 在 max effort 下與 Fable 5 峰值分數相差不到 0.5%，每項任務成本約為一半；這項結果只適用於該評測與指定條件。
採購時可以依序處理：先確認所用平台與必要工具是否支援 Opus 5，再以 high effort 跑自家測資；接著比較 Sonnet 5、Opus 5，必要時再加入 Fable 5。若某類任務的差異明顯，再考慮升級；若 high 不足，再測 xhigh 或 max，並同時記錄 token、延遲、截斷與人工修正時間。批次且不急的工作則可評估 Batch API 的五折價格。
若從 Opus 4.8 遷移，budget_tokens 與取樣參數不是新增限制，因為 Opus 4.8 已有相同限制。需要處理的是 Opus 5 預設開啟 adaptive thinking、停用 thinking 的 effort 上限、web fetch 缺口與 Priority Tier 不支援。
本文價格與功能依 2026 年 8 月 2 日的 Anthropic 官方公告與文件整理。模型規格、預覽功能、限時優惠與平台供應可能變動，正式採購前請重新核對官方定價、模型總覽與遷移指南。