闲置的 Claude Code 会话，回来再用花多少？恢复提醒何时出现

30 秒看懂结论

Claude Code 长会话闲置超过 1 小时，再发消息通常要把大部分上下文重新写入缓存。 400K token 按 Opus 5.5 标价约 $3，订阅用户会消耗相应的用量。

• 开启闲置压缩（idle compaction），并确认它运行过。 它会在缓存过期前生成摘要。我们的测试中，闲置两小时后回来，开启时花 $0.20、关闭时花 $3.28，但我们的长驻会话从未触发。
• 在 1 小时内回来，或换任务就新开会话。 提到旧会话时，Claude 可以查回。
• 留意发往闲置会话的自动提示。 我们约一半的冷恢复由它们触发。
• 在 Max 上用 Opus 5.5，别等恢复提醒。 按我们看到的配置，它不会出现。

1 小时内，多数上下文可读缓存

使用 Claude 订阅时，Claude Code 的主会话至少缓存 1 小时，这段时间内大部分上下文从提示词缓存读取。缓存读取只需输入价的二十分之一。过后缓存可能失效，再次写入要花输入价的两倍，即 Opus 5.5 每百万 token $8。使用 API 密钥、云服务商或用量额度（Usage credits）时，默认缓存只有五分钟。

我们的会话记录也呈现了这个规律：

这 355 次请求就是冷恢复，缓存写入量中位数为 365,288 token，按标价约 $2.92。Claude Code 自己估算，在 Max 5x 上重写 400K token 约占 5 小时用量限额的 1.5%。这些缓存写入共花 $1,151，占全部 46 个会话总成本 $2,074 的 55%。它们来自 19 个会话，多数是连续运行数天的长驻会话。约一半由自动提示触发，主要是定时检查。

闲置压缩能省钱，先确认它跑过

Claude Code 2.1.299 加入了终端闲置压缩：200K token 及以上的会话闲置约 54 分钟后，会在 1 小时缓存过期前变成摘要，下次只发送摘要。它默认开启，但需要自动压缩、1 小时缓存和电脑保持唤醒。在 settings.json 中设 "idleCompaction": false 可关闭它，CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 可把 200K 门槛最低调到 100K。

我们在 Claude Code 2.1.310 上用两个相同的 421K token 会话测试，A 开启闲置压缩，B 关闭：

真正可比的是第二次回来。第一次 B 仍命中缓存，可能因为 A 的压缩在八分钟前读过两者共用的前缀。热身后合计 A 花 $0.58，B 花 $3.51。代价是 Claude 从摘要继续，摘要会指向磁盘上的完整会话记录。

我们的长驻会话从未触发闲置压缩。 记录里一次也没有，包括 2.1.299 发布后、上下文达 200K+ token 的 86 次冷恢复。进程当时仍在跑 2.1.283 和 2.1.293，但 2.1.283 已有闲置压缩代码，原因我们不知道。会话连续开几天，就检查终端是否提示「已在闲置时压缩」（原文：“Compacted while idle”）。

Max 上用 Opus 5.5，恢复提醒不会出现

按我们账户缓存的配置，Opus 5.5 在 Max 5x 上约需 1.36M token 才能触发恢复提醒，已超过它的 1M token 窗口。Claude Code 2.1.304 为 Pro 和 Max 加入恢复提醒，针对会明显消耗 5 小时用量限额的恢复（原文：“would use a noticeable share of your 5-hour usage limit”）。2.1.310 代码把门槛定为预估用量至少 5%，算法是上下文 token 数 × 模型的折算系数 ÷ 套餐额度。恢复提醒只在 Claude Code 判断缓存无法复用、用户未触及限额且未使用用量额度时显示。

各模型、套餐触发恢复提醒所需的上下文：

超过 1M 的门槛，在 1M token 窗口里达不到。我们用 Opus 5.5 和 Max 20x 恢复一个闲置十天的 764K token 会话，没有出现恢复提醒。折算系数和额度通过下载获取，可能变化。我们这份配置没有 Pro 条目。

我们怎么测的

这些测量均于 2026 年 10 月 25 日，在我们一台 Mac 上完成：

• 会话记录：扫描 ~/.claude/projects 中截至 19:18 UTC 的全部主会话记录，含 7 月 10 日以来的 46 个会话、7,121 次请求，不含子代理。只统计上下文至少 20K token 的请求。间隔按相邻请求的会话记录近似计算。间隔至少 1 小时、至少一半上下文重新写入缓存，才算冷恢复。
• 代码与配置：查看 Claude Code 2.1.310 二进制中的恢复提醒文案和逻辑、2.1.283 中的闲置压缩代码，以及 ~/.claude.json 中缓存的配置。
• 闲置压缩测试：用完整的 Claude Code 更新日志构建两个会话，在 2.1.310 上使用 Opus 5.5，成本取自会话记录和 /cost。

这些情况没测

• 没测其他人的用量。 我们的大部分冷恢复来自刻意保持运行的会话。
• 没核对实际账单。 金额均按 Opus 5.5 标价折算全部流量，包括它在 9 月 22 日发布前的流量。订阅按用量扣除，美元金额不代表实付费用。
• 没核对用量表。 恢复提醒中的占比是 Claude Code 自己的估算，我们未与用量表核对。
• 没查明长驻会话为何没有闲置压缩，也没做第二次压缩测试。

相关阅读

• Opus 5.5 发布后，代理流量到底花多少：为什么缓存写入占代理账单的大头。
• Claude Code 用量限额：5 小时和每周限额如何运作。
• 如何管理一批长驻代理：我们大部分冷恢复背后的运行方式。
• Claude Code 后台代理标签：平时占 0.1%，关遥测占 19%：另一笔后台费用，以及关闭遥测后状态标签更贵的原因。

来源

1. Anthropic：Claude Code 更新日志，2.1.299 和 2.1.304 条目。查阅日期：2026 年 10 月 25 日。
2. Anthropic：Claude Code：提示词缓存，「各类请求的缓存有效期」一节（原文：“Which TTL each request gets.”）。
3. Anthropic：提示词缓存，缓存写入价格倍数，以及 Opus 5.5 按输入价 5% 收费的缓存读取。
4. Anthropic：Claude Code：设置参考，idleCompaction。
5. Anthropic：Claude Code：环境变量，CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS。

FAQ

为什么闲置的 Claude Code 会话一恢复，就消耗很多额度？

使用 Claude 订阅时，Claude Code 的主会话至少缓存 1 小时。间隔更久，缓存可能已失效，下次请求就会把大部分上下文重新写入缓存，价格是输入的两倍。我们的记录中，间隔至少 1 小时的 357 次请求有 355 次如此。缓存写入量中位数为 365,288 token，按 Opus 5.5 标价约 $2.92。

Claude Code 的闲置压缩是什么？

Claude Code 2.1.299 加入了闲置压缩：终端会话达到 200K token 后，闲置约 54 分钟就会在 1 小时缓存过期前变成摘要，下次只发送摘要。在我们的一次测试中，闲置 2 小时 12 分钟后回来，开启它花 $0.20，关闭则花 $3.28。在 settings.json 中设 "idleCompaction": false 可关闭它，CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 可把 200K 门槛最低调到 100K。

Claude Code 何时显示「恢复此会话？」提醒？（原文：“Resume this conversation?”）

从 2.1.304 起，Pro 和 Max 上的 Claude Code 只在预估恢复会消耗至少 5% 的 5 小时用量限额，且判断缓存无法复用时显示恢复提醒。按我们账户缓存的配置，Opus 5.5 在 Max 5x 上约需 1.36M token，在 Max 20x 上约需 5.46M，都超过它的 1M token 窗口，因此不会出现恢复提醒。Fable 5.1 在 Max 5x 上约 300K token 即达到门槛。

怎样避免冷恢复的开销？

在 1 小时内回来，或换任务就新开会话。提到旧会话时，Claude 可以查回。保持闲置压缩开启，并确认它在连续运行数天的会话中确实执行过。留意发往闲置会话的定时提示：我们的记录里，约一半冷恢复由自动提示触发。