Claude Code 中的 Opus 4.8：新功能、定價，以及如何在 2026 年切換

Ailoot 參考文件：ailoot.ai/docs/。

5 月 28 日 Claude Code 推出了什麼#

5 月 28 日，Anthropic 推出 Opus 4.8——距離 Opus 4.7 僅 41 天。Claude Code v2.1.154 和部落格文章〈在 Claude Code 中推出 Dynamic Workflows〉也在同一天發布。隔天，v2.1.156 修正了 thinking blocks 的錯誤，該錯誤會讓 Opus 4.8 上的 API 無法運作。

這四項變化會影響所有在 Claude Code 中寫程式的人：

1. 全新的 Opus 4.8 模型——價格相同（每百萬 token $5/$25），但基準測試成績更高，而且漏掉自己程式碼中錯誤的頻率降低了 4 倍。
2. Dynamic Workflows——Claude 會自行撰寫 JS 指令碼，單次執行累計最多啟動 1000 個子代理，同時活躍不超過 16 個。提示詞中出現 workflow 一詞就會觸發。
3. xhigh effort——新增的推理層級。Opus 4.8 的預設值現在是 high；遇到要求較高的任務時，可以調高到 xhigh。
4. Fast Mode 便宜了 3 倍——先前價格是標準價格的 6 倍，現在是 2 倍，速度則快 2.5 倍。

Anthropic 對這次發布的說法相當謹慎：

在這篇指南中，我會精確說明有哪些變化、實際使用的成本，以及你現在是否該切換，還是先等等。

Opus 4.8 和 4.7 有什麼不同？#

數據有哪些進步

Anthropic 在官方公告和 Claude API 說明文件中公布了基準測試。摘要如下：

⚠️ 這些是廠商公布的數據——來自 Anthropic，而非獨立測量。

主要承諾：「漏掉錯誤的機率降低 4 倍」

Anthropic 宣稱：

聽起來很棒，但背後有個細節：根據 Anthropic 的 System Card，在每一項基準測試中，Claude Opus 4.8 的錯誤回答比例都是六個模型中最低的，因為它在不確定時會拒答。

把 System Card 的說法翻成 vibe coder 的語言：模型並沒有變聰明 4 倍，而是更常說「我不確定，請確認一下」，而不是編出看似合理的幻覺。它變得更誠實，而不是 IQ 提升——這就是它的進步方式。

實際上，這表示遇到以前 Claude 會自信地亂說的相同任務時，現在它會說：「我不確定。」這能降低風險，但不會增加涵蓋範圍。

維持不變的部分

• 標準價格（每百萬輸入 token $5、每百萬輸出 token $25）——不變。
• 知識截止日期——和 4.7 一樣，是 2026 年 1 月。
• 預設 context——在 Anthropic API、AWS Bedrock 和 GCP Vertex AI 上為 1 million tokens；在 Microsoft Foundry 上為 200K。
• 最大輸出量——128K tokens。
• 取樣參數（temperature、top_p、top_k）——仍不支援；使用時會回傳 400 錯誤。

Opus 4.8 的不足之處

坦白說：在 Terminal-Bench 2.1 上，Opus 4.8 的得分是 74.6%——表現不差，但不是該類別的領先者。如果你的工作大多在終端機中完成，請記住這一點：Codex 在純終端機任務上通常略強一些。Opus 4.8 在其他基準測試中領先，但這項差異確實存在。

第二個坦白的重點：在輸入未經驗證的複雜代理式流程中（網站解析、RSS 閱讀），Opus 4.8 對 prompt injection 的防護並無保證。如果你正在建置會讀取他人文件的自動化流程，請另外加入輸入淨化器。

2026 年 Opus 4.8 要多少錢？#

價格級距

標準價格和 4.7、4.6 相同。這很少見——新一代模型通常會更貴。Fast Mode 便宜了 3 倍：在 4.6 和 4.7 上，快速模式的價格是標準價格的 6 倍；在 4.8 上則是 2 倍。

換算成每小時工作成本

在 Claude Code 中用 Opus 4.8 積極寫程式一小時，大約會用掉 1–2 百萬個輸入 token 和 10–30 萬個輸出 token。按標準價格計算，輸入費用是 $5–10，輸出費用是 $2.5–7.5。四捨五入後，單是 API 費用每小時約 $8–15。

訂閱方案：

• Pro（每月 $20）——每天足以積極工作 1–2 小時。單一要求較高的提示詞搭配 Dynamic Workflow，就會耗盡使用量限制。
• Max 5x（每月 $100）——每天可穩定工作 4–6 小時。這是大多數 vibe coder 的最佳選擇。
• Max 20x（每月 $200）——不必擔心使用量限制，足以工作一整天。如果你會啟動許多 workflow 或使用 Agent SDK，這就很合理。

更多細節請見指南：如何避免耗盡 Claude Code 使用量限制和token 都用到哪裡去了。

⚠️ Anthropic 提醒了一個重要細節：包含 1000 個代理的 workflow 會消耗「遠多於一般工作階段的 token」。即使同時不超過 16 個代理，大型執行仍可能消耗大量額度。啟動前應檢查可用用量並設定單次預算；並行數本身無法決定總成本。

⚠️ Pro／Max／Team／Enterprise 方案不包含 Fast Mode。你必須啟用使用額度，並另外付費；每百萬 token 為 $10/$50，需在訂閱費用之外支付。如果你使用 Max 並在沒有使用額度的情況下啟用 Fast Mode，系統會提示你需要儲值。閱讀說明文件時常會漏掉這一點。

Claude Code 中的 Dynamic Workflows 是什麼？#

Workflow 和子代理、Skill 有什麼不同

過去，Claude Code 自主執行的所有工作都採用逐回合協調。每一回合中，Claude 會決定要呼叫哪個工具，中間結果則留在它的 context 中。這種方式最多適用於 4–5 個子代理；再多的話，context 就會溢出。

Dynamic Workflow 改變了這種模式。Claude 會撰寫一段 JavaScript 指令碼，由指令碼自行協調代理。中間結果會留在指令碼的變數中，而非 Claude 的 context。只有最終結果會回到 context。這會帶來三種效果：

1. 你可以一次並行啟動最多 16 個代理，單次執行總計最多 1000 個。
2. Claude 的 context 不會溢出——每個子代理都在自己的沙箱中工作。
3. 指令碼可重複使用——成功執行後，在 /workflows 中按下 s，就能儲存為你的斜線指令。

Anthropic 的 workflow 說明文件是這麼說的：

執行環境限制

啟用 workflow 的三種方式

1. 在提示詞中使用 workflow 一詞。「執行一個 workflow，檢查 src/routes/ 下的每個 API endpoint 是否缺少 auth 檢查」。Claude 會看到觸發詞、撰寫指令碼並啟動它。
2. /effort ultracode——結合 xhigh 推理與自動 workflow 協調。它會套用到工作階段中所有實質任務。說明文件指出：

3. /deep-research [question]——內建的研究 workflow，會使用網頁搜尋並交叉核對來源。

範例：11 天內以 Bun 處理 750,000 行 Rust 程式碼

Bun 團隊使用 Dynamic Workflows 進行一項實驗：將 Bun 從 Zig 移植到 Rust。根據 Anthropic 部落格：

• 產生了 約 750,000 行 Rust 程式碼。
• 從第一筆 commit 到合併花了 11 天。
• 現有測試套件中 99.8% 的測試通過。
• 用於將 Zig 轉譯成 Rust 的規則有 約 300 條。

技術流程是連續執行三個 workflow：

1. Workflow #1 為 Zig 程式碼庫中的每個 struct 欄位找出正確的 Rust lifetime。
2. Workflow #2 將每個 .rs 檔案寫成其 .zig 對應檔的行為一致移植版本。數百項檔案工作分批處理，同時最多 16 個代理，每個檔案有兩位審查者。
3. Workflow #3 是修正迴圈：執行 build + test，直到全部通過。

最大陷阱：小任務也可能耗盡使用量限制

實務建議：如果任務只需 1–2 個簡單子代理，就不要呼叫 workflow；手動使用子代理即可。Workflow 適合 50 個以上的檔案，而不是 5 個。

Dynamic Workflow 是 context engineering 的下一步。Workflow 單次可累計啟動最多 1000 個代理，同時排程不超過 16 個。缺少專案共享 context 時，錯誤可能跨批次累積，因為各代理只看得到自己的一部分。

什麼時候該啟用 xhigh effort？#

在 Claude Code v2.1.154 的版本說明中，Anthropic 明確指出：Opus 4.8 預設以 effort=high 執行——這是發布後的新標準。先前的標準較低。新的 xhigh 層級可供最要求的任務使用，模型會在每一回合花更多 token 思考。

適合使用 xhigh 的時機：

• 遷移（採用新的架構模式，涉及 50 個以上的檔案）。
• 安全稽核（審查 200 個以上的 endpoint）。
• 有計畫的重構，並檢查不變條件。
• 複雜、耗時很長的除錯工作，模型需要記住整個流程。

不適合使用的時機：

• 單一檔案的例行編輯（撰寫測試、重新命名方法）。
• 結構清楚的簡單提示詞。
• 文件／註解——使用 xhigh 會增加成本。

在 Claude Code v2.1.154 中，effort 滑桿的名稱已從「Speed/Intelligence」改為「Faster/Smarter」。預設的 /effort high 現在會在底層自動套用，你不需要明確切換。

什麼時候該使用 Fast Mode？#

價格：

適合使用的時機：

• 回應時間比準確度重要的互動任務（直播中的即時程式碼審查）。
• 快速編輯與測試假設。
• 向客戶示範／提案。

不適合使用的時機：

• 長時間代理式工作——在 1M context 下，2 倍價格會讓成本效益變差。
• 大型 Dynamic Workflow——Fast Mode 將適用 token 費率加倍，各個已啟動代理用量也會累加。1000 個累計啟動上限，不代表任務成本固定乘 1000；應依實際總輸入與輸出編預算。
• 速度不重要的背景工作階段。

如何切換至 Opus 4.8，同時保留設定？#

步驟 1：更新 Claude Code

在終端機中：

claude upgrade

或依照 Anthropic 說明文件重新安裝。

⚠️ 目標版本為 v2.1.156 或更新版本。v2.1.154 有個錯誤：使用 Opus 4.8 時，thinking blocks 會被修改，導致 API 錯誤。這個錯誤已在 v2.1.156 修正。

檢查版本：

claude --version

步驟 2：在 /config 中切換模型

在 Claude Code 中：

/model claude-opus-4-8

或者開啟 /config → Model 區段 → 從清單中選擇 Opus 4.8。API endpoint 上的模型 ID 是 claude-opus-4-8。

步驟 3：啟用 Dynamic Workflows（Pro 方案）

Pro 方案預設會停用 Dynamic Workflows。開啟 /config → Workflows 區段 → 啟用。Max、Team 和個人 Enterprise 方案從一開始就已啟用。如果有管理員的 Enterprise 方案中停用了這項功能，請請管理員啟用。

步驟 4：執行測試

在 Claude Code 中要求執行一項簡單、結果明確的任務，確認模型能正常回應：

Write a TypeScript function that splits an array into chunks of a fixed length.
Give me tests in vitest.

如果回應合適，而且開頭出現「using claude-opus-4-8」這句話，就代表切換成功。如果出現 400 錯誤，請檢查 Claude Code 版本（回到步驟 1）。

不需要遷移的內容

• CLAUDE.md 可在任何模型上直接使用，無須修改。更多細節請見指南：如何設定 CLAUDE.md。
• Skills 會自動由 Opus 4.8 採用。更多細節請見指南：Claude Code Skills。
• MCP 伺服器的運作方式完全相同。MCP 指南：7 種現成組合。
• 子代理和 Plan Mode 維持不變。Skills、Subagents、MCP 和 Plugins 的選擇摘要，請見相關主題指南。

該從 Sonnet 4.6 或 Haiku 4.5 切換嗎？#

我已在較早的指南中介紹如何在 Sonnet 和 Opus 之間選擇，但當時談的是 4.7。Opus 4.8 出現後，選擇規則略有改變。

2026 年的決策矩陣：

對大多數 vibe coder 而言，最佳組合是預設使用 Sonnet 4.6，並透過 /model 切換器在要求較高的任務中使用 Opus 4.8。這樣可以少花錢，同時妥善處理要求較高的任務。

Opus 4.8 有哪些地方行不通？#

根據實務回報，Opus 4.8 有三個不足之處：

1. 大量資料的策略和產品路線圖。 實際使用回報顯示，分析工作仍以 4.7 為佳。如果你的主要用途是建立指標表並提出產品路線圖，先試試 4.8；如果不行，使用 /model claude-opus-4-7 切回 4.7。

2. 既有程式碼庫中的「最後 10%」。 模型很擅長從零開始處理新專案，但在改進舊程式碼時會遇到困難——例如邊界案例和架構中特有的細節。這是推理模型的典型弱點：擅長生成，卻不擅長替既有成果「收尾」。

3. 幻覺仍然存在。「漏掉錯誤的機率降低 4 倍」代表模型更常說「我不知道」，但 context 不足時，仍可能產生看似合理的捏造內容。專案脈絡能提供防護：CLAUDE.md 越完整，幻覺的空間就越小。

這不代表「不要更新」，而是要了解其限制，並把 Sonnet 4.6 和 Opus 4.7 留作備用。

Opus 4.8 之後會推出什麼？#

依照 Anthropic 的說法，「未來幾週」通常代表 4–8 週。換句話說，Mythos 級模型最可能在 2026 年 6–7 月推出。這會改變策略：

• 如果你目前的專案使用 Sonnet 4.6 或 Opus 4.7——更新到 4.8，並在特定任務中試用 xhigh 和 workflows。就價格而言，這是免費升級。
• 如果你打算使用 workflow 進行大型遷移——別急。再過一兩個月，可能就會推出更擅長這類工作的模型。你可以先在一個模組上進行實驗，了解它的運作方式。
• 如果你打算圍繞 Dynamic Workflows 重建基礎架構——先等等。Mythos 可能會改變底層模式。

這種不確定性是最重要的建議：保持彈性。Opus 4.8 是不錯的漸進式升級；Mythos 可能會是一次飛躍。可能有新模型推出前一個月，不要投入大規模改造。

繼續在 ailoot.ai 探索 Ailoot。