Claude Code 长任务里，Prompt Cache 命中率会直接影响成本和速度。很多人只知道“缓存能省 Token”，但不清楚哪些操作会让缓存突然失效。
理解它并不难：每次请求都可以看成一条从左到右的上下文链条：
|
|
越靠左的内容越稳定，缓存收益越大；越靠左的内容一变，后面的缓存也更容易跟着失效。反过来，越靠右的内容变化，影响范围越小。
所以优化 Claude Code 的 Prompt Cache，不是靠玄学，而是靠一个原则：任务开始前把模型、MCP、Skills、CLAUDE.md 等基础上下文准备好，任务中途尽量不要改。
Prompt Cache 缓存的不是文字本身
Prompt Cache 不是简单地把提示词字符串存起来。对 Transformer 模型来说，更关键的是前缀上下文经过注意力层计算后的 Key/Value 状态，也就是常说的 KV cache。
这意味着两个事实：
- 同一段上下文，只要前缀保持稳定，就可以在后续请求中复用一部分计算结果。
- 如果模型、工具定义、系统提示词或前缀消息发生变化，之前的缓存就可能无法复用。
Anthropic 官方文档也把失效层级概括为 tools -> system -> messages。工具定义变化会影响整段缓存，系统层变化会影响 system 和 messages，messages 层变化则主要影响消息缓存。
Claude Code 里还会额外涉及 CLAUDE.md、Skills、MCP、插件和子代理等上下文，所以实际使用时更容易踩到缓存失效点。
缓存杀手一：中途切换模型
切模型是影响最大的操作。
Prompt Cache 是按模型隔离的。Opus、Sonnet、Haiku 这类模型的结构和权重不同，同一段文本算出来的 KV cache 也不同。你在 Opus 里跑了很长上下文，再切到 Sonnet，并不能让 Sonnet 复用 Opus 的缓存。
这会带来一个反直觉结果：中途为了省钱切模型，可能反而让前面已经积累的缓存全部失效。原本可以按 cache read 价格读取的上下文，需要重新写入和计算。
更稳妥的做法是：
- 主对话尽量固定一个模型。
- 需要便宜模型处理支线任务时，用 subagent 隔离出去。
- 让支线代理完成搜索、探索、整理，再把结果摘要交回主对话。
这样主对话的长上下文尽量不动，缓存命中率更稳定。
缓存杀手二：中途新增 MCP 或重载插件
MCP 会向 Claude Code 提供工具。新增 MCP 服务器后，工具列表会变化，而工具定义处在上下文链条最左侧。
从 Prompt Cache 的角度看，工具列表一变，后面的 system 和 messages 都可能需要重新计算。尤其是 MCP 很多时，工具定义本身就可能占用大量 Token，缓存失效的代价会很明显。
不过有一个细节：Claude Code 通常在会话启动时读取 MCP 配置。你中途改了配置，当前 session 不一定立刻受影响。真正需要小心的是触发重新加载的动作，例如重启、恢复会话、重新加载插件或让工具列表重新组装。
建议是：
- 开始长任务前，一次性装好需要的 MCP。
- 不要做一半才发现缺工具，再安装并重载。
- 对大型 MCP 工具集，优先考虑按需加载或减少默认启用数量。
- 不常用的 MCP 不要长期挂在默认配置里。
如果工具定义稳定，Prompt Cache 才有长期命中的基础。
缓存杀手三：中途修改 CLAUDE.md
CLAUDE.md 是 Claude Code 的项目记忆文件，适合放构建命令、测试命令、架构约定、代码风格和项目注意事项。
它对 Claude Code 很有用，但也会进入上下文。官方帮助文档说明，CLAUDE.md 会在 session 开始时读取，并作为用户消息提供给 Claude；它也会使用 Anthropic 的 Prompt Cache。首次请求会按完整输入计费，后续请求如果在缓存有效期内命中，就按更低的 cache read 成本处理。
问题在于：CLAUDE.md 是内容寻址的。你一改文件内容，旧缓存就对不上了。
所以不要在长任务中途频繁改 CLAUDE.md。更好的方式是：
- 任务开始前先检查
CLAUDE.md是否够用。 - 把稳定规则写进去，把临时指令放在当前对话里。
- 如果只是一次性任务，不要为了临时需求修改长期记忆文件。
- 如果必须改，最好在一个阶段结束后再开始新 session。
CLAUDE.md 应该是稳定的项目说明，而不是每轮任务都改的便签。
缓存杀手四：中途安装或更新 Skills
Skills 也是上下文的一部分。安装新 Skill、更新 Skill，或者让 Skill 列表发生变化，都会让注入到会话里的上下文不同。
这类变化通常不会在当前 session 里立刻完整生效，而是在重新加载、恢复会话或新开会话时体现出来。问题是，一旦重新组装 messages，旧缓存就可能命中不了。
建议和 MCP 类似：
- 开始任务前先确认需要哪些 Skills。
- 同一类任务尽量固定 Skill 集合。
- 不要在一个长任务中途边做边装 Skill。
- 如果安装了新 Skill，最好把它当成新阶段的开始。
对经常做内容生产、代码审查、部署、翻译的工作流，可以把常用 Skills 固定下来，让上下文结构尽量稳定。
缓存杀手五：空闲时间超过 TTL
Prompt Cache 不是永久保存。常见默认有效期是几分钟级别，Anthropic 文档和 Claude Code 相关说明里都提到过 5 分钟左右的缓存窗口。超过 TTL 后，即使你发送完全一样的请求，服务端也可能已经清掉缓存。
这也是很多长任务用户的体感来源：刚才还很省，去喝杯咖啡回来，再发下一步，Token 又突然涨上去了。
长任务尤其容易遇到这个问题。你可能要看 Claude Code 的输出、检查文件、跑测试、思考下一步，这些操作一不小心就超过 5 分钟。
如果你的使用环境支持，可以在长任务前启用 1 小时 Prompt Cache TTL：
|
|
在 Windows PowerShell 里可以写成：
|
|
需要注意的是，1 小时缓存写入成本通常会高于 5 分钟缓存写入成本。它不适合所有短任务，但对大型代码库、长对话、复杂多步骤开发任务，往往比频繁缓存过期更划算。
怎么安排一次更省 Token 的 Claude Code 长任务
比较稳的流程可以这样做：
- 任务开始前选定模型，不要中途频繁切换。
- 提前启用需要的 MCP，不用的 MCP 先关掉。
- 检查
CLAUDE.md，只保留稳定、关键、长期有效的规则。 - 提前准备好本次任务需要的 Skills。
- 如果是复杂任务，考虑启用 1 小时 TTL。
- 把大任务拆成几个阶段，但每个阶段内部尽量保持上下文结构稳定。
- 需要探索支线问题时，用 subagent 或单独 session，不要污染主对话。
这套做法的目标不是绝对不让缓存失效，而是避免那些代价最高、最容易被忽略的失效。
一个简单判断标准
你可以用一句话判断某个操作是否危险：
这个操作会不会改变模型、工具定义、系统上下文或会话开头的固定消息？
如果答案是会，那它大概率会影响 Prompt Cache。越靠近上下文链条左侧，影响越大。
常见操作可以这样理解：
- 切模型：高风险，模型缓存隔离。
- 新增 MCP 或重载插件：高风险，工具列表变化。
- 修改
CLAUDE.md：中高风险，项目记忆变化。 - 安装 Skills：中高风险，注入上下文变化。
- 普通对话继续追问：低风险，主要追加 messages。
- 空闲超过 TTL：高风险，服务端缓存过期。
小结
Claude Code 的 Prompt Cache 优化，关键不是背参数，而是让会话前缀稳定。
模型不要随便切，MCP 和 Skills 不要边做边装，CLAUDE.md 不要当临时草稿频繁改，复杂任务尽量延长 TTL。只要这些基础动作稳定下来，Claude Code 在长任务里的 Token 成本和响应速度都会更可控。
最实用的一句话是：开始前配好，开始后少动。