先看 cache miss reason
如果 claude --resume 之后额度下降很快，先检查会话日志中的 cache_creation_input_tokens、cache_read_input_tokens 和 diagnostics.cache_miss_reason。公开复现中，旧 CLI 与 VS Code 同时恢复一个活跃会话，约 760K token 被重新写入缓存，原因标记为 system_changed。
这不是普通的“会话太久没用”。客户端版本、工具 schema、技能列表或 system block 顺序变化，都可能让原本相同的前缀失效。
三种恢复方式不要混用
| 恢复方式 | 主要风险 |
|---|---|
| 同一客户端继续会话 | 成本最低，但仍可能遇到自动更新 |
VS Code 与独立 CLI 交替 --resume | system prefix 和工具列表容易不同 |
cron/脚本定时 --resume | 可能调用旧二进制并与前台会话并发 |
先记录当前客户端版本和实际执行路径，再决定是否恢复。脚本中不要只写 claude，应确认它解析到哪个二进制。
用小会话做安全复现
不要拿百万 token 的生产会话反复试错。先建立一个有少量规则文件和工具的测试会话，退出后分别使用同版本 CLI、不同版本 CLI 和 VS Code 恢复。
每次只比较这些字段：
entrypoint和 CLI 版本modelcache_read_input_tokenscache_creation_input_tokensdiagnostics.cache_miss_reason.type
如果同版本恢复能命中缓存，而跨版本恢复出现 system_changed 且完整重写，根因就在客户端前缀变化。
发生缓存重建时怎么止损
发现一次大规模 cache_creation 后，先停止继续发送 prompt。确认当前会话是否仍在另一个客户端运行，关闭旧的定时任务或后台进程，再决定是使用同一版本继续还是新建会话。
不要为了“保持原会话”连续重试。每次重试都可能再次写入完整前缀；长任务可以把当前目标、已完成步骤和待验证项写入新的短上下文，再从新会话继续。
成功标准
恢复后的下一轮请求应主要表现为 cache_read_input_tokens，而不是接近完整上下文的 cache_creation_input_tokens；客户端版本和入口路径可追溯；不会同时有两个进程写同一会话。
这条排查路径比通用计费文章更具体，适用于跨客户端、自动更新和定时恢复造成的缓存失效。