缓存按前缀逐字节匹配，Claude Code 的一切设计都围绕保住共享前缀
缓存按前缀匹配，所以内容的排列顺序决定了成本。
API 会缓存从请求开头到每个 cache_control 断点为止的全部内容。前缀里任何位置一变，后面的缓存就全部作废。所以按变化频率从低到高排：全局的静态 system prompt 和工具，然后是项目级的 CLAUDE.md 和 memory，再是会话级上下文，最后是对话消息。这样尽可能多的会话能共用同一段前缀。
“the order you put things in matters enormously” ¶5
这一点暂无对应的审视。
状态更新走消息通道，不改 system prompt。
时间、文件改动这类会过期的信息，如果写回 system prompt 就会让整段前缀失效。Claude Code 的做法是在下一条 user message 或 tool result 里附一个 system-reminder 标签，前缀保持不动。作者也提到排序很容易被无意破坏：静态 prompt 里放了精确时间戳、工具定义顺序不固定、改了工具参数，都出过事故。
“we add a <system-reminder> tag in the next user message or tool result” ¶15
代价一侧几乎没展开：system-reminder 注入对输出质量的影响只用一句话带过（¶6）；defer_loading 会多一次 tool search 往返，模型也可能选错或漏选工具；压缩摘要会丢信息。文中都没给数据。
缓存按模型隔离，会话中途换成便宜的模型反而可能更贵。
每个模型的缓存是各自独立的。例如 Opus 对话已经积累到 100k token，这时切到 Haiku，就得在 Haiku 上把整段前缀按未缓存价重新写一遍。真要换模型，正确做法是开一个 subagent，由主模型写一份交接消息再交给另一个模型；Claude Code 的 Explore agent 就是这样用 Haiku 的。
“more expensive to switch to Haiku than to have Opus answer” ¶17
命中率高直接关系到厂商自己的算力成本和订阅限额，所以「别中途切到便宜模型」这条建议也同时增加了大模型的用量。文中只举了一个对 Opus 有利的例子，没有给出对话长度和问题难度在什么范围内切换反而更省的临界点。
工具集合始终固定，状态切换和按需加载都做成工具或存根。
工具定义属于缓存前缀，增删一个工具就会让整段对话的缓存失效。所以 Plan Mode 不靠替换成只读工具集来实现，而是把 EnterPlanMode 和 ExitPlanMode 做成工具，再用 system message 说明当前约束。顺带的好处是模型遇到难题时能自己进入计划模式。MCP 工具多的时候只发名称存根（defer_loading: true），模型通过 tool search 选中后才加载完整 schema，存根本身的内容和顺序始终不变。
“we keep all tools in the request at all times” ¶21
这一点暂无对应的审视。
压缩之类的旁路计算必须共用父会话的前缀（cache-safe forking）。
直观的写法是单独发一次「总结一下」的调用，换一个 system prompt、不带工具。但这样从第一个 token 起前缀就不一样了，整段对话都按未缓存价计费，而且对话越长、越需要压缩，这一次就越贵。正确做法是沿用父会话完全相同的 system prompt、上下文和工具定义，接上原有消息后在末尾追加压缩指令，这样新增的 token 只有指令本身。代价是要预留一块 compaction buffer，给指令和摘要输出（图中约 20k token）留出空间。
“use the exact same system prompt, user context, system context, and tool definitions” ¶28
「会话中途增删工具或换模型会让缓存失效」「独立摘要调用拿不到缓存」这两条都可以低成本复现。
缓存命中率要像可用性（uptime）一样监控，命中率掉下来按事故处理。
命中率高，成本就低，订阅方案的限额也能给得更宽，所以 Claude Code 对缓存失效设了告警，命中率过低会宣布 SEV。作者说缺失率差几个百分点就会明显影响成本和延迟，但文中没有给出具体基线。
“Monitor your cache hit rate like you monitor uptime” ¶36
「缺失率差几个百分点就会明显影响成本」没有给基线命中率，也没有给分母口径（按请求算还是按 token 算）。图中缓存读取是原价十分之一，但文中完全没提缓存写入的溢价和缓存过期时间，这两项会改变长间隔场景（比如每周跑一次的任务）的计算。
作者没有直接谈到这一点。
文章没有讨论 effort 或 thinking 档位的改变会不会打断缓存，而 L-001 方案是否可行正取决于这一点。
同样是给长对话做摘要，前缀是否与父会话一致，决定了这次调用能否命中缓存。
缓存按前缀匹配，所以内容的排列顺序决定了成本。
API 会缓存从请求开头到每个 cache_control 断点为止的全部内容。前缀里任何位置一变，后面的缓存就全部作废。所以按变化频率从低到高排：全局的静态 system prompt 和工具，然后是项目级的 CLAUDE.md 和 memory，再是会话级上下文，最后是对话消息。这样尽可能多的会话能共用同一段前缀。
the order you put things in matters enormously
¶5 ↗
状态更新走消息通道，不改 system prompt。
时间、文件改动这类会过期的信息，如果写回 system prompt 就会让整段前缀失效。Claude Code 的做法是在下一条 user message 或 tool result 里附一个 system-reminder 标签，前缀保持不动。作者也提到排序很容易被无意破坏：静态 prompt 里放了精确时间戳、工具定义顺序不固定、改了工具参数，都出过事故。
we add a <system-reminder> tag in the next user message or tool result
¶15 ↗
缓存按模型隔离，会话中途换成便宜的模型反而可能更贵。
每个模型的缓存是各自独立的。例如 Opus 对话已经积累到 100k token，这时切到 Haiku，就得在 Haiku 上把整段前缀按未缓存价重新写一遍。真要换模型，正确做法是开一个 subagent，由主模型写一份交接消息再交给另一个模型；Claude Code 的 Explore agent 就是这样用 Haiku 的。
more expensive to switch to Haiku than to have Opus answer
¶17 ↗
工具集合始终固定，状态切换和按需加载都做成工具或存根。
工具定义属于缓存前缀，增删一个工具就会让整段对话的缓存失效。所以 Plan Mode 不靠替换成只读工具集来实现，而是把 EnterPlanMode 和 ExitPlanMode 做成工具，再用 system message 说明当前约束。顺带的好处是模型遇到难题时能自己进入计划模式。MCP 工具多的时候只发名称存根（defer_loading: true），模型通过 tool search 选中后才加载完整 schema，存根本身的内容和顺序始终不变。
we keep all tools in the request at all times
¶21 ↗
压缩之类的旁路计算必须共用父会话的前缀（cache-safe forking）。
直观的写法是单独发一次「总结一下」的调用，换一个 system prompt、不带工具。但这样从第一个 token 起前缀就不一样了，整段对话都按未缓存价计费，而且对话越长、越需要压缩，这一次就越贵。正确做法是沿用父会话完全相同的 system prompt、上下文和工具定义，接上原有消息后在末尾追加压缩指令，这样新增的 token 只有指令本身。代价是要预留一块 compaction buffer，给指令和摘要输出（图中约 20k token）留出空间。
use the exact same system prompt, user context, system context, and tool definitions
¶28 ↗
缓存命中率要像可用性（uptime）一样监控，命中率掉下来按事故处理。
命中率高，成本就低，订阅方案的限额也能给得更宽，所以 Claude Code 对缓存失效设了告警，命中率过低会宣布 SEV。作者说缺失率差几个百分点就会明显影响成本和延迟，但文中没有给出具体基线。
Monitor your cache hit rate like you monitor uptime
¶36 ↗
命中率高直接关系到厂商自己的算力成本和订阅限额，所以「别中途切到便宜模型」这条建议也同时增加了大模型的用量。文中只举了一个对 Opus 有利的例子，没有给出对话长度和问题难度在什么范围内切换反而更省的临界点。
「缺失率差几个百分点就会明显影响成本」没有给基线命中率，也没有给分母口径（按请求算还是按 token 算）。图中缓存读取是原价十分之一，但文中完全没提缓存写入的溢价和缓存过期时间，这两项会改变长间隔场景（比如每周跑一次的任务）的计算。
「会话中途增删工具或换模型会让缓存失效」「独立摘要调用拿不到缓存」这两条都可以低成本复现。
文章没有讨论 effort 或 thinking 档位的改变会不会打断缓存，而 L-001 方案是否可行正取决于这一点。
代价一侧几乎没展开：system-reminder 注入对输出质量的影响只用一句话带过（¶6）；defer_loading 会多一次 tool search 往返，模型也可能选错或漏选工具；压缩摘要会丢信息。文中都没给数据。