前言¶
2026 年 7 月 24 日，Anthropic 正式發佈 Claude Opus 5，並把它設爲 Claude Code 的默認模型。官方定位很直白：這不是公司最強的模型——頂層的 Claude Fable 5 仍負責極限任務——但 Opus 5 在編程與知識工作場景裏，能力已接近 Fable 5，價格卻只有後者的一半。
同一天，GitHub Copilot 也宣佈接入 Opus 5。編程代理賽道上，Anthropic 用「更強、更省、更落地」的組合，把日常開發工具鏈的默認水位又抬高了一檔。
發佈要點：誰該用、花多少錢¶
Opus 5 面向的是長時程、多步驟的 agentic 編程——改 bug、跨文件重構、在工具鏈裏連續調用，而不是單次補全。官方定價與 Opus 4.8 相同：
- 輸入：$5 / 百萬 token
- 輸出：$25 / 百萬 token
API 模型 ID 爲 claude-opus-5。主要規格如下：
| 項目 | 說明 |
|---|---|
| 上下文窗口 | 100 萬 token（默認即上限） |
| 最大輸出 | 128K token（Batches API 可達 300K） |
| 默認接入 | Claude Max 默認模型；Claude Pro 最強模型；Claude Code 默認 |
| Fast 模式 | 約 2.5 倍速度，價格爲基準的 2 倍 |
如果你已經在用 Claude Max / Pro 或 Claude Code，多數情況下無需額外配置即可獲得 Opus 5。Claude Code 裏也可顯式指定：
claude --model claude-opus-5
或在 shell 配置中寫入：
export ANTHROPIC_MODEL="claude-opus-5"
評測表現：Frontier-Bench 與 SWE-bench¶
Anthropic 在公告中重點引用了幾組面向真實軟件工程的評測，而非只看單次函數補全。
Frontier-Bench v0.1（74 項任務，可視爲 Terminal-Bench 2.1 的後續版本）是本次最受關注的指標之一。據官方與公開解讀：
- Opus 4.8：約 18.7%
- Opus 5（max effort）：約 43.3%
- Opus 5（xhigh effort）：約 44.4%（官方內部跑分中，xhigh 甚至略高於 max）
- 對比參考：Fable 5 約 33.7%，GPT-5.6 Sol 約 37.5%
也就是說，Opus 5 在 Frontier-Bench 上超過同期其他模型，相對前代 Opus 4.8 則是翻倍以上，且官方強調單任務成本更低。
在 SWE-bench 系列上：
| 基準 | Opus 5 | 備註 |
|---|---|---|
| SWE-bench Verified | 96.0% | 修復已驗證 GitHub Issue |
| SWE-bench Pro | 79.2% | Fable 5 約 80.0%，仍略高 |
| SWE-bench Multimodal | 59.4% | Opus 4.8 爲 38.4% |
此外，在 GDPval-AA、CursorBench 3.2 等知識工作與 IDE 向評測中，Anthropic 稱 Opus 5 達到新的 SOTA；CursorBench 3.2 在 max effort 下與 Fable 5 峯值相差 0.5% 以內，成本約爲一半。網絡安全方向仍由 Mythos 5 領先，Opus 5 未覆蓋該上限場景。
自適應思考與 effort 參數¶
Opus 5 相對 4.8 最大的 API 行爲變化，是自適應思考（adaptive thinking）默認開啓。
在 Opus 4.8 上，請求默認不思考，需顯式設置 thinking: {"type": "adaptive"} 纔會啓用。Opus 5 則反過來：同樣請求會自動進入思考模式，模型自行決定每輪推理深度；開發者用 effort 參數控制「想多深」。
可用檔位：low、medium、high（默認）、xhigh、max。
high：API 與 Claude Code 的默認值，兼顧質量與成本。xhigh：面向 30 分鐘以上的長時程 agent 任務；Frontier-Bench 上有時比max更優。max：追求極限質量，token 與延遲也最高。
官方建議：日常開發優先用 effort 調成本，而不是直接關掉思考——多數任務下，thinking 開啓 + low effort 往往優於 thinking 關閉。
遷移時需注意的破壞性變更¶
若仍要關閉思考，只能把 effort 設在 high 及以下：
{
"model": "claude-opus-5",
"thinking": {"type": "disabled"},
"output_config": {"effort": "high"}
}
在 xhigh 或 max 下搭配 thinking: {"type": "disabled"}，API 會返回 400 錯誤。另外，max_tokens 同時限制思考 token 與回覆 token，從 4.8 遷移時需重新評估預算。
GitHub Copilot 接入¶
GitHub 於 7 月 24 日同步宣佈：Claude Opus 5 已在 GitHub Copilot 中可用，面向需要複雜推理、工具調用與多步執行的編碼任務。
覆蓋範圍包括：
- Visual Studio Code、Visual Studio、JetBrains、Xcode、Eclipse
- Copilot CLI、Copilot cloud agent、Copilot app
- github.com 與 GitHub Mobile
訂閱方面，Copilot Pro+、Max、Business、Enterprise 用戶可在模型選擇器裏選用 Opus 5；Business / Enterprise 管理員需在 Copilot 策略中開啓對應模型權限。 rollout 爲漸進式，部分賬號可能稍晚看到入口。
對團隊而言，這意味着 Copilot 與 Claude Code 可以共享同一套 Opus 5 能力基線，便於在 IDE 插件與終端 agent 之間做 A/B 對比。
怎麼選：Opus 5 還是 Fable 5¶
Anthropic 自己的分層很清晰：
- 日常編程、企業知識工作、可預期的 agent 流水線 → Opus 5。性價比高，Frontier-Bench / SWE-bench 數據支持「接近頂層、成本減半」的敘事。
- 最高風險、最長自主運行、必須榨乾能力的任務 → 仍選 Fable 5。SWE-bench Pro 等個別項 Fable 5 仍有微弱優勢。
- 網絡安全紅隊與漏洞利用鏈 → Mythos 5 專屬賽道，Opus 5 不在此列。
落地建議：
- 先把 Claude Code / Copilot 默認切到 Opus 5，用自有倉庫跑一輪迴歸（構建、測試、典型 Issue）。
- 用
effort做成本掃描：從medium或high起，逐步下調直到質量跌破閾值。 - 對超長任務（>30 分鐘）試
xhigh，不必默認max——Frontier-Bench 數據表明「最高檔 ≠ 永遠最優」。 - 從 Opus 4.8 遷移時，檢查所有關閉 thinking 的調用路徑，避免與
xhigh/max衝突。
小結¶
Claude Opus 5 的發佈，核心不是又刷了一個榜單分數，而是把接近 Fable 5 的 agentic 編程能力壓進 Opus 價位，並同步推到 Claude Code 與 GitHub Copilot 兩條主航道。自適應思考默認開啓、effort 五檔可調、Frontier-Bench 與 SWE-bench 的大幅躍升，共同指向同一件事：編程代理正在從「嚐鮮功能」變成 IDE 裏的默認工作方式。
如果你已經在用 Claude Code 或 Copilot Pro+，現在值得做的只有一件——打開一個真實項目，讓 Opus 5 跑完一整條多文件任務鏈，再用 effort 量一下賬單。比任何 benchmark 數字都更能說明它是否該成爲你們團隊的新默認。
