Claude Opus 5 發表｜Fable 5 半價的旗艦、thinking 預設開啟與 effort 限制

Anthropic 在 2026 年 7 月 24 日推出 Claude Opus 5，接替 Opus 4.8 成為 Opus 產品線的當家模型。價格維持 input $5 / output $25 每 1M tokens 完全沒動，但官方公布的評測數字多數項目超過了要價兩倍的 Fable 5。

Opus 5 已經是 Claude Max 方案的預設模型，也是 Pro 方案階層最高的選項。API 的模型 ID 是 claude-opus-5，Amazon Bedrock、Google Cloud 與 Microsoft Foundry 同日上架。這是 Anthropic 兩個月內的第四款模型，前面依序是 Mythos 5、Fable 5 與 Sonnet 5。

快速比較

與 Opus 4.8 的差異

項目	Opus 4.8	Opus 5
模型 ID	`claude-opus-4-8`	`claude-opus-5`
Input 價格	$5 / 1M tokens	$5 / 1M tokens
Output 價格	$25 / 1M tokens	$25 / 1M tokens
Context window	1M tokens	1M tokens
Max output（同步 API）	128K tokens	128K tokens
Max output（Batch API beta）	300K tokens	300K tokens
Thinking 預設	不帶 `thinking` 欄位就不思考	不帶 `thinking` 欄位就跑 adaptive
關閉 thinking	任何 effort 都可以	只有 effort `high` 以下可以
Effort 等級	low ～ max	low ～ max
Prompt cache 最低門檻	1024 tokens	512 tokens
Fast Mode	有（$10 / $50）	有（$10 / $50）
知識截止	2026-01	2026-05
Priority Tier	支援	不支援

價格、context window、max output 都跟 4.8 一樣，成本估算模型可以直接沿用。知識截止從 2026 年 1 月推到 5 月。4.6、4.7、4.8 三代的訓練資料截止都停在同一個時間點。

走 API 的話還有一個營運面的差異：Opus 5 的 rate limit 屬於獨立的額度池。Opus 4.8、4.7、4.6、4.5 共用一個合併的 Opus 額度，Opus 5 不從那個池子扣。把流量搬過來既不會釋放舊池的空間，也不會繼承舊池的上限，要先確認方案在 Opus 5 上的實際額度。Priority Tier 目前也還沒涵蓋 Opus 5，指定這個模型的 Priority Tier 請求會直接驗證失敗。

Claude 完整產品線價格對照

Opus 5 一般模式是 Fable 5 的一半價格，Fast Mode 則與 Fable 5 同價。單價都是每 1M tokens 美元：

模型	Input	Output	Context	Max output	定位
Fable 5	$10	$50	1M	128K	能力天花板，跨日的長時間自主任務
Opus 5（Fast Mode）	$10	$50	1M	128K	2.5× 速度，延遲敏感場景
Opus 5	$5	$25	1M	128K	複雜 agentic coding 與企業工作
Opus 4.8	$5	$25	1M	128K	上一代旗艦，仍可使用
Sonnet 5	$3	$15	1M	128K	速度與智能平衡，日常 agent 任務
Haiku 4.5	$1	$5	200K	64K	最快、成本敏感場景

Anthropic 官方給的分工建議是：日常商業應用與一般用途選 Opus 5，需要連續跑好幾天的長時間自主任務再上 Fable 5。Fable 5 的定位與安全分類器機制在 Claude Fable 5 發表整理有比較詳細的說明。

Benchmark 表現

官方公布的對照涵蓋 agentic coding、推理、電腦操作與知識工作四類。Frontier-Bench v0.1 測終端機環境下的 agentic coding、ARC-AGI-3 測沒看過的新題型推理、OSWorld 2.0 測操作真實電腦桌面、BrowseComp 測 agentic 搜尋、AutomationBench 測商業流程自動化。百分比越高越好：

Claude Opus 5 Benchmark 對照長條圖：Frontier-Bench 43.3%、ARC-AGI-3 30.2%、OSWorld 2.0 70.6%、BrowseComp 90.8%、AutomationBench 26.0%，五項皆高於 Opus 4.8 與 Fable 5 — Opus 5（藍色）五項評測都超過要價兩倍的 Fable 5，Frontier-Bench 與 ARC-AGI-3 的差距特別大。

Benchmark	Opus 5	Fable 5	GPT-5.6 Sol	Opus 4.8
Frontier-Bench v0.1（agentic coding）	43.3%	33.7%	34.4%	18.7%
ARC-AGI-3（新題型推理）	30.2%	—	7.8%	1.5%
OSWorld 2.0（電腦操作）	70.6%	66.1%	62.6%	55.7%
BrowseComp（agentic 搜尋）	90.8%	87.4%	90.4%	84.3%
AutomationBench（商業流程）	26.0%	17.4%	18.1%	17.0%
GDPval-AA v2（知識工作，Elo）	1861	1747	1736	1593

Frontier-Bench 從 Opus 4.8 的 18.7% 跳到 43.3%，是進步幅度最大的一項，同時也超過 Fable 5 的 33.7% 與 GPT-5.6 Sol 的 34.4%。ARC-AGI-3 的 30.2% 則是第二名 GPT-5.6 Sol（7.8%）的將近四倍，這項測的是模型面對訓練資料裡沒有的題型時能不能推理出規則，而不是靠模式比對。Opus 4.8 在這項只有 1.5%，等於幾乎沒有作答能力。

另外幾個 Anthropic 在公告裡提到但沒給絕對數字的比較：CursorBench 3.2 在 max effort 下與 Fable 5 差距在 0.5 個百分點以內，成本只要一半；OSWorld 2.0 用大約三分之一的成本就超過 Fable 5 的最佳成績；AutomationBench 即使在最便宜的 effort 設定下，也贏過其他競品的最佳成績。生命科學類評測全面優於 Opus 4.8，其中有機化學進步超過 10 個百分點。

這些都是廠商自己的測試環境跑出來的數字，第三方獨立驗證還沒出來。從實際使用的角度，比較值得留意的是 Anthropic 反覆強調的「每個完成任務的成本」而不是「每個 token 的成本」。Opus 5 需要的步驟數與工具呼叫次數比 Opus 4.8 少，所以帳單上的差距通常比單價差距更明顯。

API 端會直接報錯的兩個變更

以下兩點只有直接呼叫 API 或 SDK 的開發者需要處理，包含走 Amazon Bedrock、Google Cloud 與 Microsoft Foundry 的請求。用 claude.ai、Claude Code 這類現成 client 的話，這兩個參數由 client 自己決定，不會踩到。從 Opus 4.8 換到 Opus 5，模型 ID 之外還有兩件事要改，不改的話不是效果打折，是請求直接失敗或輸出被截斷。

Thinking 預設開啟

在 Opus 4.8 與 4.7 上，請求裡沒有 thinking 欄位就代表不思考。Opus 5 反過來：沒帶這個欄位的請求會跑 adaptive thinking。thinking: {"type": "adaptive"} 這個寫法本身沒變，變的是預設值。

這不只是行為差異，還是成本與截斷的問題：max_tokens 是 thinking 加上回應文字的總上限。原本在 Opus 4.8 上不思考、max_tokens 抓得剛好夠塞答案的工作流，切到 Opus 5 之後很可能思考佔掉大半額度、答案輸出到一半被截斷。每一條從來沒設過 thinking 的呼叫路徑都要重新檢視 max_tokens。

# Opus 4.8 時代：沒帶 thinking = 不思考，max_tokens 抓 4096 剛好
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    messages=[...],
)

# 同樣的寫法搬到 Opus 5：會跑 adaptive thinking，4096 可能不夠
# 要嘛把 max_tokens 加大
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[...],
)

# 要嘛明確關掉思考（但 effort 必須是 high 以下，見下一節）
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    output_config={"effort": "high"},
    messages=[...],
)

還有一件跟輸出有關的：Opus 5 不會回傳原始的思考內容。thinking.display 預設是 omitted，thinking 區塊照樣出現但文字是空字串；要拿到可讀的摘要就設 display: "summarized"。如果產品有把推理過程串流給使用者看，預設值會讓畫面在開始輸出前空白一段時間。

關閉 thinking 只能搭配 high 以下的 effort

thinking: {"type": "disabled"} 在 Opus 5 上只有 effort 是 high 或更低才接受，配 xhigh 或 max 會直接回 400。Opus 4.8 接受這個組合，所以任何在 4.8 上關掉思考又開高 effort 的路徑，遷移前都要先盤點。

Opus 5 的 thinking 與 effort 組合限制矩陣：thinking 開啟時五個 effort 等級都合法，關閉 thinking 時只有 low、medium、high 合法，xhigh 與 max 回 400 — 關閉 thinking 的請求只能停在 high 以下。

這個檢查是逐次請求做的。同一段對話裡前面幾次請求用 high 跑得好好的，後面某次把 effort 調到 xhigh 而 thinking 還關著，那一次就會被拒絕。所以要掃的是每一個呼叫點，不是只看對話開頭那次。

遇到這個限制時，多數情況比較好的處理不是把 effort 降回 high，而是把思考打開、改用 medium。Opus 5 在低 effort 的表現比前幾代好很多，延遲敏感的路徑用「thinking 開啟 + medium」通常比「thinking 關閉 + high」划算。

另外，關閉 thinking 在 Opus 5 上有兩個實測到的副作用，也是建議別關的理由。一是模型偶爾會把工具呼叫寫成使用者看得到的純文字，而不是結構化的 tool_use 區塊，這一輪會正常結束、不會報錯，但那個工具從來沒被執行，在 agent 迴圈裡還會留在對話歷史裡影響後續判斷。二是 <thinking> 標籤可能漏進正式輸出。如果因為延遲或成本必須維持關閉，在系統提示裡加一句「使用工具前可以先講一句話」能減少第一種狀況；第二種則要注意，寫「不要思考」「不要推理」這類指令反而會讓標籤外漏更嚴重，改用「不要在回應中包含內部或系統 XML 標籤」這種泛用寫法比較有效。

Effort 的選法

這章節 Claude Code 與 API 使用者都適用。Opus 5 支援完整的 low、medium、high、xhigh、max 五級，Claude Code 裡用 /effort 切換，走 API 則是 output_config.effort，兩邊的預設值都是 high。官方的起手式建議是 coding 與 agentic 工作用 xhigh、其他需要智能的工作用 high。

不過實際跑起來，Opus 5 在 low 與 medium 的表現相當突出，很多工作用一小部分的 token 與延遲就能拿到接近的品質。所以比較務實的做法是從建議值開始往下掃一輪。Claude Code 使用者可以把 /effort medium 當日常檔位，遇到真的難的重構或除錯再往上切；有評測集的開發者則值得把 medium、high、xhigh 各跑一次，看哪一級的品質仍可接受。從前一代模型沿用過來的 effort 設定，在 Opus 5 上多半不是最佳解。

只有走 API 要注意的是：effort 開到 xhigh 或 max 時記得把 max_tokens 拉大，起手抓 64K 再往下調。這兩級會在工具呼叫與 subagent 之間反覆思考，額度不夠就會出現思考佔滿、答案被截斷的狀況。Claude Code 會自己處理這個上限，不需要手動設。

最後一點兩者都成立：effort 不是控制輸出長度的旋鈕。想讓回應變短要靠提示詞，調低 effort 只會改變思考量，使用者看到的文字長度不一定跟著變。

Fast Mode

Fast Mode 在 Opus 5 上以研究預覽的形式提供，用大約 2.5 倍的輸出速度換 2 倍價格（$10 / $50）。Claude Code 裡打 /fast 就能開關，切過去用的仍然是 Opus 5，不會換成比較小的模型，只是輸出變快。

走 API 的話要用 beta 端點、帶 fast-mode-2026-02-01 這個 beta flag，並把 speed 設成 fast：

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    speed="fast",                      # 頂層參數，不是 header
    betas=["fast-mode-2026-02-01"],
    messages=[...],
)

# 回應裡的 usage.speed 會顯示這次實際用了哪一種速度
print(response.usage.speed)

Fast Mode 只在 Claude API 上有（含 Managed Agents），Amazon Bedrock、Google Cloud、Microsoft Foundry 都沒有，Batch API 與 Priority Tier 也不支援。它的 rate limit 跟一般 Opus 分開計算，遇到 429 可以照 retry-after 重試，或是拿掉 speed 退回一般模式，但要注意切換速度會讓 prompt cache 失效。

新增的 API 功能

自動 fallback 不用再指定替補模型

Opus 5 跟 Fable 5 一樣帶有安全分類器，被判定為高風險的請求會回傳 HTTP 200 但 stop_reason 是 refusal 的回應，內容可能是空的。直接讀 response.content[0] 的程式會在這裡拋出例外，所以要先檢查 stop_reason。

過去要接 fallback 得自己指定替補模型（fallbacks: [{"model": "claude-opus-4-8"}]）。Opus 5 新增了 fallbacks: "default" 的寫法，由 Anthropic 依照拒絕的類別自動挑替補，網路安全類別的拒絕會轉給 Opus 4.8。這個寫法用的 beta header 是 server-side-fallback-2026-07-01，跟指定陣列版本的 -2026-06-01 不是同一個，兩者交叉搭配會回 400。

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    betas=["server-side-fallback-2026-07-01"],
    fallbacks="default",               # 由 Anthropic 依拒絕類別挑替補
    messages=[...],
)

# 最終回應仍是 refusal 代表整條 fallback 鏈都拒絕了
if response.stop_reason == "refusal":
    handle_refusal(response.stop_details)

建議用 "default" 而不是自己釘一個模型：不同替補模型帶的分類器不一樣，正確的選擇取決於當初為什麼被拒絕；而且釘死的模型未來被淘汰時還得再改一次程式。Claude Fable 5 的 fallback 機制與實際觸發狀況在 Claude Max 用戶常駐 Fable 5 整理有比較完整的說明。

對話中途換工具不會讓 cache 失效

工具定義在請求裡排在最前面，所以過去只要動了 tools 陣列，整段 prompt cache 就全部失效重算。Opus 5 加了 beta 功能（header mid-conversation-tool-changes-2026-07-01），可以在回合之間增減工具而保留已快取的前綴。

做法是在 messages 裡插一則 role: "system" 的訊息，內容放 tool_addition 或 tool_removal 區塊。要能被加進來的工具必須事先在 tools 裡宣告並標上 defer_loading: True，先讓請求知道有這個工具，但不載入模型的上下文，等到 tool_addition 把它拉出來為止。

tools = [
    {"name": "get_weather", "description": "查詢目前天氣",
     "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}}},
    # 先宣告但不載入，等 tool_addition 才進上下文
    {"name": "get_forecast", "description": "查詢五日預報",
     "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}},
     "defer_loading": True},
]

messages = [
    {"role": "user", "content": "台北的天氣怎麼樣？"},
    # 中途把預報工具加進來，前面的 cache 不受影響
    {"role": "system", "content": [
        {"type": "tool_addition",
         "tool": {"type": "tool_reference", "name": "get_forecast"}},
    ]},
]

這跟 tool search 解決的是不同問題：tool search 是讓模型自己從一大堆工具裡找出需要的，重點在探索；對話中途換工具是應用程式自己決定工具集該變了（模式切換、某個資源剛好可用、要收回某個權限），重點在控制。

Prompt cache 門檻降到 512 tokens

可快取的最短前綴從 Opus 4.8 的 1024 tokens 降到 512。原本因為太短而放棄快取的 prompt，不用改任何程式就能建立快取條目了，Claude Code 這類現成 client 也會自動吃到這個好處。這個門檻在各代之間並不是單調遞減的：Opus 4.6 與 Haiku 4.5 是 4096、Opus 4.7 是 2048，所以一段 3K tokens 的 prompt 在 Opus 5 上會快取，在 Opus 4.6 上不會，而且不會報錯，只是 cache_creation_input_tokens 一直是 0。Prompt caching 的運作原理與省錢算法可以參考 Claude Code 節省 Token 與快取指南。

提示詞需要跟著調整的地方

這節對 Claude Code 使用者的影響最直接。以下幾點不會讓程式報錯，但為 Opus 4.8 調過的指令在 Opus 5 上會有不同結果，要調整的位置是 CLAUDE.md、自訂 agent 定義，或走 API 時的 system prompt。Opus 5 對明確指令的服從度很高，多半加一小段話就能校正回來。

回應變長：預設的使用者可見文字比前幾代長。實測加一句簡短的精簡指令，可以把長度縮短約兩成。如果系統提示本身很長，在結尾再補一行提醒會更有效。要注意這件事只能靠提示詞處理，調低 effort 沒用。
寫到磁碟的檔案也變長：跟對話冗長度是分開的兩件事。模型產出的報告、Markdown 文件、摘要普遍比前幾代長，如果產品會把這些檔案直接交付出去，需要另外指定長度標準。
自我驗證變成過度驗證：Opus 5 不用被要求就會檢查自己的產出。原本為了讓前幾代模型願意複查而寫的「完成後請驗證一次」「用 subagent 驗證結果」這類指令，現在反而會造成重複驗證。這裡要做的是刪掉而不是改寫，自建流程裡沿用下來的獨立驗證步驟也一樣。這跟一般提示工程「請模型自我檢查」的通則正好相反，如果團隊有共用的提示詞模板，這條要開例外。
會擴張任務範圍：有時候會多做使用者沒要求的步驟，或是自己判斷任務應該是什麼卻沒講清楚。加一段界定範圍的指示（照使用者要的範圍交付、認為做法有問題就講一句然後照原樣做完、確實做不到的部分明講）在實測中幾乎消除了這個現象，也不會換來一堆反問。
比較願意派 subagent：這點跟 Opus 4.8 的方向剛好相反。4.8 是傾向少派、需要提示才會委派；Opus 5 會主動派，而每個 subagent 都要重新建立脈絡、重新探索、回報，主 agent 再讀一次報告，成本與延遲會被放大。Claude Code 與自建 agent 都會受影響，當初為 4.8 寫的「多多委派」指引應該拿掉，並且加上明確的數量上限。
會詳細交代自己的更正：會把先前的小失誤標記出來並解釋一番，在使用者面前讀起來像在來回反覆。把更正限縮在會改變使用者結論或程式碼的那些就好。

還有一個 code review 場景的老問題在 Opus 5 上依然存在：如果稽核提示裡寫了「只回報高嚴重度問題」「保守一點」，模型會照字面執行，它一樣把 bug 找出來，但自己判斷沒到門檻就不報，結果測出來的 recall 反而下降。比較好的做法是要求它把所有發現都列出來並附上信心度與嚴重度，過濾交給後面的步驟做。

安全性

Anthropic 的自動化行為稽核把 Opus 5 列為對齊程度評分最高的模型，錯誤對齊行為的評分是 2.3。網路安全能力上仍然落後 Mythos 5，但比 Opus 4.8 強，而這部分並非針對性訓練的結果。

分類器的鬆緊度介於兩者之間：Opus 5 的網路安全類分類器比 Fable 5 寬鬆，預估攔截次數大約少 85%。對於做防禦性資安工作、生命科學研究這類容易被誤判的使用者來說，這個差距實際影響不小，Fable 5 上偶爾會被擋下來的正常請求，在 Opus 5 上多半能過。搭配前面提到的 fallbacks: "default"，就算被擋也還有轉圜。

各平台使用方式

claude.ai 與手機 App

Opus 5 是 Claude Max 方案的預設模型，打開就會用到，不需要手動切換；Pro 方案在模型選單裡也可以選到。Cowork 也同步支援。網頁版重新整理頁面、手機 App 更新到最新版並重啟一次就會出現。

Claude Code

# 更新 Claude Code
claude update

# 確認版本
claude --version

# 切換模型（如果不是預設）
# 在 Claude Code 裡輸入
/model claude-opus-5

# 調整 effort（coding 建議 xhigh）
/effort xhigh

# 開關 Fast Mode（輸出變快，模型不變）
/fast

Claude Code 裡的 effort 預設值是 high。Claude Code 的模型切換與版本退回方式可以參考 Claude Code 切換模型教學，入門用法則在 Claude Code 入門使用教學。

API 與雲端平台

Claude API：model 欄位設成 claude-opus-5，effort 預設 high
Amazon Bedrock：透過 Claude in Amazon Bedrock 使用 anthropic.claude-opus-5
Google Cloud：model ID 為 claude-opus-5，沒有前綴
Microsoft Foundry：同樣使用 claude-opus-5

Opus 4.8 沒有被下架，claude-opus-4-8 仍然可以繼續用。如果線上環境有依賴 4.8 的行為（特別是預設不思考這件事），可以先留在 4.8 把前面那兩個變更測過一輪再切。

該選 Opus 5、Fable 5 還是 Sonnet 5

複雜的 agentic coding、企業工作流：Opus 5 是目前性價比比較合理的落點。多數評測贏過 Fable 5，價格只有一半。要發揮它的長處，任務規格盡量在第一輪就講完整，讓它一次跑完，而不是分成好幾輪來回補充。
跨日的長時間自主任務：Fable 5 仍是官方建議的選擇。需要連續跑好幾天、脈絡累積極長的專案還是留給 Fable 5。
大量跑 agent、對成本敏感：Sonnet 5（$3/$15）在 8 月底前還有 $2/$10 的優惠價，日常自動化、CI 內的 code review 這類任務多半夠用，詳細對照可以看 Claude Sonnet 5 發表整理這篇。
延遲敏感的互動場景：Opus 5 Fast Mode（$10/$50）用 2 倍價格換 2.5 倍速度，適合 IDE 即時補完、客服機器人這類要即時回應的場合。非同步的批次工作流繼續走一般模式比較省。
單純當高品質 LLM 用：沒有要跑 agent 的話，繼續用 Opus 4.8 是合理的選擇，功能不會少，也不用處理 thinking 預設值改變帶來的那一串調整。新模型發佈不代表非升不可。

Claude 產品線這一年的演進與各代模型的分工，在 Anthropic 與 Claude 模型入門指南有完整的時間線整理。

參考資料

Introducing Claude Opus 5 — Anthropic 官方公告，含 benchmark 圖表、安全評估與客戶回饋
Models overview — Claude Platform Docs — 所有 Claude 模型的 ID、context window、max output、定價與知識截止
Model migration guide — Opus 4.8 遷移到 Opus 5 的完整破壞性變更與提示詞調整清單
Claude Opus 5 Outscores Fable 5 on Most Benchmarks — Decrypt
Claude Fable 5 發表整理 — Fable 5 的定位、安全分類器與 fallback 機制
Claude Opus 4.8 發表整理 — 上一代 Opus 的完整介紹與價格圖解

Post Views: 144