Claude Code 空闲压缩可节省缓存，但会从摘要继续

Claude Code 的空闲压缩现可在提示缓存过期前总结大型会话，即使上下文窗口尚未填满。该功能默认面向至少包含 20 万 token 的会话。其核心权衡十分鲜明：Claude 会回到成本更低、长度更短的上下文，但将基于生成的摘要继续，而非保留每一轮原始对话。

Anthropic 工程师 Lydia Hallie 在 2026 年 10 月的一篇空闲压缩帖子中介绍了这一行为。用户可以在 Claude Code 设置文件中添加 "idleCompaction": false 来禁用该功能；也可以通过 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 调整最低上下文阈值。

这项控制功能推出之前，开发者曾报告在长时间运行的会话中出现意外压缩。他们担忧的并非压缩功能本身。Claude Code 原本就会在对话接近上下文上限时进行总结。争议在于，空闲计时器是否应在缓存过期后，为降低重新返回的成本而替换仍可使用的完整对话记录。

Claude Code 空闲压缩改变了“恢复会话”的含义

恢复后的会话可以保留自身身份，但可能失去最初建立该身份的逐字历史记录。

Claude Code 会在本地保存会话消息，并支持通过 --continue 或 --resume 重新打开它们。这种持久化机制会让会话像一个可长期使用的工作空间。不过，模型只能基于当前请求中发送的上下文进行推理，而非磁盘上保存的所有内容。

Anthropic 的上下文窗口指南说明，活跃上下文包含对话历史、文件内容、命令输出、项目指令、记忆、技能和系统指令。随着这些材料不断积累，Claude Code 会清除较早的工具输出，并最终总结对话。

压缩是指用更短的摘要替换较早的对话材料。会话仍然可用，Claude 也可以继续工作。然而，模型不再逐字接收每一轮被替换的内容。

新的空闲路径改变了这种替换可能发生的时机。传统自动压缩会响应逐渐缩小的上下文预算；空闲压缩则会响应不活动状态和提示缓存时机，前提是会话规模足够大。

用户在将会话闲置后，开始报告看到“Compacted while idle, before the prompt cache expired”消息。相关报告将此次推出与 Claude Code 2.1.286 联系起来，尽管该行为部分由服务器端开关控制。这意味着，仅安装某个特定客户端版本，并不一定能反映完整的推出状态。

Hallie 报告的默认最低值，以及 Anthropic 公开仓库中讨论的数值，均为 20 万 token。该数字是资格阈值，并不承诺对话恰好达到 20 万 token 时就会发生压缩。

符合条件的会话还需要满足相关缓存条件，并经历足够长的空闲时间。社区对空闲压缩 issue的调查发现，计时器接近一小时提示缓存周期的末尾。用户观察到，可见事件会在最后一次活动后的约 54 至 56 分钟出现。

这些时间细节来自 issue 参与者对客户端行为的检查和本地测试。Anthropic 的公开 Claude Code 文档最初并未提供完整的空闲压缩规范。因此，读者应区分三类证据：Anthropic 对压缩的说明、该工程师的公告，以及社区对实现细节的分析。

这些来源一致表明，已验证的产品后果十分明确：空闲压缩后，Claude 将从压缩后的对话状态恢复。原始记录可能仍存在于本地，但其完整内容不再自动出现在模型的工作上下文中。

这一差异很重要，因为本地持久化和模型注意力解决的是不同问题。已保存的记录支持审计和恢复；活跃上下文则决定 Claude 在下一次响应时能够考虑什么。

该功能以缓存效率换取上下文保真度

空闲压缩会将工作从一次可能的冷缓存返回，转移到最后的热缓存窗口；它接受摘要造成的信息损失，以减少重复处理上下文。

提示缓存允许重复请求复用相同的输入前缀。与缓存条目过期后重新构建相同的大型前缀相比，缓存命中通常需要更少的输入处理。长时间运行的 Claude Code 会话会形成异常庞大的可复用前缀，因为每一轮都可能包含先前消息、工具活动和项目材料。

Anthropic 的提示缓存文档介绍了缓存生命周期，以及缓存写入与读取的不同处理方式。一个变冷的长会话，可能要求 Claude Code 在用户返回时再次处理大量前缀内容。

空闲压缩试图在此之前介入。当大型前缀仍保留在缓存中时，Claude Code 可以要求模型对其进行总结。后续请求将从较短的摘要，以及 Claude Code 恢复的指令或项目材料开始。

当用户打算在休息后恢复大型会话时，这一机制有利于提升效率。用户返回时无需携带完整旧上下文，而是使用需要处理更少 token 的压缩表示。

代价是信息保真度。摘要会保留部分事实和决策，但无法保证精确保留每一项约束、被放弃的方案、测试观察结果或对话中的修正。

Anthropic 在其上下文文档中承认了这一普遍限制。文档称，请求和关键代码片段会在压缩期间保留，而早期对话中的详细指令则可能丢失。

在代理式编程会话中，这一警告的影响更为显著。一项细微指令可能决定允许采用哪条迁移路径；一个被否定的假设可能阻止 Claude 重复成本高昂的调查；一次小型测试异常可能解释为何看似显而易见的修复并不安全。

这些细节对总结器而言可能看似次要，但对下一步编程工作仍可能具有决定性意义。摘要可以准确描述项目的整体目标，却仍遗漏限制其实现方式的证据。

在漫长、探索性的会话中，风险会进一步增长。开发者可能要求 Claude 检查多个模块、比较相互竞争的设计、运行测试，并放弃两种方案。最终方向可能依赖于散落在命令输出和简短修正中的负面结果。

压缩后，Claude 或许记得选择了某一种方案，却不再保留其他方案失败的全部原因。它随后可能重建出一种看似合理、但不同于实际调查过程的解释。

这并不意味着压缩本身存在缺陷。任何有限的上下文管理系统都无法逐字保留无限历史。争议在于时机和用户意图。

接近硬性上下文上限时，总结可防止会话停止。但在缓存过期前，产品选择了效率，即使会话可能仍拥有大量剩余上下文容量。

这正是本文的主要对立面：缓存效率与上下文保真度。它并非 Claude Code 与另一款编程助手之间的竞争。每个长时间运行的代理最终都必须管理有限上下文，但空闲触发机制让 Anthropic 所选择的平衡格外明显。

开发者为何反对自动摘要

反弹的核心在于未经通知的状态变化，而非上下文压缩本身的存在。

手动输入 /compact 的开发者知道 Claude 将总结此前的对话。该命令可以包含重点，例如保留 API 决策或尚未解决的测试失败。这一刻自然形成了一个审查边界。

空闲压缩取消了这一即时选择。用户可能去吃午饭、参加会议，或等待外部反馈，回来时会发现会话的活跃历史已经改变。

最初的 GitHub 报告称，多个工作会话在空闲时被压缩。报告者表示，摘要遗漏了精确指令、决策推理和此前商定的方法。其他用户则报告称，即使尚未接近其配置的上下文阈值，也看到了相同通知。

这些是用户报告，并非针对摘要准确性的受控测量。尽管如此，它们指出了可信的产品风险，因为 Anthropic 的文档已说明，压缩过程中早期细节可能丢失。

初始实现也让监控变得更加复杂。根据 issue 中记录的测试，早期空闲压缩在 hook 元数据中似乎显示为 manual，尽管没有用户输入 /compact。

Claude Code hooks 允许团队在定义的事件前后运行自动化。误导性的触发标签会使团队更难区分用户有意执行的操作与计时器驱动的状态转换。

根据仓库中 Anthropic 协作者的说法，Claude Code 2.1.290 将该触发器改为了 auto。这将空闲压缩与显式调用的 /compact 区分开来，但仍未能完全区分空闲压缩与普通的阈值自动压缩。

这种模糊性对使用 hooks 保存工作状态的团队很重要。一个 hook 可能希望在紧急的上下文上限压缩前采用一种策略，而在缓存驱动的空闲压缩前采用另一种策略。

issue 讨论要求提供独立的 idle 触发器。根据所报告的 2.1.290 行为，空闲事件和上下文阈值事件都可能显示为 auto。终端通知会向人工用户标识空闲事件，但该通知未必会包含在 hook 输入中。

更广泛的产品教训关乎不可见的优化。当优化只改变延迟或资源使用，而不改变语义时，开发者通常会接受它。摘要可能改变语义，因为下一次模型请求会接收到不同的证据。

这使空闲压缩更像一次自动状态迁移，而非后台清理任务。会话标识符保持稳定，而推理的底层基础发生了变化。

运行高风险迁移、事件响应或长期代码审查的团队，有理由谨慎对待这一转换。他们的会话通常会积累单独看很小、但总体上十分重要的约束。

较短的会话受到的影响较小，因为它们低于最低阈值。已围绕显式交接构建的工作流也会降低成本，因为关键状态存在于聊天记录之外。

因此，压力主要落在那些将一个长 Claude Code 会话视为持久项目伙伴的开发者身上。他们从连续性中获益最多，但当连续性在没有明确边界的情况下变得依赖摘要时，他们失去的也最多。

idleCompaction 设置区分了两种不同的保护机制

用户可以禁用空闲压缩，而无需禁用保护接近上下文上限会话的自动压缩。

根据一位 Anthropic 协作者在公开 issue 中的回应，Claude Code 2.1.290 引入了专用设置。随后，一名用户确认该选项可在 2.1.291 版本中正常工作。

基本配置如下：

Claude Code 支持多个作用域的设置，包括用户、项目、本地项目和受管政策级别。Anthropic 的设置参考说明了它们的位置和优先级。

适用于全体用户的偏好可写入个人设置文件。当团队成员都应共享相同行为时，代码库团队可将项目设置纳入版本控制。本地项目设置则可在不修改代码库共享配置的情况下覆盖行为。

关键区别在于 idleCompaction 与 autoCompactEnabled。前者针对新的基于计时器的路径，后者则控制更广泛的自动压缩行为。

将 "idleCompaction": false 设为关闭，可保留基于常规阈值的压缩机制，即版本 2.1.290 所述的行为。这适合希望在上下文窗口接近满载时仍有保护措施、但不希望在暂停期间触发由缓存驱动的摘要的开发者。

这种区分直接回应了用户最强烈的诉求。在专用开关出现之前，更广泛地禁用自动压缩，也可能一并移除防止会话达到上下文上限的保护机制。

用户不应假定该键一定可用，而应先确认已安装的版本。运行：

公开 issue 显示该设置位于 2.1.290 版本中，而一位用户明确确认其在 2.1.291 中可用。使用受管安装的组织也可能按照受控节奏接收更新。

该功能的服务端开关也带来了另一层谨慎理由。将 idleCompaction 设为 true 并不必然会迫使 Anthropic 为每个账户或环境启用这一功能；它仅允许客户端在其他资格条件满足时执行该行为。

对于需要退出该功能的用户，将其设为 false 才是相关控制项。团队仍应在自己的安装版本、账户类型和政策层级下测试实际行为。

受管设置可能优先于用户选择。这适合采用集中配置的组织，但也意味着编辑某一个本地文件未必会产生预期结果。

最稳妥的验证方式是观察实际行为：确认客户端版本、检查生效设置，并先在非关键会话中测试，再在重要工作中依赖该选项。

用户还应将持久性指令保存在对话历史之外。Anthropic 建议将长期规则放入 CLAUDE.md，Claude Code 会将其作为项目上下文加载。无论是否启用闲置压缩，这一建议都适用，因为接近上下文上限时的常规压缩仍可能发生。

可搜索的工程知识库也能为人工团队发挥类似作用。决策、约束和调查结果将成为可恢复的产物，而不必完全依赖某一段代理会话。

200K 阈值可调整，但它不是上下文上限

`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` 改变的是会话何时符合闲置压缩条件，而不是模型上下文窗口的大小。

Hallie 表示，最低值默认为 200,000 个 token。用户可通过 Claude Code 设置中的环境配置提供其他整数值。

例如：

该示例将符合条件的阈值提高到 400,000 个 token。它不会提供更大的上下文窗口、不会为对话历史预留 400,000 个 token，也不保证压缩会恰好在该节点立即触发。

公开 issue 的分析称，下限为 100,000 个 token。低于这一底线的值会被提升至 100,000。讨论发生时，Anthropic 尚未在公开设置参考中完整记录这一环境变量，因此用户应将实现细节视为与版本相关。

提高阈值有利于保真度。更多大型会话可在不被摘要的情况下保持闲置，但在缓存过期后返回时，可能需要处理更多输入内容。

降低阈值则有利于缓存效率。更多会话会在缓存过期前获得压缩资格，从而增加用户返回后看到摘要而非完整对话历史的可能性。

合适的数值取决于工作流形态，而不只是模型容量。包含重复工具输出的长会话可能易于摘要；而较短的架构讨论可能包含密集、相互依赖且难以压缩的决策。

Token 数量衡量的是规模，而非语义重要性。一次 300,000-token 的调试会话可能包含数千行可丢弃的日志；一次 120,000-token 的安全审查则可能包含大量应原样保留的精确威胁假设。

这正是可配置最低值虽有帮助，却无法消除核心矛盾的原因。它让团队能够选择从何处开始权衡，但单一数值阈值无法识别当前对话是否适合摘要。

开发者可在离开会话前创建明确的检查点。要求 Claude 在代码库笔记中记录当前目标、已确认发现、被否决的方法、已修改文件、测试状态和下一条命令。

该笔记不应只是重述任务，而应记录恢复工作所需的证据，避免重新构建整段对话。

持久性约束应放在 CLAUDE.md 或其他权威项目文件中。临时发现应记录在 issue、工作日志或交接文档中。生成的摘要便可支持连续性，而不会成为唯一记录。

团队也可使用 /context 检查正在占用活动窗口的内容。如果大量命令输出占据主导，清除或重构这些内容可能比让通用摘要自行决定重要事项更安全。

手动 /compact 在自然边界处仍然很有价值。Anthropic 表示用户可添加聚焦指令，这会比无人看管的闲置事件为摘要器提供更明确的保留目标。

更大的原则很简单：尽可能围绕任务边界进行压缩。Token 阈值可防止失败，但由人定义的边界更能反映工程工作的结构。

Claude Code 压缩会保留什么，以及它无法承诺什么

压缩保留的是会话的工作表征，而不是推理历史的无损副本。

Anthropic 的 Claude Platform 文档将压缩定义为：用模型生成的摘要替换较早的对话轮次。其压缩概览说明，应用程序会将返回的压缩块置于原先摘要消息所在的位置，以继续运行。

Claude Code 在产品内部处理这一工作流。其具体实现不同于直接使用 Claude API 的应用程序，但概念结果相似：较早输入会由生成文本来表征。

好的摘要可以保留用户请求、当前实现状态、重要文件路径、测试结果和剩余任务。它能大幅减少后续轮次所需发送的历史材料。

但它无法保证逐字保留每一次交流。摘要器必须在更小的 token 预算内选择信息、组织信息并表达出来。

推理历史带来了特别挑战。一次编程会话通常包含一连串排除过程。Claude 检查一个文件、形成假设、看到相互矛盾的输出，然后改变方向。

最终摘要可能会记录被接受的解释，同时压缩验证该解释的路径。这通常已足够，但会削弱下一模型审查该结论的能力。

工具输出带来了另一个问题。日志、编译器错误、数据库执行计划和测试追踪中，可能包含只有在之后才显现重要性的小细节。在该后续发现之前生成的摘要，不可能知道哪一行将会关键。

用户修正也可能失去力度。“不要修改 schema”或许只出现一次，随后便是数百轮对话。如果没有被提升为持久性指令，压缩可能会降低其显著性，甚至将其省略。

Claude Code 的文档明确建议将必须持续保留的规则放入 CLAUDE.md。它还支持“Compact Instructions”部分，用于告诉摘要器在压缩期间应保留什么。

这些机制能降低风险，但不能让摘要变为无损副本。压缩指令仍只是对执行信息选择的模型提供的指导。项目指令文件更可靠，因为 Claude Code 可以将其再次作为权威上下文加载。

因此，开发者应将会话知识分为三类。永久性操作规则应放在项目指令中；已验证的工程状态应保存在文件或受跟踪的工作记录中；对话式探索则可留在转录记录中，并接受最终被压缩的结果。

这种做法也能改善协作。另一位工程师无法可靠地继承私人代理对话中未被记录的细微信息。一份简洁的交接文件能为人类和代理提供共同的恢复点。

实际问题并非摘要是好是坏，而是某一具体事实能否安全地只存在于摘要之中。

如果丢失某项细节会导致不安全的迁移、重复发生的事故或无效结果，就应在离开会话前将其记录在对话之外。

三个信号将表明闲置压缩是否值得信任

下一项检验在于，Anthropic 能否让效率收益变得可观察，同时不让会话连续性变得不可预测。

第一个信号是官方文档。用户需要一份稳定的说明，涵盖资格条件、时机、支持的版本、阈值限制、设置优先级，以及与提示词缓存政策的交互。

文档还应澄清 200,000-token 的默认值是否在不同模型和账户之间一致适用。如果 Anthropic 记录这一环境变量及其下限，团队便可无需依赖 issue 考古来配置它。

这样的结果将增强人们对该功能的信心。若继续依赖社交帖子和二进制检查，则会削弱信心，因为未文档化的控制项可能发生变化，却没有明显的迁移路径。

第二个信号是明确区分的钩子元数据。专用的 idle 触发器将让团队能够以不同于手动 /compact 命令和接近上限时自动压缩的方式处理基于计时器的压缩。

组织可在闲置事件前快照保存状态、附加定制的压缩指令，或记录该功能激活频率的遥测数据。清晰的事件身份也会使事故调查更容易。

如果 Anthropic 继续将两种自动路径都归为同一个 auto 标签，管理员将难以了解会话为何发生变化。这会保留终端体验与自动化接口之间的鸿沟。

第三个信号是关于长编程会话中摘要质量的证据。用户报告指出了丢失的细微信息，但公开讨论尚未确立普遍的失败率。

有价值的评估应衡量摘要能否保留明确约束、被否决的假设、待办任务、测试失败、文件引用和安全规则。还应测试重复压缩，因为当一个压缩状态又成为另一个压缩状态的输入时，错误可能累积。

积极的结果将支持 Anthropic 的效率论证。它将表明，大多数符合条件的会话都能以足够准确的方式恢复，足以证明在缓存过期前自动压缩是合理的。

消极的结果则会加强采用自愿启用行为或提高默认阈值的理由。它还可能推动 Claude Code 转向部分压缩：在摘要较早材料的同时，逐字保留最近几轮对话。

目前，开发者有一个可行的选择：当较低的恢复开销比逐字连续性更重要时，保持启用 Claude Code 的空闲压缩。若只有超大型会话才值得接受这一权衡，则提高 token 阈值。

当暂停的会话必须在返回时完整保留现有的活跃历史记录，可通过 "idleCompaction": false 将其禁用。作为独立的保护措施，常规的上下文限制压缩仍可保持启用。

无论选择哪种策略，都不要让一段长对话成为关键工程状态的唯一记录。将持久性约束写入项目说明，把已验证的发现保存在文件中，并在离开前创建交接记录。

Claude Code 的空闲压缩揭示了编码代理的一个基本事实：会话连续性并不等同于完美记忆。在下一次长时间离开前，请确定你的工作流实际需要的是哪一种。