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

30 秒看懂结论

使用 Claude 订阅套餐且未超出套餐用量时，Claude Code 会把主会话写入提示词缓存，至少保留 1 小时。在这 1 小时内，下一次请求可以从缓存读取上下文；Opus 5.5 的缓存读取价是输入价的二十分之一。隔得更久，缓存条目可能已经被删除。下一次请求就需要重新写入相应的上下文，写入价是输入价的 2 倍。

10 月的两次更新都与这笔开销有关。Claude Code 2.1.299（10 月 14 日）的更新日志宣布了闲置压缩（idle compaction）：终端里的会话达到 20 万 token，闲置约 54 分钟后，会在缓存过期前压缩。2.1.304（10 月 19 日）又为 Pro 和 Max 套餐加入了恢复提醒。按更新日志的说法，恢复闲置会话会占用 5 小时用量限额的“明显份额”时，就会提醒（原文：“would use a noticeable share of your 5-hour usage limit”）。

这两项功能能帮上多大忙？我们统计了自己的会话记录，查看了恢复提醒的判断逻辑，又做了一次闲置压缩实验：

• 记录里有 355 次请求重新写入了至少一半上下文。从 7 月 10 日到 10 月 25 日，我们统计了 46 个主会话。其中，355 次请求距上一次请求至少 1 小时，且至少一半上下文重新写入了缓存；250 次的写入占比达到 95%。中位写入量为 365,288 token。按 Opus 5.5 标价折算，这些写入共 $1,151，占这些会话总花费 $2,074 的 55%。
• 间隔不到 1 小时，大多仍能命中缓存。间隔 5–60 分钟的 270 次请求中，有 266 次主要从缓存读取上下文。
• 冷恢复主要集中在长驻会话。全部 355 次都出自 19 个会话，最多的一个发生了 101 次。约一半由自动提示触发，大多是定时巡查。
• 这些会话从未触发闲置压缩，原因不明。所有会话记录里都没有闲置压缩。它们已在 2.1.283 和 2.1.293 上运行数周，但 2.1.283 的二进制文件里已经有受功能开关控制的闲置压缩代码。
• 按我们账户缓存的配置，Max 套餐使用 Opus 5.5 时看不到恢复提醒。客户端估算恢复会占用至少 5% 的 5 小时用量限额，才会显示提醒。Opus 5.5 在 Max 5x 上要约 136 万 token 才达到这个门槛，超过了 100 万 token 的上下文窗口。Fable 5.1 在 Max 5x 上则约 30 万 token 就会触发。
• 新建的 2.1.310 会话成功触发了闲置压缩。一个 42.1 万 token 的会话在闲置 54 分钟时被压缩，花费约 $0.18。第一次回来后又闲置了 2 小时 12 分钟，第二次回来时，压缩过的会话写入 24,738 token，花费 $0.20；内容相同但关闭了闲置压缩的会话写入 409,710 token，花费 $3.28。

结论：保持闲置压缩开启。压缩真的运行时，可以在较长时间后回来时用摘要替代大段旧上下文，减少缓存写入。在我们这台机器上这一对会话的实验中，第二次回来那一次请求的花费分别是 $0.20 和 $3.28；把压缩与两次返回都算上，分别是 $0.58 和 $3.51。代价是 Claude 此后要依据摘要处理较早的历史。对于连续开着好几天的会话，还要确认压缩确实发生了：终端会提示“已在闲置时压缩”（原文：“Compacted while idle”），我们的长驻会话却一次也没有。至于 Max 套餐上的 Opus 5.5，按我们看到的那份配置，等不到恢复提醒。

10 月更新了什么

恢复提醒会问“是否恢复此会话？”（原文：“Resume this conversation?”），并列出会话闲置了多久、有多少 token，以及恢复预计会占用多少 5 小时用量限额。你可以继续这个会话，也可以新开一个。提醒还说明，以后提到旧会话时，Claude 可以去查阅（原文：“Claude can look this one up if you refer to it later”）。

恢复会话 为什么有开销

以 Opus 5.5 为例，每百万 token 的普通输入价是 $4，1 小时缓存的写入价是 $8，缓存读取价则是 $0.20。每次请求都会重新发送整个会话。因此，上下文能从缓存读取多少、又需要重新写入多少，往往决定了大部分花费。

默认使用 1 小时缓存的范围有限：仅适用于 Claude 订阅套餐在套餐用量内的主会话。如果使用 API 密钥、云服务，或订阅已转为消耗用量额度（Usage credits），Claude Code 主会话默认使用 5 分钟缓存，也可以通过 promptCacheTtl 自行设置。

我们取出截至 10 月 25 日 19:18 UTC 的所有主会话请求，排除子代理会话记录。对每次请求，先算出它与同一会话上一次请求的记录间隔，再看上下文主要来自缓存读取，还是主要重新写入了缓存：

在间隔不到 1 天的请求中，所有缓存写入都采用 1 小时缓存。间隔 5–60 分钟的请求大多从缓存读取上下文，因此花费很低。间隔超过 1 小时后，几乎每次请求都重新写入了大部分上下文。

会话记录里 发生了什么

本文把同时满足以下条件的请求叫作冷恢复：它与同一会话上一条请求记录相隔至少 1 小时，输入上下文至少 2 万 token，且至少一半上下文重新写入了缓存。记录之间的间隔，只是距上一次请求多久的近似值。

符合这个口径的共有 355 次。上下文中位数是 384,785 token，中位写入量为 365,288 token。其中 250 次写入了至少 95% 的上下文，但仍有 176 次从缓存读取了部分上下文。另有 14 次同时更换了模型。按 Opus 5.5 标价折算，中位写入花费为 $2.92，最高为 $7.70；冷恢复前的间隔中位数为 9.9 小时。

这些请求分布很不均匀。46 个主会话中，只有 19 个出现过冷恢复，其中两个就占了 159 次和 $632。它们是我们刻意连续运行多天、不断发入任务的长驻会话。355 次冷恢复中，约一半由自动提示或系统追加的提示触发，大多是每日查收件箱、工作日早间检查这类定时巡查。其余大多是隔了一段时间后，又有人向会话发来消息。有一次，Claude 提问后等用户回答，等了两个多小时才继续。

闲置压缩从未在这些会话上运行。我们查过的所有会话记录里，一次也没有。长驻会话当时已经运行约四周，进程仍使用启动时的版本：2.1.283 和 2.1.293。更新要到下次启动 Claude Code 时才生效（原文：“take effect the next time you start Claude Code”）。2.1.299 发布后，这些会话发生了 86 次输入上下文至少 20 万 token 的冷恢复。

但版本旧解释不了这件事。2.1.283 的二进制文件里已经有受功能开关控制的闲置压缩代码，我们机器上缓存的开关值也是 compact。为什么没有触发，我们不知道。

恢复提醒 什么时候出现

官方文档没有给出恢复提醒的完整判断规则。我们查看了 2.1.310 的代码，发现 Claude Code 会在客户端估算恢复占 5 小时用量限额的份额。算法是：上下文 token 数除以 100 万，乘以模型的折算系数，再乘以 100，最后除以套餐的 5 小时额度。原公式如下：

share = context tokens / 1,000,000 × rate for the model × 100 / 5-hour allowance for your plan

参与计算的上下文 token 数最多取到模型的上下文窗口上限，套餐档位则采用 Claude Code 当前识别到的档位。恢复提醒只在同时满足以下条件时出现：

• 客户端根据距上一次请求的时间，认为缓存已经过期，或者会话更换了模型。
• 当前没有被限流，也没有在使用用量额度。
• 估算份额达到 minPercent，默认值是 5，即 5%。

模型的折算系数和套餐额度都来自 Claude Code 下载的配置。我们查看了 10 月 25 日缓存在 ~/.claude.json 中的那一份：Max 5x 的额度是 50,000 点数，Max 20x 是 200,000 点数，另有 11 个模型的折算系数，没有 Pro 的额度条目。

用这份配置计算，结果如下。表中的触发门槛是近似值：

超过 100 万 token 的门槛，不可能在 100 万 token 的上下文窗口内达到。因此，仅按这份配置，两个 Max 档位使用 Opus 5.5 时，都不会显示恢复提醒。

我们也实际恢复了一个闲置 10 天、已有 76.4 万 token 的会话，使用 Opus 5.5 和 Max 20x 套餐，确实没有看到提醒。按公式算，它只占 5 小时用量限额的 0.7%。换成 Max 5x 上的 Fable 5.1，约 30 万 token 就会触发；Opus 4.6 的门槛则约为 50 万 token。

这些都是 Claude Code 根据下载配置做的估算，配置可能变化。我们没有拿这些估算去核对用量表；能看到的用量表只显示整数百分比。

我们怎么测的

我们在 Claude Code 2.1.310 终端里建立了两个内容相同的会话，都先放入完整的 Claude Code 更新日志。加上终端自带的提示后，每个会话约有 42.1 万 token 的上下文。19:25 UTC，我们分别发了一条单行消息热身，然后不再操作。A 保持闲置压缩的默认开启状态，B 设置 "idleCompaction": false。下文花费来自会话记录和 /cost 的会话面板（界面名称为 Session），统一按 Opus 5.5 标价折算。

A 按文档描述的时间触发了压缩。终端也给出提示：已在闲置期间、提示词缓存过期前完成压缩（原文：“Compacted while idle, before the prompt cache expired”）。20:27，距热身已过 61.5 分钟，B 这次请求仍从缓存读出了 402,067 token。

第一阶段的 A/B 对比被共享缓存干扰，无法说明 B 的缓存本来能撑多久。两个会话的前缀相同，同一目录下的会话可以互相读取缓存（原文：“can read each other’s cache”）。A 在 8 分钟前压缩时，刚读过同一份前缀，而读取会刷新缓存条目的寿命。Anthropic 说的缓存寿命是最低保留时间；过期后会“及时，但不是立即”删除（原文：“promptly, though not immediately”）。把压缩算上，从热身之后到这次返回，A 累计花费 $0.38，B 为 $0.23。

第二次回来时，花费才拉开差距。我们让两边再次闲置，在 22:39 UTC 向 A 发消息，22:40 UTC 向 B 发消息，距各自上一次请求约 2 小时 12 分钟。两份会话记录在这段时间内都没有别的模型请求。A 先发，但它已经不再发送那份更新日志，因此刷新不了两边此前共享的那份缓存。

这一次，B 从缓存读了 11,334 token，写入 409,710 token，约占上下文的 97%，花费 $3.28。它的会话面板将“闲置超过 1 小时缓存期限”列为可能原因（原文：“idle past the 1h TTL”）。A 此时发送的是摘要加终端自带的开场提示，从缓存读取 12,710 token，写入 24,738 token，花费 $0.20。从热身之后算，A 累计 $0.58，B 累计 $3.51。

A 付出的代价是历史细节。摘要替换了更新日志和较早的消息，这次只有最后一条回复原样保留。摘要也会告诉 Claude 完整会话记录文件在哪里，需要细节时可以再去读取。

实验中还有两点值得留意。压缩后，A 的会话面板记录了 1 次预期内的重建，原因可以是压缩或清理工具结果（原文：“1 expected rebuild (compaction or tool-result clearing)”）。两边的面板还会显示主会话缓存是否仍能命中，以及距上次使用过了多久。2.1.310 面板里的缓存状态，是客户端按时间戳推算的，没有向服务端确认。恢复大体量会话前，可以用它快速了解客户端的判断。

我们查看的 2.1.310 代码还会在以下情况跳过闲置压缩：自动压缩或闲置压缩已关闭、上下文未达到门槛、有更新的请求到达、定时器触发晚了超过 1 分钟、缓存前缀发生变化，或限流状态不再是“允许”（原文：“allowed”），例如已经接近用量限额时。

怎样减少 冷恢复的开销

• 尽量在 1 小时内回来，新任务可以另开会话。新会话只需发送开场上下文；需要旧内容时，可以让 Claude 查阅之前的会话。
• 留意发往闲置会话的定时提示。一个大体量会话闲置超过 1 小时后收到提示，往往需要重新写入大量上下文。我们的记录中，约一半冷恢复由自动提示触发。
• 保持闲置压缩开启。如果会话通常不到 20 万 token，可以调低 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS，最低可设为 10 万 token。
• 使用 Opus 5.5 时，别等恢复提醒再做决定。按我们看到的配置，Max 套餐不会显示这个提醒。假设恢复一个 40 万 token 的会话，并将全部上下文写入 1 小时缓存，Claude Code 估算它约占 Max 5x 的 5 小时用量限额的 1.5%，按标价折算则是 $3.20。
• 压缩后，Claude 要按摘要处理较早的历史。较早的消息被摘要替换，最近的消息仍原样保留。完整历史留在会话记录文件里，摘要会告诉 Claude 去哪里查。

这些情况没测

• 其他人的使用情况。全部 355 次冷恢复都来自我们一台机器，而且大多出自我们刻意长期运行的会话。晚上会关掉终端的开发者，使用情况会不同。
• 长驻会话为什么没有触发闲置压缩。所有会话记录里都找不到闲置压缩，我们也没能查明原因。
• 用量表是否与估算吻合。上面的份额是 Claude Code 按下载配置算出来的；我们能看到的用量表只报告整数百分比，没有据此核对估算。
• Pro 套餐和其他账户。我们账户缓存的配置没有 Pro 的额度条目，其他账户也可能收到不同的值。
• 实际账单价格。所有流量都统一按 Opus 5.5 标价折算，包括它在 9 月 22 日发布之前的会话。订阅套餐实际消耗的是用量，不是美元。
• 更多闲置压缩实验。这里只有一台机器上的一对会话，内容来自同一个文件，而且第一阶段的 A/B 对比被共享缓存干扰。

相关阅读

• Opus 5.5 发布后，代理流量到底花多少钱：为什么代理的大部分花费来自缓存写入。
• Claude Code 用量限额：5 小时用量限额和每周用量限额怎样运作。
• Claude Code 上下文管理：压缩、/clear，以及怎样控制上下文大小。
• 如何管理一组长驻代理：本文大部分冷恢复所处的运行环境。
• Codex CLI 的后台守护进程，以及 Claude Code 留下的进程：长驻会话背后有哪些持续运行的进程。

来源

1. Anthropic：Claude Code 更新日志，2.1.299、2.1.302 和 2.1.304 的条目。查阅日期：2026 年 10 月 25 日。
2. npm：@anthropic-ai/claude-code，2.1.299（2026 年 10 月 14 日 00:23 UTC）、2.1.302（10 月 16 日 16:48 UTC）和 2.1.304（10 月 19 日 19:47 UTC）的发布时间。
3. Anthropic：Claude Code：提示词缓存，其中“各类请求使用哪种缓存期限”和“自行选择缓存期限”两节（原文：“Which TTL each request gets”、“Choose the TTL yourself.”）。
4. Anthropic：提示词缓存，缓存写入的价格倍数，以及 Opus 5.5 缓存读取按输入价的 5% 计费。
5. Anthropic：Claude Code：设置参考，idleCompaction 的触发条件，以及“已在闲置期间、提示词缓存过期前完成压缩”的提示（原文：“Compacted while idle, before the prompt cache expired”）。
6. Anthropic：Claude Code：环境变量，CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS。
7. Anthropic：安装与配置 Claude Code，“自动更新”一节（原文：“Auto-updates.”）。

我们自己的测量均来自一台 macOS 机器，测量日期为 2026 年 10 月 25 日。依据包括：~/.claude/projects 下截至 19:18 UTC 的全部主会话记录，共 46 个会话、从 7 月 10 日起的 7,121 次独立请求；Claude Code 2.1.310 二进制文件里的恢复提醒文案和判断逻辑，以及 2.1.283 里的闲置压缩代码；~/.claude.json 中缓存的配置；在终端恢复一个 76.4 万 token 闲置会话的实测；以及在 Claude Code 2.1.310 上，让两个 42.1 万 token 的会话分别开启、关闭闲置压缩，再各自闲置两轮的对照实验。

FAQ

为什么恢复闲置的 Claude Code 会话，会占用那么多用量？ 使用 Claude 订阅套餐且未超出套餐用量时，Claude Code 主会话的提示词缓存至少保留 1 小时。在这 1 小时内，下一次请求通常从缓存读取大部分上下文；Opus 5.5 的缓存读取价是输入价的二十分之一。隔得更久，缓存条目可能已经被删除，需要重新写入相应的上下文，写入价是输入价的 2 倍。我们统计的请求中，间隔 5–60 分钟的有 270 次，其中 266 次主要从缓存读取；间隔至少 1 小时的有 357 次，其中 355 次重新写入了大部分上下文。后者的中位写入量为 365,288 token，按 Opus 5.5 标价折算约 $2.92。

Claude Code 什么时候会显示恢复提醒？ Claude Code 2.1.304 为 Pro 和 Max 套餐加入了恢复提醒。按 2.1.310 的代码，客户端先用上下文 token 数乘以模型的折算系数，再按套餐的 5 小时额度估算占比。只有 Claude Code 认为缓存已过期或模型已更换、账户尚未被限流且未使用用量额度、估算占比达到 5% 时，才会显示提醒。按我们账户 10 月 25 日缓存的配置，Opus 5.5 在 Max 5x 上需要约 136 万 token，在 Max 20x 上需要约 546 万 token，才会达到 5%，均超过 100 万 token 的上下文窗口。Fable 5.1 在 Max 5x 上约 30 万 token 就能达到。配置由客户端下载，可能变化。

Claude Code 的闲置压缩是什么？ 闲置压缩会在你离开后压缩会话，让下一条消息携带较早消息的摘要，最近的消息仍原样保留。2.1.299 的更新日志宣布了这项功能：交互式终端里的会话达到 20 万 token，闲置约 54 分钟后，会在 1 小时缓存过期前压缩。它还要求自动压缩开启、使用 1 小时缓存、能够获取功能开关，并且电脑在触发时保持唤醒。CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 可以调整默认的 20 万 token 门槛，最低设到 10 万；在 settings.json 中设置 "idleCompaction": false 可以关闭。在我们的 2.1.310 实验中，42.1 万 token 的会话在最后一次请求的 54 分钟后触发压缩，耗时 7 秒，按标价约 $0.18。第一次回来后又闲置了 2 小时 12 分钟，第二次回来时，压缩过的会话写入 24,738 token，花费 $0.20；内容相同但关闭了闲置压缩的会话写入 409,710 token，花费 $3.28。

闲置压缩为什么没帮到我们的长驻会话？ 我们不知道。所有会话记录里都没有闲置压缩。我们的长驻会话已经运行约四周，使用的是 Claude Code 2.1.283 和 2.1.293。2.1.299 发布后，它们发生了 86 次输入上下文至少 20 万 token 的冷恢复。但 2.1.283 的二进制文件里已经有受功能开关控制的闲置压缩代码，单凭版本旧解释不了。

怎样减少冷恢复的开销？ 尽量在 1 小时内回来。新任务可以另开会话，避免恢复庞大的旧会话；需要旧内容时，可以让 Claude 查阅之前的会话。保持闲置压缩开启。如果定时向一个大体量的闲置会话发送提示，间隔超过 1 小时，往往每次都需要重新写入大量上下文。我们的记录中，约一半冷恢复由自动提示触发，大多是定时巡查。