不一定。
假设你刚刚把 Claude Prompt Cache 设置好了。
第二次运行后一看：
cache_read_input_tokens
非常高。
你可能会很自然地想：
「太好了，这个 AI 工作现在一定便宜很多。」
方向可能是对的。
但还不能直接下结论。
因为 Prompt Cache 真正降低的是：
重复读取那一段既有 Context 的成本。
不是替整个 AI 工作打：
75% 折扣。
先搞懂 Cache Hit 到底证明什么
Claude API 会把输入使用量拆成几部分。
其中包括：
cache_read_input_tokens
代表这次从既有 Cache 读取的 Token。
cache_creation_input_tokens
代表这次创建新 Cache 的 Token。
input_tokens
则主要是没有从 Cache 读取、位于 Cache 后面的新 Input。
所以当你看到：
Cache Read 很高，
真正能确认的是：
这一次有大量 Prompt Prefix 没有重新按照一般 Input 价格处理。
这当然是好事。
但它回答的是：
「背景数据有没有成功重复利用？」
还没有回答：
「整件工作到底花多少钱？」
Fable 5.1 的 Cache Read 确实非常便宜
Claude Fable 5.1 目前每百万 Token 的一般 Input 价格是：
10 美元。
5 分钟 Cache Write：
12.50 美元。
1 小时 Cache Write：
20 美元。
Cache Read：
只要：
0.25 美元。
所以同样 100 万 Token，
如果真的已经存在有效 Cache，
从 Cache Read 取得，
确实比重新用一般 Input 处理便宜很多。
但你不能只看这一格。
因为模型还是要处理「今天添加的东西」
假设一个 Agent 每次工作都有：
100,000 Token 固定项目背景。
这次 Cache 全部成功命中。
很好。
但今天又加入：
50,000 Token 新文档。
这 50,000 Token 并没有因为前面的 Cache Hit，
自动变成 Cache Read。
它仍然是新的 Input。
所以真正的请求不是：
「100,000 Token 全部很便宜。」
而是：
固定背景便宜地重用＋今天新数据正常处理。
这两块都要算。
还有一块经常更贵：Output
Claude Fable 5.1 的 Output Token 价格目前是：
每百万 Token：
50 美元。
比一般 Input 更高。
所以你可能碰到一个很有趣的情况：
Prompt Cache 做得非常漂亮。
背景数据几乎全部命中。
但是你要求 AI：
产生超长研究报告。
写大量代码。
列出几十种方案。
反复解释每一步。
最后 Output 很长。
那么：
Input 省下来了，Output 帐单仍然可能很大。
所以「Cache Hit 很高」不能直接等于：
「这次 API 很便宜。」
更麻烦的是 Agent 不一定只调用一次模型
一般聊天可能是：
Input。
Output。
结束。
Agent 工作可能完全不同。
它可能：
读数据。
思考。
调用工具。
拿回结果。
再调用模型。
发现错误。
重新规划。
再用工具。
再调用模型。
最后整理结果。
因此你看到的其实不是：
一个 Prompt 的成本。
而是：
整条工作流程很多次推理加起来的成本。
有些迭代可以吃到 Cache。
但每一轮仍可能产生新的：
Input。
Output。
Tool Result。
甚至其他模型调用。
所以高 Cache Hit，可能只是代表「其中一部分做得很有效率」
可以想像一家印刷店。
每天都使用同一份：
品牌规范。
纸张规格。
印刷模板。
这些固定数据都已经准备好了。
今天不用刷新一次。
很好。
但第一个客户只要：
改一个日期。
很快完成。
第二个客户却要求：
重写全部内容。
产生 30 页。
修改 5 次。
重新校稿。
重新输出。
两件工作都用了：
完全相同的固定模板。
固定背景重用率一样高。
但最后总成本显然完全不同。
Prompt Cache 也是一样。
那 Cache Hit Rate 到底该怎么看？
Anthropic API 提供的是：
Cache Read Tokens。
Cache Creation Tokens。
一般 Input Tokens。
Output Tokens。
你可以利用这些 Usage 数字，
自己创建适合工作流程的 Cache 指针。
例如想知道：
这一次所有输入里，
有多少比例来自既有 Cache。
可以比较：
Cache Read Tokens
和：
整体 Input Token 结构。
但这是你创建的营运指针。
不要把它误认成：
「品质分数」。
Cache Hit 只是在描述：
Context 重复利用程度。
Cache Hit 也完全不代表答案比较正确
这一点更重要。
假设你 Cache 的是：
公司退款政策。
但那份政策其实已经过期。
接下来：
Cache Hit 100%。
代表什么？
代表 AI 非常有效率地：
反复读取同一份过期政策。
Cache 没有能力替你判断：
这份数据是不是最新版。
它只是让：
相同 Context
不用一直重新处理。
所以：
Cache 效率
和：
数据正确性
是两个完全不同的问题。
甚至可以「更便宜地做错很多次」
这就是最危险的误解。
假设一个客服 Agent 原本每次调用成本比较高。
加上 Prompt Cache 后：
成本下降。
于是公司开始让它：
每天跑更多次。
但它使用的：
产品规则错了。
Tool Definition 有问题。
分类逻辑错了。
或回答经常需要人工重写。
这时你可能得到：
非常漂亮的 Cache 指针。
API 单次成本也下降。
但公司真正得到的是：
更便宜地产生更多需要修改的结果。
这不叫真正的成本优化。
所以真正该看的不是「一次调用多少钱」
而是：
Cost per Usable Task。
也就是：
完成一件真正可以使用的工作，
到底花多少钱？
这比：
单次 API Cost
更有意义。
假设流程 A：
一次 API 成本 0.20 美元。
10 次里只有 5 次可以直接使用。
另外 5 次都要重跑或人工修改。
流程 B：
一次成本 0.30 美元。
10 次有 9 次可以直接使用。
只看：
单次 Token 成本，
A 比较便宜。
看真正完成的工作，
答案就不一定了。
这和我们之前谈 AI ROI 是同一个问题
之前 SasaDaily 已经谈过：
「AI 成果可直接用比例很高」
不代表 ROI 一定很好。
反过来也一样：
「AI Token 成本很低」
也不代表 ROI 一定很好。
因为公司真正付出的成本还有：
人工修改时间。
重新运行。
错误处理。
验证。
维护。
Agent 失败后的人工接手。
真正值得追踪的是：
整条工作最后有没有：
省时间。
省成本。
提高成功率。
或创造更多价值。
那应该同时看哪些数字？
如果你真的要评估 Prompt Cache 是否值得，
至少可以一起看五件事。
第一：
Cache Read Tokens。
固定 Context 到底有多少真的被重复利用？
第二：
Cache Creation Tokens。
是不是一直重新创建 Cache？
如果每次都 Cache Miss，
只是不断付 Cache Write 成本，
就要检查 Prompt 结构。
第三：
Output Tokens。
Input 省很多，
Output 是否反而愈来愈长？
第四：
成功率。
工作有没有真正完成？
第五：
人工修改量。
完成后是不是还要花很多时间修？
这五个一起看，
才比较接近：
真正的成本。
还有一个常被忽略的成本：Cache Miss
5 分钟 Cache 的 Write 价格，
对 Fable 5.1 是一般 Input 的：
1.25 倍。
1 小时 Cache Write 则是：
2 倍。
也就是：
创建 Cache 本身不是免费的。
你真正期待的是：
创建一次之后，
后续多次利用便宜的 Cache Read。
如果：
刚创建就过期。
Prompt 每次都改。
Prefix 一直变。
或使用频率太低。
结果可能一直变成：
Write。
Write。
Write。
却很少：
Read。
这时「有使用 Prompt Cache」
不代表「Prompt Cache 有省钱」。
5 分钟和 1 小时也不是愈长愈好
Anthropic 预设 Cache TTL 是：
5 分钟。
每次成功使用，
会重新刷新。
如果 Agent 在短时间连续跑很多步，
5 分钟通常就很合理。
1 小时 Cache 适合的是：
下一次需要同一段 Context，
经常会发生在：
5 分钟以后。
1 小时以内。
因为 1 小时 Cache Write 比较贵。
所以不能看到：
「1 小时保存比较久」
就直接全部改 1 小时。
真正该问：
我的工作多久会再次读同一份 Context？
如何知道 Cache 到底有没有真的命中？
不要猜。
Claude API 的 Usage 会直接提供：
cache_read_input_tokens
如果有数字，
代表这次真的从 Cache 读取。
如果：
cache_creation_input_tokens
和：
cache_read_input_tokens
都一直是 0，
就代表这份 Prompt 并没有真的被 Cache。
Anthropic 也提醒：
内容太短、没有达到最低 Cache 长度时，
系统可能直接正常处理，
但不会创建 Cache。
所以：
「我有写 cache_control」
也不等于：
「这次一定 Cache Hit。」
还要注意工具本身也可能影响 Cache
Agent 的 Context 不只有：
文字 Prompt。
还可能包含：
Tool Definitions。
Tool Results。
Web Search。
Browser。
Computer Use。
某些工具设置改变，
也可能影响前面的 Cache。
例如 Anthropic 官方指出，
激活或禁用 Web Search，
会让相关 System／Messages Cache 失效。
这代表：
Agent 架构愈复杂，
Cache Optimization 就愈不能只看：
「我的 System Prompt 有没有改。」
工具也属于 Context 的一部分。
所以什么才算真正好的 Prompt Cache？
不是：
Cache Read Tokens 永远最高。
而是：
该重复的东西成功重复。
固定的：
System Instructions。
Tool Definitions。
项目背景。
大型文档。
范例。
能稳定重用。
新的：
问题。
数据。
任务。
则正常处理。
最后整体：
成本下降。
延迟下降。
品质没有下降。
人工修改没有增加。
这才叫有效。
一个很实用的检查方式
如果你今天刚把 Prompt Cache 做好，
不要只比较：
昨天 0 Cache。
今天 80% Cache。
而是创建一个很小的比较表。
看：
每件工作总成本。
平均 Output。
成功完成比例。
需人工修改比例。
失败／重试次数。
Cache Read Tokens。
跑个：
20 次。
50 次。
甚至 100 次。
再看趋势。
因为真正的问题不是：
「Cache 有没有工作？」
而是：
「Cache 有没有让整个工作变得更有效率？」
最后回答今天的问题
Claude Prompt Cache Hit 很高，
是好信号。
它表示：
你的固定 Context 很可能正在被有效重复使用。
尤其 Fable 5.1 把 Cache Read 降到：
每百万 Token 0.25 美元后，
这对大型 Agent 确实可能带来很明显的成本优势。
但高 Cache Hit 本身不能证明：
总帐单一定最低。
工作一定成功。
Output 一定合理。
数据一定最新。
或结果一定可以直接使用。
真正该追求的不是：
最高 Cache Hit。
而是：
最低的「每件可用成果总成本」。
因为 AI 真正替你工作的时候，
你付钱买的不是：
Token。
你真正想买的是：
一件完成、正确，而且不用重新做的工作。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 快问快答｜2026/08/10：AI 成果「可直接用」比例很高，就代表 ROI 一定很好吗？
AI 一分钟教学｜2026/08/10：别只记 AI 成本，每次结果先标成「可用、需修改、失败」
今日 AI 工具｜2026/08/10：Langfuse，把 AI 每次花多少钱、跑多久、结果好不好记下来，不再只看总帐单
