Claude Opus 5.5 變便宜了。
但如果你真的用：
Claude Code
工作，
只知道：
「Input 每百萬 Token 4 美元」
其實幫助不大。
因為一個 Coding Task 最後花多少，
不是只由：
Token 單價
決定。
還包括：
Claude 跑了幾輪？
有多少舊 Context 從 Cache 讀？
Thinking／Output 用了多少？
是不是第一次做錯又重新來？
所以今天不教你：
怎麼算一堆 Token。
只學一個動作：
每次完成一個真正任務後，輸入 /usage。
接著只看三件事：
Cache。
Output。
Turns。
第一步：任務真的完成後，再看 /usage
例如你剛讓 Claude Code：
修一個 Bug。
修改三個 Files。
跑完 Tests。
確認功能正常。
這時不要只看到：
「Done」
就關掉 Terminal。
直接輸入：
/usage
Claude 官方也表示：
/cost
可以查看相同類型的 Session Usage 資訊。
其中會看到：
Input。
Output。
Prompt Cache。
以及 Estimated Cost。
如果你是 Subscription Plan，
裡面的美元數字主要是按照 List Price 計算的參考值，
不一定就是你真正收到的帳單。
所以今天不要執著：
「這次到底花 0.83 還是 0.91 美元。」
重點是：
哪一項特別異常。
第一格：先看 Cache
Claude Code 每一輪工作，
不只是讀：
「你剛剛新輸入的那一句。」
它還要帶著前面的：
Conversation。
Project Instructions。
Tool Definitions。
看過的 Files。
之前的 Tool Results。
繼續工作。
這些已經看過的內容，
如果可以從：
Prompt Cache
重複使用，
價格會比重新當成 Fresh Input 讀便宜很多。
Opus 5.5 的 Cache Read，
目前只有：
Fresh Input Price 的 5%。
所以長 Session 裡：
Cache Share 很重要。
長 Session 的 Cache 很低，要先找原因
Claude 官方建議，
如果一個很長的 Session：
Cache Share 卻偏低，
可以先檢查：
中間是不是停太久？
是不是切換 Model？
是不是改了 Effort／Thinking Setting？
是不是半途才接入新的 MCP Server？
因為這些情況都可能：
讓原本可以延續的 Cache
需要重新建立。
所以第一個問題很簡單：
「我明明一直在同一件工作上，為什麼舊 Context 沒有被大量重用？」
但 Cache 高，不代表這次工作就一定便宜
這點很重要。
假設你的 Cache Hit 很漂亮。
但 Claude：
來回跑了 40 Turns。
每一輪都要重新帶入一大段 Cached Context。
一次很便宜。
40 次加起來，
仍然是成本。
所以 Cache 只是：
第一格。
接下來一定還要看：
Output
和：
Turns。
第二格：看 Output 有沒有和工作大小相稱
Opus 5.5 的 Output，
每百萬 Tokens：
20 美元。
而 Cache Read：
每百萬只有：
0.20 美元。
也就是：
一個 Output Token 的價格，
大約是 Cache Read Token 的：
100 倍。
而且 Claude 的：
Thinking
也會計入 Output。
所以如果你只是要求：
「把這個 Variable Rename 到五個 Files。」
最後模型卻產生：
大量推理。
很多解釋。
一直查資料。
不停重新規劃。
那就值得看一下：
是不是：
Effort 開得太高。
小修改卻出現很多 Output，先不要怪模型價格
例如工作只是：
把舊 API Field Name
改成新名字。
既有 Pattern 很明確。
沒有架構決策。
沒有複雜除錯。
這種 Mechanical Task，
Claude 官方建議可以考慮：
較低 Effort。
因為真正需要的不是：
模型思考十分鐘。
而是：
按照已知規則完成修改。
如果這種小任務卻產生大量 Output，
先問：
「是不是我讓它想太多？」
但困難工作不要為了省 Output 硬降 Effort
反過來也一樣。
假設一個 Bug：
牽涉 API。
Frontend。
Database。
Tests。
你硬把 Effort 降低。
結果 Claude 第一次只修 Backend。
第二次才發現 Frontend。
第三次又發現 Test。
那原本想省下的 Thinking，
最後可能全部被：
Retry
吃回去。
Anthropic 特別提醒：
一次 Retry 的成本，
可能比前面少用一點 Thinking
更高。
所以不要看到：
Output 很多
就機械式全部降 Effort。
先看第三格：
Turns。
第三格：Total Input 為什麼比 Conversation 大那麼多？
這是 Claude Code 最容易被誤解的一點。
假設你看到目前 Conversation：
大約只有：
12 萬 Tokens。
你可能以為：
「那這個 Session 最多就讀了 12 萬。」
不是。
因為每一個 Turn，
都會再次帶著前面的 Context。
Anthropic 舉的例子是：
Session 最後只有：
12 萬 Tokens。
但跑了：
40 Turns。
累計 Input 可能達到：
280 萬 Tokens。
所以 /usage 裡：
Total Input
如果遠遠大於你現在看到的 Conversation Size，
通常代表：
這件事跑了很多輪。
Turns 多，先回頭看它到底卡在哪裡
不要第一個反應就是：
「模型太貴。」
先翻一下 Session。
常見狀況可能是：
讀一個 File。
↓
改。
↓
跑 Test。
↓
失敗。
↓
再讀另一個 File。
↓
改。
↓
再 Test。
↓
才發現還有第三個 Caller。
這就是：
Loop。
而每一圈，
都重新帶著之前的 Context。
所以 Anthropic 有一句很值得記：
最便宜的 Turn，是根本不需要發生的那一 Turn。
怎麼少掉不必要的 Turns？
最實用的方法之一不是：
換便宜模型。
而是：
讓 Claude 有辦法自己驗證。
例如開始前就告訴它：
修改完成後執行：
Test。
Build。
Lint。
API Validation。
如果第一輪改錯，
模型可以：
立刻看到 Fail。
馬上修。
而不是：
它說 Done。
你人工測試。
發現錯。
重新開 Session。
再把 Context 全部交代一次。
真正省下的，
可能不是：
單一 Token。
而是：
整個第二輪工作。
所以今天只做一張「三格檢查」
不用 Excel。
不用 Dashboard。
一個真實任務結束後，
輸入：
/usage
然後問三件事。
Cache
長 Session 的舊 Context 有沒有大量被重用？
如果很低：
找長時間中斷、
Model／Effort 切換
或其他可能讓 Cache 重建的原因。
Output
產生的推理與文字，
和任務難度相稱嗎？
如果只是 Mechanical Task 卻非常高：
下次可以測試較低 Effort。
Turns
Total Input 是否遠高於 Conversation Size？
如果高很多：
回去找模型在哪一段：
反覆讀、
反覆改、
反覆驗證。
舉一個很簡單的例子
今天任務：
「把 API 的 customer_name 改成 client_name。」
最後：
Tests 全部通過。
接著看 /usage。
情況 A
Cache 高。
Output 不多。
5 Turns 完成。
那就很正常。
不需要為了：
「再省 0.1 美元」
把 Workflow 搞得更複雜。
情況 B
Cache 很高。
但跑了 25 Turns。
那問題可能不是 Cache。
而是：
Claude 一直分批發現 Dependency。
下次可以：
先要求它找出所有 Call Sites，
再一起修改。
情況 C
只有幾個 Files。
Turns 也不多。
但 Output 特別高。
那可能要檢查：
Effort 是否超過任務需要。
情況 D
長時間工作，
Cache Share 卻很低。
那就檢查：
中間是不是停太久、
切 Model、
改 Effort
或改變其他會重建 Prompt 的設定。
不要每次看到成本高，就立刻換小模型
這也是今天最重要的一點。
如果問題其實是：
Turns 太多，
換成便宜模型之後：
可能還是跑很多 Turns。
甚至因為能力不夠：
跑更多。
如果問題是：
Cache 一直失效，
換模型也沒有解決：
Workflow 中斷。
如果問題是：
Output 太高，
也可能只要：
調整 Effort。
所以：
先找成本來源。
再決定要不要換模型。
這跟 8 月那篇「20 題模型測試」不一樣
如果你正在決定：
要不要從昂貴模型整批換成便宜模型，
SasaDaily 之前教過：
用同一組 20 個代表案例，
比較：
成本。
正確率。
修改時間。
那是在做：
Model Selection。
今天這一招處理的是另一件事：
你已經在用 Claude Code。
某個真實 Session 看起來特別貴。
要先回答：
「到底是哪裡燒掉成本？」
所以不是：
先 A/B Test 模型。
而是：
先診斷自己的 Workflow。
/usage 最有價值的時候，是每次都看同一種工作
例如你每週都會：
修 Bug。
做小 Feature。
更新 API。
Review PR。
不要拿：
一次 5 分鐘 Rename
跟：
一次 3 小時 Migration
比較。
最有價值的是：
同一種工作做完後，
每次都快速看：
Cache。
Output。
Turns。
慢慢你會知道：
這類 Task 正常大概長什麼樣子。
某一天突然高很多，
才知道：
值得檢查。
AI 成本不是越低越好
真正目標不是：
讓 /usage 的數字變成最低。
而是：
用合理成本把工作一次做對。
一個 1 美元的 Session：
完全做完。
Tests 通過。
只要 Review 5 分鐘。
可能比：
0.50 美元的 Session
更划算。
如果後者：
做錯一次。
重跑一次。
還要人工修半小時。
所以最終還是要回到：
Final Usable Output。
不是：
誰的 Token 最省。
今天只記這個動作
Claude Code 真正完成一件工作後：
輸入：
/usage
然後看：
Cache：舊 Context 有沒有好好重用？
Output：是不是花太多在 Thinking／生成？
Turns：是不是一直繞圈？
先找到：
錢花在哪裡。
下一次才知道應該：
降 Effort。
補 Test。
減少重複 Turns。
保持 Cache。
還是真的需要換 Model。
AI 成本優化最容易做錯的一件事，
就是：
看到單價，還沒看 Workflow，就先換模型。
如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 快問快答｜2026/09/02：Claude Prompt Cache Hit 很高，就代表這個 AI 工作一定比較便宜嗎？
AI 一分鐘教學｜2026/09/02：用 Claude Fable 5.1 前，先把 Prompt 拆成「固定背景＋今天新增」，別每次整包重讀
