在构建基于 Claude 的生产服务时，提示缓存（Prompt Caching）已成为降低延迟与成本的核心手段。然而，缓存生命周期的选择 —— 默认的 5 分钟还是可选的 1 小时 —— 直接影响缓存命中率和最终费用支出。本文从工程实践角度，提供具体的决策框架与可落地参数。
缓存 TTL 的定价机制
Anthropic 的提示缓存采用分层计费模式，TTL 时长的选择本质上是对缓存写入成本与潜在收益的权衡。以 Claude Sonnet 4.6 为例：
5 分钟缓存的写入费用为基价的 1.25 倍（每百万 tokens 3.75 美元），而 1 小时缓存则为基价的 2 倍（每百万 tokens 6 美元）。读取费用统一为基价的 0.1 倍。这一差异意味着，选择 1 小时 TTL 意味着首次缓存写入需要多支付 60% 的成本，但换取的是更长的命中窗口。
对于高频调用场景，如果请求间隔普遍小于 5 分钟，5 分钟 TTL 会持续刷新缓存（刷新不额外收费），此时长 TTL 无法产生额外价值，反而徒增写入成本。关键判断标准是：请求的实际时间间隔是否稳定落在 TTL 窗口内。
成本收益的量化判断
定义以下变量进行计算：设基价输入 tokens 为 P（美元 / 百万），缓存内容大小为 T（tokens），请求间隔为 I（分钟），单位时间内的请求数为 R。
5 分钟缓存的期望成本为：首次写入 1.25P×T，后续每次请求支付 0.1P×T 的读取费用。1 小时缓存的期望成本为：首次写入 2P×T，后续每次请求支付 0.1P×T。
当请求间隔 I > 5 分钟时，需要计算两种方案的成本平衡点。假设单位时间内总请求数固定为 N，5 分钟缓存需要约 N/5 次写入（每 5 分钟刷新），1 小时缓存则只需 N/60 次写入。成本差异主要体现在写入次数乘以各自单价。当 I 显著大于 5 分钟且小于 60 分钟时，1 小时缓存的写入次数优势开始显现。
实际工程中，建议设置监控阈值：当平均请求间隔超过 3 分钟且缓存命中率低于 40% 时，考虑切换至 1 小时 TTL；当请求间隔小于 2 分钟时，坚决使用 5 分钟 TTL。
缓存失效的工程陷阱
缓存失效是生产环境中被低估的风险因素。Anthropic 的缓存遵循严格的前缀匹配规则，任何微小的内容变更都会导致缓存未命中。
最常见的陷阱是将 cache_control 标记置于每请求变化的内容上。例如，若系统提示包含动态时间戳或用户特定上下文，将缓存断点设在该位置会导致每次请求都产生新的缓存写入，而非读取既有缓存。正确的做法是将断点设在静态内容的末尾，确保前缀在多次请求间保持不变。
另一个关键限制是 20 块的回溯窗口。当对话上下文增长超过 20 个块时，位于更早位置的缓存条目将无法被检索。此时需要显式设置多个断点，确保每个回溯窗口内都有有效的缓存写入。对于长对话场景，建议在系统提示、工具定义、历史消息的固定部分分别设置断点。
混合 TTL 的正确姿势
Anthropic 支持在同一请求中混合使用 5 分钟和 1 小时两种 TTL，但存在严格的顺序约束：长 TTL 的断点必须出现在短 TTL 断点之前。这一设计源于缓存层级的构建逻辑。
具体实践中，可以将变化频率最低的内容（如工具定义、系统指令）使用 1 小时 TTL，变化频率适中的内容（如会话历史）使用 5 分钟 TTL，而每轮必变的用户输入则不参与缓存。计费时，系统会从高到低依次计算三个位置：最高缓存命中位置 A、最高 1 小时断点位置 B、最后断点位置 C。位于 (A, B] 区间的 tokens 按 1 小时缓存写入计费，位于 (B, C] 区间的 tokens 按 5 分钟缓存写入计费。
对于使用 Spring AI 等框架的开发者，AnthropicCacheTtl 枚举已提供标准支持，可通过配置类直接指定默认 TTL 策略。
监控指标与回滚策略
生产环境中应追踪以下核心指标：缓存命中率（cache_read_input_tokens /total_input_tokens）、缓存写入频率、每次请求的平均缓存成本。当缓存命中率骤降时，可能的原因包括：断点位置不当、请求间隔超过 TTL、缓存内容被意外修改。
建议设置告警规则：当缓存命中率低于 30% 持续超过 10 分钟时，自动降级至 5 分钟 TTL（若原本使用 1 小时）并触发告警；当缓存写入成本占比超过预期值的 150% 时，触发配置审计。
Anthropic 于 2026 年 2 月将缓存隔离级别从组织改为工作区，这一变更对多租户场景有直接影响。同一组织内不同工作区的缓存已完全隔离，需相应调整缓存策略以适应新的隔离边界。
资料来源：本文核心参数与定价模型来自 Anthropic 官方提示缓存文档，监控指标设计参考 Spring AI 的 AnthropicCacheTtl 实现。