缓存 Token
Cache tokens
提供商从之前的模型请求中缓存下来的输入 Token，这样就不用重新处理。当连续请求共享一个前缀时，提供商通过前缀缓存复用这部分计算，并按低得多的费率计费。它是让长 Session 负担得起的关键杠杆——没有它，每一轮都要为整段历史重新付费。
这之所以重要，是因为 Session 的计费方式。模型是无状态的，所以每次请求都要把整段对话——System Prompt、每条消息、每个工具结果——作为输入 Token 重发。到第五十轮时，每次请求都携带五十轮的历史，而你每次都要为全部内容付全价。缓存改变了这笔账：在相同前缀中已经被处理过的 Token 会按缓存 Token 计费，通常只有输入 Token 价格的十分之一甚至更低。在长 Session 中，你发送的大部分内容都是缓存 Token，账单才保持在合理范围。
下面这个例子说明什么时候 Token 会被缓存、什么时候不会。每个字母代表一段对话内容；每次请求发送的是当前为止的对话：
| 请求发送 | 已缓存 | 全价计费 | 原因 |
|---|---|---|---|
| AB | 无 | AB | 第一次请求——没有可匹配的内容 |
| ABC | AB | C | AB 与上一次请求的前缀完全匹配 |
| ABCD | ABC | D | 前缀仍然完整 |
| AXCD | A | XCD | 一次编辑把 B 改成了 X；匹配在那里失败 |
缓存有一种特定的脆弱性：它只匹配完全相同的严格前缀。如果对话中较早位置的任何内容发生变化——Harness 重新排序了内容、时间戳更新了、文件的表示方式变了——缓存从该点开始就失效，之后的所有内容都按全价输入计费。缓存还会在几分钟不活动后过期，所以长时间暂停后恢复的 Session 要先为历史付一次全价。当 Session 成本没有明显原因地上涨时，去用量报告里比较缓存 Token 和输入 Token——缓存失效会先在那里显现出来。
用法：
“长 Session 的成本太夸张了——一次重构花了八美元。”
“看看缓存 Token。如果 Harness 在轮次之间重新排序 System Prompt 或文件，前缀就会失效，每次请求都要按全价输入重新付费。”