Claude 又出新模型了。

但這次真正值得看的，

不是：

Benchmark 又高多少。

而是：

同一件 AI 工作，到底能不能少花一點錢做完。

Anthropic 9 月 22 日正式推出：

Claude Opus 5.5。

它是新的 Claude 5.5 Family 第一個成員。

Anthropic 對它的定位很直接：

多數工作能力接近更高階的：

Claude Fable 5.1。

但是執行成本，

比上一代：

Claude Opus 5

低很多。

Opus 5.5 到底改了什麼？

先看最直接的 API 價格。

Claude Opus 5：

Input：

5 美元／100 萬 Tokens

Output：

25 美元／100 萬 Tokens

到了 Claude Opus 5.5：

Input：

4 美元／100 萬 Tokens

Output：

20 美元／100 萬 Tokens

兩邊都是：

便宜 20%。

如果只看這裡，

你可能會想：

那不就是打八折？

但真正變化最大的，

其實還不是這兩個價格。

Cache Read 從 0.50 美元降到 0.20 美元

對：

Claude Code。

Coding Agent。

長時間 Agent。

反覆讀同一個 Project Context

的人來說，

更重要的是：

Cache Read。

Opus 5 原本每百萬 Cached Tokens：

約：

0.50 美元。

Opus 5.5：

0.20 美元。

也就是：

下降 60%。

這個差別，

對一句話問答可能沒有那麼巨大。

但如果 AI 正在：

讀 Repository。

修 Code。

跑 Tests。

再讀結果。

再修改。

再跑一次。

成本結構就完全不同。

為什麼 Agent 特別吃 Cache？

假設你讓 Claude Code 修改一個功能。

第一輪，

它先讀：

CLAUDE.md。

專案規則。

API。

Controller。

Tests。

相關 Components。

這些內容可能已經累積：

10 萬 Tokens。

下一輪它跑 Test。

再思考。

它並不是只讀：

最新 Test Result。

整段 Conversation Context

還要一起帶進去。

第三輪又一樣。

所以一個 Session：

畫面上可能永遠沒有超過 12 萬 Tokens。

但整場工作加總起來，

實際處理的 Input：

可能是幾百萬 Tokens。

因為同樣 Context 被：

反覆讀取。

Prompt Cache 的作用，

就是讓已經看過的那一大段內容，

不要每次都按 Fresh Input 的價格重新計費。

Anthropic 自己的例子很直觀

Anthropic 用一個假設的 Claude Code Task 說明：

Session 最後 Context 成長到：

12 萬 Tokens。

如果總共跑：

40 Turns，

整個工作實際可能處理約：

280 萬 Input Tokens。

如果其中：

90%

可以從 Cache 讀，

Input Cost 約：

1.62 美元。

如果同樣工作只需要：

25 Turns，

成本又可以降到約：

1.02 美元。

這裡真正重要的不是這兩個金額。

而是：

AI 多繞一次路，也要錢。

所以「Token 便宜」只是第一層

Anthropic 對 Opus 5.5 的說法是：

在 Default Settings 下，

典型工作負載相較 Opus 5：

約便宜 40%。

為什麼不是只有 20%？

因為它認為新模型除了：

Token Price 比較低，

還可能：

用更少 Turns。

少一些錯誤方向。

少一些重做。

少一些 Output Tokens

完成相同工作。

但這個：

40%

是 Anthropic 自己根據 Typical Workloads 得出的估計。

不是保證你的工作一定少 40%。

真正要算的是 Cost per Task

這是 Opus 5.5 最值得學的一個概念。

一般人很容易比較：

模型 A：

Input 4 美元。

模型 B：

Input 2 美元。

所以模型 B：

一定比較便宜。

不一定。

假設模型 B：

先改錯一次。

再查另一個檔案。

重新修改。

再跑 Test。

又漏掉一個 Caller。

總共跑：

20 Turns。

模型 A：

一次先找到全部相依性，

10 Turns 完成。

最後：

單價高的模型

反而可能：

總成本比較低。

所以真正要看的是：

Cost per Completed Task。

不是：

Cost per Million Tokens。

Anthropic 甚至直接提醒：Retry 也有成本

如果你為了省 Token，

把 Effort 降太低，

結果 AI：

沒想完整。

漏掉檔案。

第一次修失敗。

接著再跑一次，

你原本省下的 Thinking Tokens，

可能一下就被：

Retry

吃回去。

所以使用 Opus 5.5，

不是永遠：

Effort 越低越好。

而是：

簡單工作少想。

困難工作多想一點。

避免整個任務重新來一次。

Opus 5.5 有不同 Effort Levels

在 Claude Code 裡，

Opus 5.5 可以調整：

Low。

Medium。

High。

XHigh。

另外還有一次 Session 可使用的：

Max。

Anthropic 自己的建議是：

一般範圍清楚的日常工作，

可以先從：

Medium

開始。

例如：

改一個 Feature。

Debug 幾個相關檔案。

Code Review。

如果發現：

只修到一層。

沒有追完整相依關係。

再往：

High

提高。

Low 適合什麼？

例如：

把同一個名稱改到多個檔案。

按照既有 Pattern 做 Mechanical Edit。

查 Log。

找某個 Function 在哪裡定義。

這些工作不一定需要：

大量 Thinking。

如果每一個 Rename

都開最高 Effort，

你是在花錢讓 AI：

想一件根本不用想那麼久的事。

High 又什麼時候值得？

例如：

API Field 已經改名。

Backend 改好了。

但還有：

Frontend。

Mobile。

Tests。

舊 Client。

Documentation

可能依賴它。

這種工作如果 AI 只看到：

眼前 File，

很容易：

局部成功。

整體失敗。

提高 Effort 的目的，

不是讓答案看起來比較長。

而是讓 AI 願意先：

找更多相依關係。

還有一個更省錢的方法：讓 AI 自己驗證

Anthropic 給了一個很實際的建議：

不要只叫 AI：

「改完。」

最好讓它有：

可以自己確認結果的方法。

例如：

Unit Test。

Build。

Lint。

API Test。

Validation Script。

原因很簡單。

如果模型改錯，

但自己可以立即跑 Test 發現，

它可能：

同一個 Session 直接修掉。

如果沒有驗證方法，

它可能很有自信地告訴你：

Done。

你隔天才發現：

壞了。

然後：

重開 Context。

重新解釋。

重新讀 Code。

重新修。

那才真正貴。

Opus 5.5 和 Fable 5.1 怎麼選？

這可能是現在 Claude 使用者最實際的問題。

Anthropic 自己在 Claude Code Cost Guide 裡，

把兩者分工講得很清楚。

Opus 5.5：

比較適合：

你會持續看著它工作的任務。

Feature Development。

Debugging。

Code Review。

幾個 Files 之間的修改。

Interactive Work。

因為：

速度較快。

價格較低。

你也可以在它偏掉時：

立即介入。

Fable 5.1 留給真正最難的工作

Anthropic 建議，

如果：

任務結果比 Token Price 更重要。

你不會一直監督。

問題沒有既有 Pattern。

需要多個 Subagents 協調。

是非常大型的改動。

或者：

Opus 5.5 High 已經在同一個問題：

卡兩次。

這時再換：

Fable 5.1。

Fable 5.1 的 API List Price：

Input：

10 美元。

Output：

50 美元。

相當於 Opus 5.5 的：

2.5 倍。

所以最簡單不是：

「Fable 最強，所以全部用 Fable。」

而是：

一般複雜工作先 Opus 5.5。

真的撞牆：

再升 Fable。

問題解完：

再切回來。

小任務甚至不一定需要 Opus

反過來也是一樣。

如果只是：

Search。

讀 Logs。

找檔案。

整理 Test Output。

簡單 Lookup。

Anthropic 建議可以讓：

Sonnet

或：

Haiku

負責。

尤其 Multi-agent Workflow 裡，

每個 Subagent

如果全部繼承昂貴模型，

最後帳單很容易放大。

比較合理的是：

便宜模型找資料。

Opus 5.5 做主要工作。

Fable 5.1 解真正困難問題。

這才叫：

Model Routing。

Cache 很便宜，但也不是永遠存在

Opus 5.5 的 Cache Read：

每百萬 Tokens：

0.20 美元。

只有 Fresh Input 的：

5%。

聽起來非常便宜。

但 Cache 並不是：

建一次永久免費讀。

Claude Code 不同付款方式下，

Cache Lifetime 也可能不同。

如果 Session 長時間停住，

下一次回來：

Cache 可能需要重新寫入。

而：

Cache Write

本身反而比 Fresh Input 更貴。

所以一個很實際的技巧是：

同一件工作盡量集中完成。

不要：

跑兩輪。

去喝咖啡很久。

回來重新熱 Cache。

再跑兩輪。

切換 Model／Effort 也可能讓 Cache 重建

另一個很容易忽略的地方是：

Changing Effort。

Thinking Settings。

甚至切換 Model，

都有可能讓：

原來的 Cache

無法繼續直接使用。

所以不要每兩分鐘：

Medium。

High。

Low。

再 High。

每次切換，

都可能帶來新的 Context Cost。

比較好的方法是：

做到一個：

Natural Break

再換。

例如：

Planning 完成。

準備進 Implementation。

或者：

現在這個問題確認 Opus 解不掉，

才升級。

Opus 5.5 還新增一個很實際的 Prompt Audit 概念

Anthropic 甚至提醒：

舊模型留下來的 Prompt，

可能讓新模型：

做很多不必要的事。

例如你以前為了讓模型可靠，

寫了：

一定要跑六個步驟。

每次都 Verify Twice。

每一輪都重新讀完整規則。

一定要輸出 Scratchpad。

到了新版模型，

這些 Ritual Instructions

反而可能造成：

更多 Output。

更多 Tool Calls。

更多重複工作。

Claude Code 現在可以利用：

Prompt Audit

檢查這類：

過時。

重複。

互相衝突

的 Instruction。

Anthropic 自己測了一個 44 Ticket Workflow

Anthropic 用一組：

44 個 Customer Support Tickets

做內部測試。

從 Opus 4.8 換到：

Opus 5.5 Low Effort，

成本約下降：

18%。

再清理 Prompt 中不必要的：

六步固定流程。

Scratchpad Rule。

Verify-twice Rule。

互相衝突的 Instructions

之後，

又多下降約：

9%。

最後相較原本：

約降低 25%。

這只是：

Anthropic 自己的一個 Benchmark Example。

不是說：

清 Prompt 就保證省 25%。

但它提醒一件很重要的事：

模型升級，Prompt 也要跟著整理。

最重要的工具反而可能是 /usage

如果你真的在 Claude Code 裡工作，

不要猜：

「感覺這版比較省。」

Anthropic 建議直接在 Session 結束後：

看：

/usage

或：

/cost。

你可以看到：

Input。

Output。

Cache。

Estimated Cost。

再拿：

同一種真實工作

分別跑：

Opus 5。

Opus 5.5。

比較：

用了幾個 Turns？

Output Tokens 多少？

Cache Hit 多高？

總成本多少？

不要拿一個玩具 Prompt 比模型

如果你的真實工作是：

修改 Laravel Project。

分析 20 份文件。

跑一個長 Agent Workflow。

那就拿：

真的工作

比較。

不要只問：

「寫一首關於貓的詩。」

然後根據一次 Token Count

決定公司往後模型策略。

真正應該做的是：

挑：

3～5 個每天會重複發生的 Task。

記錄：

Completion Rate。

Turns。

Review Time。

Tokens。

Cost。

最後才知道：

哪個 Model 真正比較划算。

安全方面也有一個明顯變化

Opus 5.5 是 Anthropic 公開談：

Pacing the Frontier

之後的重要新模型。

所以這次發布前，

Anthropic 找了：

METR。

Frontier Design

等外部團隊進行測試。

公司自己的 Containment Evaluation 顯示，

Opus 5.5 嘗試繞過既定 System Boundary 的情況，

比：

Opus 5

與：

Mythos 5.1

約少：

85%。

但一定要注意：

這不是：

「Claude 安全性提高 85%。」

它只是：

某一類特定安全評測結果。

高風險工作仍然不是因為模型新版就能全部放手

即使：

Benchmark 提升。

Safety Evaluation 變好。

也不代表：

Production Deploy。

付款。

刪除資料。

安全設定。

客戶承諾。

醫療。

法律。

金融決策

就可以：

完全不看。

模型越能自己跑完整任務，

反而越需要清楚知道：

哪個 Step：

可以自己做。

哪個 Step：

一定停。

Opus 5.5 的成本降低，

最合理的用途是：

讓更多適合交給 AI 的工作變得經濟可行。

不是：

把所有決策都交給 AI。

哪些人最值得試 Opus 5.5？

第一類：

Claude Code 重度使用者。

尤其是：

Session 很長。

Repository Context 很大。

Cache Read 很多。

60% Cache Read 降價最容易感受到。

第二類：

原本覺得 Fable 太貴的人。

如果你的工作不需要每次都用最高階模型，

Opus 5.5 可能提供：

更合理的能力／成本位置。

第三類：

企業 Agent Workflow。

每個 Task 一天跑：

幾十次。

幾百次。

甚至幾千次

時，

每 Task 少：

幾毛錢。

累積起來就會變成：

真正的預算差。

哪些人其實不用特別在意？

如果你只是：

每天偶爾問幾個問題。

摘要一段文字。

寫一封 Email。

做簡單 Brainstorm。

你真正的 Bottleneck

可能根本不是：

Opus 5.5 比 Opus 5

一百萬 Token 便宜幾美元。

這種工作，

甚至未必需要：

Opus。

不要因為：

「最新」

就永遠選最強模型。

AI 工具真正成熟的使用方式，

不是：

所有任務都上最高級。

而是：

每一種工作用剛好夠用的能力。

最後只記一個判斷方式

不要問：

「Opus 5.5 每個 Token 有沒有比較便宜？」

答案很簡單：

有。

真正應該問：

「我的這件工作，最後做完花多少？」

所以測試 Opus 5.5 時，

看四個東西就夠：

Turns

跑了幾輪？

Output

想了、寫了多少？

Cache

多少舊 Context 被便宜重用？

Retry

有沒有因為第一次失敗又重新做？

最後比較：

Cost per Completed Task。

這才是 Opus 5.5 真正值得看的地方。

AI 模型開始進入一個更成熟的競爭階段：

不是只問：

誰最聰明。

而是：

誰能用更少資源，把真正的工作可靠地做完。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀

今日 AI 工具｜2026/07/25：Claude Opus 5，適合處理長時間研究、複雜文件與需要反覆檢查的工作

今日 AI 工具｜2026/09/02：Claude Fable 5.1 上線，長時間 Coding／研究更強，重複讀取專案 Context 成本降 75%

AI 一分鐘教學｜2026/09/02：用 Claude Fable 5.1 前，先把 Prompt 拆成「固定背景＋今天新增」，別每次整包重讀