07 Claude Code 最近的缓存相关变化

Claude Code 这一段，不适合写成 changelog 逐条解释。真正值得讲的是：Claude Code 正在从单个 coding agent，变成一个会调度工具、压缩上下文、切换模式、拉起子任务的工程系统。系统越复杂，越容易制造动态上下文；动态上下文越多，缓存越难稳定。

这就是 Claude Code 最近一系列缓存相关变化的共同背景。

一个 coding agent 的请求前缀，通常不只是 system prompt。它还包括工具定义、项目规则、CLAUDE.md、权限模式、MCP schema、当前目录、git 状态、上下文预算、历史消息和工具结果。这里面有些内容应该长期稳定，有些内容每轮都会变。

缓存优化的核心，就是把这两类东西分开。

Claude Code 在 TTL 上已经有明显策略化痕迹。2.1.108 里出现了两个环境变量：

ENABLE_PROMPT_CACHING_1H：启用 1 小时 prompt cache TTL
FORCE_PROMPT_CACHING_5M：强制 5 分钟 TTL

这说明 Claude Code 并没有把缓存时间当成单一默认值处理。连续修 bug、跑测试、读文件，5 分钟通常够用；用户离开一段时间、side agent 执行长任务、远程会话恢复，1 小时缓存才更有价值。

后面修复过的几个问题，也都能放到这个逻辑里看。

比如 1 小时 TTL 曾经被静默降级成 5 分钟。用户以为自己保住了长会话缓存，实际中途停顿后可能重新写入。再比如 cache_creation_input_tokens 显示异常，会让用户误判缓存写入成本。sub-agent progress summaries 缺少 prompt cache，则会在多 agent 场景里放大 cache creation。

这些不是单纯的 UI 或统计 bug。它们会直接影响用户对账单的判断。

系统提示词也是一样。

Claude Code 后来加过 --exclude-dynamic-system-prompt-sections，目标是改善跨用户 prompt caching。这个变化说明，system prompt 里有一部分内容本来就不该混在稳定前缀里。

比如当前时间、cwd、git 状态、权限模式、token budget、工具可用状态，这些信息对 Agent 有用，但每轮都可能变化。它们如果出现在很靠前的位置，会让原本稳定的 system prompt 变成动态前缀。

缓存失效很多时候就发生在这里：用户只发了一句“继续”，框架却在最前面改了很多运行状态。

Tool schema 是另一类问题。

MCP server 一多，tool definitions 会很长，而且容易变化。Claude Code changelog 里提到过 MCP tool definitions deferred，也就是延迟加载 MCP 工具定义。这类改动的意义不只是少塞一点 token，它也减少了工具 schema 对缓存前缀的扰动。

工具定义越稳定、越少无关工具提前进入上下文，缓存越容易维持。

/model 切换提醒也属于同一类问题。

Claude Code 会提醒用户：中途切换模型后，下一轮会重新读取完整历史，且没有缓存。这个提醒很重要。长会话里，切模型不只是换一个推理能力，也可能意味着原来的缓存链路断掉，下一轮输入成本突然变高。

Auto-compaction 则是另一个取舍。

压缩上下文可以避免撑爆 context window，也能减少后续输入长度。但 compaction 会改写历史，原来的 messages prefix 会变成摘要。它可能降低总 token，也可能打断原有缓存链。

所以 compaction 不是天然省钱。它是在“缩短上下文”和“保持缓存连续性”之间做取舍。

最近的 ultracode / orchestration mode，会把这个问题再放大一层。

ultracode 可以理解成高 effort 加自动多 agent 编排。它不只是让主 agent 多想一会儿，而是让 Claude Code 更主动地拆任务、派子 agent、并行推进、再汇总结果。

这对复杂任务有价值，比如大型重构、深度 PR review、跨模块排查。但从缓存角度看，它会制造更多独立上下文：每个 sub-agent 都有自己的 prompt、工具、项目规则、历史片段和执行结果。它们不一定共享主会话已经命中的缓存，也不一定有相同的前缀结构。

换句话说，ultracode 能提高任务推进能力，也会放大 token 消耗和缓存不稳定性。

如果一个任务本来只需要主会话连续处理，缓存还能沿着同一条前缀链往后走。进入多 agent 编排后，系统会同时生成多条上下文链，每条链都可能重新写缓存、重新读取项目规则、重新加载工具定义。再加上 agent 之间的 progress summary、结果汇总和后续 review，成本会明显上去。

这不是说 ultracode 不该用。它适合值得认真拆解的大任务。小修小改、单文件 bug、简单命令能解决的问题，用它反而容易把缓存和 token 都打散。

Claude Code 这些变化放在一起看，指向的是同一个工程问题：

Agent 框架要同时处理“能力”和“成本”。能力越强，越需要动态状态、工具调度、子任务、压缩和恢复；成本越稳，越需要稳定前缀、可控 TTL、少变的 tool schema、清楚的 usage 字段。

缓存不是 Claude Code 的附属优化。到了 coding agent 这个层级，它已经变成上下文工程的一部分。

用户看到的是读文件、改代码、跑测试、拉 sub-agent。账单背后，是每一轮到底复用了多少稳定前缀，又因为多少动态状态重新计费。