Claude API prompt cache 怎么检测

Prompt cache 让多个请求复用相同的长前缀，常见对象包括 system prompt、工具定义、长文档和稳定的对话历史。命中缓存后，上游不必按完整输入重新处理该前缀，因此可能降低长上下文成本和首字等待。

检测目标不是证明“第二次更快”，而是确认 Anthropic usage 中出现可核对的创建和读取 token 数。网络抖动、排队和生成长度都会影响延迟，usage 字段才是更直接的缓存证据。

不同 SDK 会把字段映射到不同命名风格，但原始 Anthropic 响应通常围绕输入 token、缓存创建 token 和缓存读取 token 展开。保存原始 usage 片段，后续排查会容易很多。

准备一个长度达到模型缓存门槛的稳定前缀，并在需要缓存的内容块上使用 Anthropic 支持的 cache_control。两次请求应使用相同模型、相同 system/tool/document 前缀，只改变最后一个很短的用户问题。

常见原因包括模型不支持、前缀低于最低 token 门槛、cache_control 放置错误、两次前缀存在空格或 JSON 顺序差异、缓存已过期，或者账号/区域发生变化。

如果通过中转站调用，还要确认它没有把 Anthropic 请求转换成 OpenAI 格式、删除 cache_control，或在响应中丢弃缓存 usage 字段。此时延迟下降也不足以证明原厂缓存命中。

缓存命中通常会改善长前缀处理成本，但总耗时仍受输出长度和上游排队影响。应把 TTFT、端到端耗时和 usage 分开记录，而不是用一个总延迟数字概括。

成本计算也要区分普通输入、缓存写入和缓存读取。具体价格会随模型和 Anthropic 定价变化，报告应保留 token 数，再按测试当天的官方价格换算。

用真实 system prompt、工具定义和文档模板复测，在不同时间段运行多轮请求，记录命中率而不是只看一次命中。对于中转站，还应确认切换账号池或出现 429 后，缓存行为是否仍然稳定。