Claude Code 又慢又贵，先从缓存前缀查起

一个长任务做到一半，你把模型换了一个。第一轮响应明显变慢，用量记录里缓存写入涨了一截，账单也跟着往上走。第一反应很自然：是不是缓存出了问题？

可换模型、改配置、压缩对话，甚至停下来喝杯咖啡再回来，都可能让响应变慢变贵，原因各不相同。

要分清原因，得先知道缓存到底复用了什么。Prompt Caching 复用的是请求开头那段完全相同的内容，也就是前缀：前缀不变，后面追加的对话和工具结果只需要处理新增的部分；前缀的某一处变了，从变化的位置起，后面都要重新处理。

缓存怎么计费、默认能保留多久，也各有条件。

先用一张前缀图把复用的机制讲清楚，再逐项看七类常见的变化，切换模型、改工具定义、使用 /compact、很久没有请求，各自怎样影响缓存，然后拿一份使用记录练习判断：是缓存重建，是前缀一直在变，还是工具本身慢。

变慢变贵有很多种原因，缓存只是其中一种，先看记录再下结论；真需要更强的模型或更严的权限时，任务要求排在缓存前面。

01 缓存复用的是相同的请求前缀

Claude Code 调用模型时，会组织系统说明、项目上下文、会话与工具结果以及当前输入。模型依赖本次请求中可用的信息继续工作；前一轮出现过的内容仍需作为本次上下文的一部分提供。

Prompt Caching 让服务端复用已经处理过的相同输入前缀，机制见 Claude API 的 Prompt Caching 文档。前缀是请求开头连续相同的部分。正常追加对话时，前部往往不变：

第 1 轮：[稳定说明 A][项目背景 B][请求 C]
第 2 轮：[稳定说明 A][项目背景 B][请求 C][回答与新消息 D]
第 3 轮：[稳定说明 A][项目背景 B][请求 C][回答与新消息 D][新增 E]

A、B、C 等已处理且仍匹配的前缀 → 可复用缓存
新追加部分 → 继续处理
前部内容改变 → 从受影响的位置重新处理后续内容

匹配要求实际请求前缀相同，并满足缓存条件。把前面的规则换成同义句，也可能失去匹配；只在末尾追加新的工具结果，则通常保留前部复用机会。

Prompt Caching 减少重复处理相同输入的成本和延迟，不复用上一轮答案，也不扩大上下文容量或保证代码正确。新回答仍需根据本轮输入生成。

缓存读取仍有计费和有效期条件：官方文档写明缓存条目默认有效期为 5 分钟，也提供 1 小时的选项。是否命中应看实际统计。使用时重点核对：本轮是向已有内容后追加，还是改变了已处理的前部。具体模型和接入条件不同，最终仍以请求与使用记录判断。

02 哪些变化可能让缓存失效

可以先用上一节的前缀图判断：只是追加内容，还是改变了已有前部？但前缀相同还不够，模型、缓存有效期和服务条件也影响复用。

变化	为什么可能影响缓存
切换模型	新模型用不上另一个模型的处理结果
改变 effort 等推理设置	官方文档写明会使消息部分的缓存失效，对工具和系统部分的影响因模型而异，需核对实际请求与统计
改变直接进入前部的工具定义	从变化位置开始不再是原来的相同前缀；官方文档指出修改工具定义会使整个缓存失效
MCP 或 Plugin 变化	要看实际加载了什么；延迟发现和后部追加只影响后部，前缀整体未变
升级 Claude Code	系统说明或工具定义可能发生变化
使用 `/compact`	旧历史被摘要替换，对话部分需要重新建立缓存
长时间没有继续请求	即使内容没变，也可能因缓存过期而用不上缓存

例如，同样是安装 Plugin，只提供按需 Skill 与改变前部工具集合，可能产生不同影响。配置写进磁盘的时刻，和当前请求实际用上新配置的时刻，往往不同。

长任务开始时选好合适的模型、推理设置和必要工具，有助于减少无意义的变化。如果当前模型做不了必要判断，或某个工具必须收紧，就照样调整。缓存可以节省成本和等待时间，但需要调整能力或收紧权限时，仍应先满足任务要求。

03 改文件和改规则，对缓存的影响不同

正常编辑代码时，会话中已经出现的旧读取记录保持原样。后续读取新内容，是向历史追加新的信息，因此通常仍保留前部复用机会。

根级和用户级 CLAUDE.md 通常在会话开始加载，中途修改磁盘文件，当前已加载的仍是旧版本。需要在清空、压缩或重启后的加载中确认新规则。缓存有没有变化，和新规则是否生效、规则内容是否仍正确，是各自独立的几件事。

普通权限模式调整只要不动模型和工具定义，通常不改既有前缀；如果同时触发模型切换，就按模型变化分析。Skill 或命令在调用处加入内容，通常属于追加；重新概括并替换历史则不同。判断时以实际变化为准。

04 用使用记录判断缓存问题

看一份长任务的使用记录。表格是教学情境，仅用于演示判断：

观察	可以支持的判断	下一步
切换模型后的第一轮缓存读取减少，写入增加	与新模型重建缓存相符	观察后续稳定请求是否恢复复用
模型未变、时间间隔短，每轮仍大量写入	需要调查持续的请求前部变化	检查工具集合、系统或项目说明是否反复改变
缓存读取仍高，但某次工具执行很慢	慢可能来自工具，原因不全在缓存	查看工具耗时与错误
长时间暂停后，第一次请求没有复用	可能是缓存已过期	核对实际有效期和之后的复用情况

统计可以帮助判断原因，确定根因常常还要结合其他线索。例如缓存写入高也可能来自新输入较多，应该结合读取量、输入规模、时间间隔与配置变化分析。一次响应时间里混着输入处理、输出生成、网络和工具等待，要拆开看。

回到开头的记录：切换模型后第一轮缓存写入增加，后续轮次恢复读取，与一次缓存重建相符。如果新模型确实更适合当前任务，先看后续是否稳定，再判断是否需要调整；一次缓存重建若不影响任务完成，可以继续观察。

条件再变一下：没有切换模型，但每次调用前都重新拼出不同的工具定义，缓存持续重建。此时值得检查工具加载策略。

05 压缩前先保留状态，再算缓存账

压缩会替换部分历史，也可能丢失决定理由、临时约束和未验证状态。保留什么、怎么写交接，见越聊越乱，该清空还是压缩。这里只增加缓存的取舍。

可以在探索收束、准备实施，或代码完成、准备验证这样的阶段边界整理状态后再压缩。例如“已改会话恢复逻辑，单测通过，浏览器刷新尚未验证”清楚地区分改动、结果和缺口，比“接近完成”更便于继续。

压缩会改变对话缓存。决定是否压缩时，要比较当前信息负担、后续任务需要与重建成本。支持查看统计的版本，可以用 /usage 查缓存信息，成本文档里有 Prompt cache statistics 一节；其他入口看实际 API 使用记录。先确认是缓存未命中，还是工具、网络或输出生成耗时，再调整。

缓存命中后，代码对错仍待验证；变慢解决了，功能是否修好要另行确认。变慢、做错、配置过期是三类问题，下一篇AI 改完代码，用五类检查证明它真的改对了讲后两类。