缓存 Token 是模型提供商从之前一次模型提供商请求中缓存的输入 Token，因此无需再次处理。当连续请求拥有相同前缀时，提供商会通过前缀缓存复用已有计算，并以低得多的费率计算缓存部分。这是长会话能够负担得起的关键机制——没有它，每个轮次都要重新为全部历史付费。
它之所以重要，是因为会话按这种方式计费。模型是无状态的，所以每次请求都会把完整对话——系统提示词、每条消息和每个工具结果——作为输入 Token 重新发送。到第 50 个轮次时，每次请求都携带 50 个轮次的历史；如果没有缓存，每次都要按原价为全部内容付费。缓存改变了这笔账：提供商已经在相同前缀中处理过的 Token 会按缓存 Token 计费，价格通常只有普通输入费率的十分之一甚至更低。在长会话中，发送内容的大部分都会成为缓存 Token，从而让费用维持在合理范围。
下面的例子说明 Token 何时命中缓存、何时不会。每个字母代表一块对话内容；每次请求都会发送截至当前的完整对话：
| 请求发送内容 | 缓存部分 | 按完整费率计费 | 原因 |
|---|---|---|---|
AB | nothing | AB | 第一次请求——没有可匹配的历史 |
ABC | AB | C | AB 是上一次请求的完全相同前缀 |
ABCD | ABC | D | 前缀仍然完整 |
AXCD | A | XCD | 一次编辑改变了 B to X；匹配从这里开始失效 |
缓存有一种特定的脆弱性：它要求前缀精确匹配。如果对话较早位置的任何内容发生变化——运行框架调整内容顺序、时间戳更新，或文件呈现形式改变——从变化点开始就会缓存未命中，之后的所有内容都按完整输入费率计费。缓存也会在闲置几分钟后过期，因此长时间暂停后恢复会话时，需要重新为历史付费一次。如果会话成本无明显原因突然上升，应在用量报告中比较缓存 Token 与输入 Token；缓存失效通常会最先在那里显现。
用法：
“长会话的成本太高了——一次重构花了 8 美元。”
“检查缓存 Token。如果运行框架在轮次之间重新排列系统提示词或文件，前缀就会失效，每次请求都得重新按完整输入费率付费。”