Claude Code 缓存为什么变成 5 分钟？订阅 TTL 与 /usage 排查

先区分主对话和子代理

子代理等请求默认 5 分钟；订阅包含用量内少数服务器控制的辅助请求例外为 1 小时。检查前先明确你在观察哪类请求。

建议先把问题写清楚：是界面直接显示了期限变化，还是因为暂停一会儿后响应变慢而猜测缓存失效？前者可以核对统计，后者还需要证据。本文按当前官方文档整理终端排查方法，不把教程发布日期当作功能首次上线日期，也未进行账户或模型调用实测。

确认正在使用的账户和客户端

在终端运行 claude --version 记录版本，再用 claude auth status --text 查看可读的认证状态。先确认这是不是你平时工作的终端环境；不要为了排查而退出、重登或切换账号，否则前后比较的对象可能已经改变。

随后打开对应账户的用量页面，核对当前是否仍在包含用量内，是否已经开始消耗额外用量。建议记录观察时间和页面提示原文，不只写“我买了订阅”。如果单位负责账单，请让有权限的人核实计费方式；不必为验证缓存而开启额外付费或提高支出上限。

在 /usage 找到实际 TTL

在现有交互会话输入 /usage，查看 Session 中的 Prompt cache (main)。建议先记下账户、项目与观察时间，避免拿两个环境的截图直接比较。

先读 TTL 与 warm、cold，再结合缓存输入占比、miss 次数判断。v2.1.260 起，能识别原因时还会显示 likely cause。expected rebuild 表示压缩上下文或清理旧工具结果后的预期重建，并非每个未命中都代表故障。

建议在正常工作到一个停顿点时保存读数，下一次继续原任务后再比较，不额外发送一串无意义提示来追求高命中率。/clear 会重置 Session 统计，留证前不要先清空。若显示 API 未报告缓存，应记作缺少可判断的统计，不自行填成“没有资格”。

把缓存期限与命中结果分开看

TTL 从写入或读取缓存的请求开始计时，命中会刷新期限；生成回答的时间也算在内。API 缓存复用还要求对应提示前缀完全一致；期限尚未过去，也不意味着改过的请求一定能复用原内容。延长缓存不是免用量开关。

可自建一条简短记录：“版本／认证方式／项目／观察时刻／期限／最近一次提示”。这只是记录模板，不是测量结果。如果前后换了账户、项目或模型，先注明变动，再判断这组截图有没有比较意义。不要把不同工作的耗时差直接归因于 TTL。

Pro、Max 的 Session 美元估算不等于订阅账单。需要追查收费时，保留账户用量或账单证据，避免把一行缓存统计换算成套餐涨价、降额或固定节省金额。

默认值不符时，检查覆盖配置

v2.1.242+ 支持 promptCacheTtl（主对话）和 subagentPromptCacheTtl（其余请求），值为 5m 或 1h。先记录原值，再按优先顺序查找覆盖来源。

本轮排查建议先读配置，不直接改期限。用户级文件通常是 ~/.claude/settings.json，项目还有共享和本地设置；在会话运行 /status 可查看受管设置来源。先找到实际起作用的层级，再与负责配置的人确认用途，不因为某个键存在就整段删除。

确需修改时，先保存原值，只增改目标键，保留其他配置。设置文件使用严格 JSON，不接受注释或末尾多余逗号；不要用网上的一行示例覆盖整个文件。修改后若出现设置错误，可在终端运行诊断 claude doctor，按报错定位文件与键。

仍不一致时，保留证据再定位

更长期限会增加 API 缓存写入成本，不能承诺更省钱。不要为了消除一个疑问而同时更换网关、调整付费方式和修改配置；先把已有读数与支持条件对应起来。

建议把问题交接成一个可复查的小案例：哪次开始不一致、客户端版本、认证方式、配置来源、原始错误，以及同一会话前后读数。截图分享前遮住账户标识和项目内容，不粘贴密钥或整份环境变量。若目前只有一次慢响应，就明确写“原因未确认”，先继续正常任务观察，避免同时改多个设置后失去对照。