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 拆成「固定背景＋今天添加」，别每次整包重读
