​
Claude 缓存为什么突然不命中，费用也变高了？

先检查缓存有效期和请求前缀。Claude 默认缓存有效期为 5 分钟，命中时会刷新；过期或前缀变化后，相关内容可能需要重新写入，费用通常高于缓存读取。
  1. 核对间隔：检查两次请求是否超过所配置的缓存有效期。
  2. 比较前缀：检查系统提示词、工具定义和历史消息。压缩、回退或修改历史会改变前缀，影响对应部分的缓存命中。
  3. 查看用量：对比前后请求的缓存读取量、写入量和实际费用，区分缓存变化与输入、输出长度增长。
模型、通道和客户端均支持时，可考虑 1 小时缓存。其写入单价更高，应结合请求间隔和命中率评估总成本，不代表开启后一定更省钱。 Claude Code 的客户端设置见缓存与费用配置；同时发起相同请求仍未命中时，继续看下方的并发缓存排查。 机制参考：Claude 官方缓存说明。平台费用以模型价格和调用明细为准。

​
为什么内容完全相同的并发请求没有命中 Prompt Cache？

核心原因是 Prompt Cache 遵循“先写入、后读取（Write-then-Read）”的机制。 当多条完全相同的请求在同一瞬间高并发同时到达时：
  • 由于首个请求的缓存尚未完成计算与写入，此时到达的并发请求均会被判定为冷缓存（Cache Miss），从而各自执行全额输入的完整计算；
  • 优化建议：在执行批量或高并发任务前，先发送 1 次单请求完成缓存预热（Warm-up），待其返回后，再观察后续请求的缓存命中指标。是否命中仍受模型支持、前缀长度、缓存有效期和实际路由等条件影响，预热不能保证每次命中。
排查常规 Prompt Cache 未命中的其他常见原因：
  1. 前缀动态污染：System Prompt 或上下文开头动态拼接了时间戳、随机 UUID 或动态会话 ID，破坏了从首字开始的严格前缀匹配（Prefix Matching）；
  2. 未达 Token 门槛：模型对缓存有最小 Token 阈值要求（通常需达到 1024 或 2048 Tokens 以上），短文本不会触发缓存；
  3. 缓存 TTL 超时：两次调用间隔超过了模型的缓存保留周期；
  4. 指标核对：真实命中情况以控制台 调用明细 记录的 cached_tokens 指标为准。

​
模型自称是其他版本，能否据此判断发生了模型降级？

不能。大语言模型的“自我介绍”仅由其预训练语料和提示词决定，并不具备实时感知底层物理硬件与 API 路由的能力。真实调用的模型版本以NoneLinear 控制台 调用明细 中的 Model ID 记录为依据。

​
使用 Python 脚本每次独立调用，为什么多轮内容没有命中 Prompt Cache？

独立 Python 请求只要满足前缀一致性即可命中缓存，无需依赖持久连接。若未命中，请重点检查每次请求是否保持了完全相同的 System Prompt 和前置历史顺序。业务层多轮交互需保证 Payload 前缀稳定。

​
频繁切换模型会对 Prompt Cache 有什么影响？

不同大模型之间无法共享底层 Prompt Cache 缓存池。频繁在不同模型间来回切换会导致每个模型均需重新执行缓存预热。建议按任务阶段（如架构规划、常规编码）固定使用对应模型。

​
模型的“上下文上限（Context Window）”与“单次最大输出长度（Max Output Tokens）”是一回事吗？

不是。
  • 上下文上限：指单次请求中「系统提示词 + 历史输入 + 工具消息 + 本次模型输出」的总 Token 上限（如 200K / 1M）；
  • 最大输出长度：指模型单次推理能够生成的最大 Token 数量（如 8K / 64K）。 在客户端配置中，切勿将单次输出上限配置过小，以免导致长文本生成或深度思考过程被意外截断。