沒人談過的 Opus 5 設定，正悄悄讓你多花錢

Opus 5 讓「深度思考」變便宜了——這件事，將改寫你的架構思維

今天幾乎每一篇談 Opus 5 的文章，講的都是同一件事：在 Frontier-Bench 上達到業界頂尖，在 CursorBench 上以一半的價格逼近 Fable 5。這些數字沒有問題。但底下還藏著一個更有意思的故事：當一個模型變得這麼擅長判斷何時該思考、何時直接回答，你的基礎設施帳單會發生什麼事。

Opus 5 今天上線，價格與 Opus 4.8 相同，每百萬 token 輸入 $5、輸出 $25。同樣的價格、明顯更高的智慧水準、1M token 的上下文視窗，以及在 API 與 Claude Code 中預設為 high effort 的 adaptive thinking。這個細節值得停下來想一想，因為它的性質與其說像一個 benchmark 數字，不如說像一種計費行為。

重點在 effort

藏在發布說明裡、多數報導一筆帶過的，是這麼一個設定：adaptive thinking 預設為 high effort，而且在 API 與 Claude Code 中都是預設開啟。沒有人需要動手打開它，除非團隊明確設上限，否則它就是這樣跑。

這個預設值不是小細節。CodeRabbit 的測試給了它一個具體數字：每一次 review 呼叫，Opus 5 平均讀入約 60.5k 輸入 token、寫出約 9.5k 輸出 token；相對地，GPT-5.6 執行同樣任務約為輸入 40.5k、輸出 5.8k。

以 Opus 5 輸入 $5、輸出 $25 的定價來看，在任何人動到 effort 旋鈕之前，這些多出來的 token 量就已經替每一次呼叫加上了實實在在的溢價。

對聊天介面來說，這個差異看不見。但對一個每天跑數千次呼叫的正式環境 agent 來說，它會成為整個技術堆疊中最大的成本變數之一，而且從團隊開始使用這個模型的那一刻起，它就已經是「開啟」狀態。

獨立測試證實了這個取捨

CodeRabbit 從開源 pull request 中挑出約 100 種已驗證的錯誤樣態，讓 Opus 5 跑過一輪，並將不同 effort 等級與他們正式環境的 reviewer 組合互相比較。他們的數字讓 effort 預設值有了可量化的份量。在 x-high effort 下，Opus 5 產出的可執行建議比基準線更乾淨，精確率 39.3% 對 35.2%，但抓到的已知問題較少，55.2% 對 61.1%。更高的 effort 是用覆蓋率換來精確率，而且這個取捨在他們多輪測試中一致成立，並非全面同步變好。

成本溢價有相當一部分來自 token 用量，因為每次呼叫都帶著更大的脈絡進去、也帶著更長的回答回來。

effort 的擴展並不是線性的，而是起伏不定。medium effort 的配置整體抓到最多問題，但產生了 110 條吹毛求疵的意見，全串流精確率也較低。high effort 寫出的輸出比 medium 少，x-high 反而寫得更多，所以若假設 effort 越高就一定代表答案更好或更貴，那會是錯誤的解讀。在 x-high 下，瑣碎意見的數量比基準線多出約四倍，這對那些會先過濾輸出、再交給開發者或另一個 agent 的下游使用者來說，這意味著要花更多時間審閱。

把資安 fallback 當成一個路由決策來讀

Anthropic 讓 Opus 5 會自動把資安敏感的提示轉送及導向到 Opus 4.8。多數報導單純把這件事框成安全功能，但它同時也是一個發生在推論堆疊內部的路由決策，值得一開始就在基礎設施層規劃進去。

如果一個 agent 偶爾會碰到程式碼審查、日誌分析，或任何與漏洞利用沾邊的工作，那麼一部分 Opus 5 流量就會落到 Opus 4.8 上，而後者有自己的成本與延遲樣貌。如果團隊只單獨測試過 Opus 5 就直接部署到正式環境，最好提早把這條 fallback 路徑算進成本模型，否則正式環境跑出來的數字，會和乾淨的測試結果差很多。同樣的模式在 Fable 5 上也出現過：良性的資安工作偶爾會觸發更嚴格的防護機制，不過在 Opus 5 上發生的頻率較低。

用基礎設施工程師的角度讀 benchmark

Anthropic 公布的數字顯示，在 OSWorld 2.0 上，這是一個以電腦操作、而非純推理為核心的 benchmark，Opus 5 在任何給定的成本點都勝過所有模型，並以約三分之一的成本超越 Fable 5 的最佳成績。對任何要打造操作工具、瀏覽器或終端機的 agent 的人來說，這個數字值得優先關注，因為它既是智慧宣稱，也是成本效率宣稱。「聰明的模型」和「每一塊錢換到多少聰明」是兩種不同的產品，而 OSWorld 2.0 量的是後者。

有機化學與蛋白質功能的進步，分別比 Opus 4.8 高出 10.2 與 7.7 分，這類數字通常被程式碼 benchmark 蓋過去，但對服務生命科學工作負載的團隊來說，這個進步很有份量。這代表訓練資源投入了許多競爭者大致跳過的領域。

建構者 vs. 審查者：兩種不同的工作

Opus 5 作為建構者，比作為審查者更有說服力。他們有一位工程師形容它比先前的 Opus 系列更「沉得住氣」，會花時間釐清目標，並在開放式專案上提出好幾種可行方案。在較大型的 agentic 任務上，它協調了數百個背景 agent，設計判斷力優於 Opus 4.8，不過在與資安相關的工作上，它仍比 Fable 5 更慢、更謹慎。

作為審查者，Opus 5 x-high 讀起來更像專科醫師而非全科醫師。它在設定錯誤與程式碼品質上很強，能敏銳看出整合細節與可維護性問題，但在邏輯錯誤、競爭條件與 API 誤用上較弱。這讓它適合在偏重正確性或偏重併發的變更上，搭配一個覆蓋導向的審查者一起提供第二意見，而不是單獨上陣。

社群在意的是什麼

發布前聲量最大的討論，與其說是在談能力，更多是圍繞在命名與信任上。好幾週的爆料串猜測 Anthropic 可能完全跳過 Opus 5 這個名字，改用 Mythos 這一階。這種揣測反映了某種熟悉的心情：開發者記得那些在幾乎沒有預告的情況下改變了模型個性與格式行為的版本，例如有些人在 Opus 4.7 注意到的、更正式的備忘錄式輸出，讓偏重寫作的工作流程跑出了與預期不同的結果。

等塵埃落定後，社群真正關心的是：這個模型在規模化之下行為是否可預測，以及預設的 effort 等級是否符合團隊原本編列的預算。

如果你在 GMI Cloud 上開發，這代表什麼

選模型，正逐漸變成選 effort 等級。能從 Opus 5 榨出最好經濟效益的團隊，都是那些會去剖析自家流程中哪些環節真的需要高 effort 推理、哪些環節可以轉移到現在已經有的更便宜、也夠好用的選項。

GMI Cloud 讓 Opus 5 與其他 200 多種模型，都能在專為混合 effort、混合模型路由打造的 GPU 基礎設施上運作。

在正式導入前，先在自家流程上測試 Opus 5 的簡短檢查清單：

• 把你打算使用的每一個 effort 等級都測過，包含 low 與 medium，不要假設 effort 越高就會線性變好

• 比較嚴格限制的提示詞與「先廣泛回報再過濾」的做法，因為過窄的指示可能壓掉有用的發現

• 在開發者習慣略過雜訊之前，先調好簡潔度與嚴重度設定

• 量測驗證指示對執行時間、token 與成本的影響，把不值得的部分刪掉

• 依類別與嚴重度拆解漏掉的問題，才知道該把第二個覆蓋導向的模型擺在哪個位置

用 curl 試試看：

curl https://api.gmi-serving.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $GMI_API_KEY" \
-d '{
"model": "anthropic/claude-opus-5",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Hello!"}
]
}'

把最難的推理工作交給 Opus 5，其餘的則分配給定價符合該任務所需 effort 等級的模型。這才是現在的重點，與這禮拜誰在排行榜上奪冠是兩回事。

在 GMI Cloud 上試用

Opus 5 提供 OpenAI 相容的 API，也就是說，只要團隊已經透過 GMI Cloud 的 serverless 推論在呼叫 LLM 端點，改一行模型名稱就能換成 Opus 5，這也是 GMI 一路以來支援整個 Claude 系列的相同模式。

先到 console.gmicloud.ai 的 playground 跑一段提示詞，接著用 serverless API 做用多少付多少的測試，並在投入專屬部署前，先針對工作負載本身量測 token 用量、延遲與成本。