Claude Code默认开启Recap功能消耗Token，建议手动关闭

背景

随着 AI 编程助手的普及，开发者与大型语言模型（LLM）的交互频率日益增加。Claude Code 作为一款基于 Claude 模型的终端编程助手，其用户体验的流畅性与资源消耗之间的平衡成为关注焦点。近期，Codex-app 的更新引发了关于“自动建议”功能过度消耗 Token 的讨论，而在同一社区（LINUX DO · AI）中，用户进一步挖掘了 Claude Code 中另一个常被忽视的资源消耗点：/recap 功能。

该功能在 v2.1.108 版本后默认开启，旨在提升用户中断工作后重新进入上下文的能力。然而，对于注重 Token 成本控制或依赖中转服务切换账号的用户而言，这一“贴心”功能可能带来意想不到的额外开销。本文旨在深入解析 /recap 的工作原理、触发机制及关闭方法，帮助开发者优化使用体验并控制成本。

核心内容

功能定义与触发机制

/recap 是 Claude Code 在 v2.1.108 版本更新后默认启用的一项会话摘要功能。其核心设计初衷是解决用户离开会话（Session）一段时间后，重新连接时可能面临的上下文丢失问题。当用户再次回到界面时，系统会自动弹出一段摘要，简要回顾“用户之前在做什么”以及“下一步计划是什么”。

该功能支持两种触发方式：

1. 自动触发：当用户离开当前会话超过约 5 分钟，系统会自动执行摘要生成流程。
2. 手动触发：用户可以在命令行中手动输入 /recap 命令来强制生成摘要。

工作原理与技术细节

/recap 的运行逻辑涉及对当前会话历史数据的打包与模型推理，具体流程如下：

1. 数据打包：系统会将整个当前 Session 的完整对话历史（messages）提取出来。
2. Prompt 注入：在历史消息末尾追加一条特定的系统提示词（Recap Prompt），内容如下：

   The user stepped away and is coming back. Recap in under 40 words, 1-2 plain sentences, no markdown. Lead with the overall goal and current task, then the one next action. Skip root-cause narrative, fix internals, secondary to-dos, and em-dash tangents.

   （译文：用户暂时离开并即将返回。请在 40 字以内，用 1-2 句纯文本进行回顾，不要使用 Markdown。首先陈述总体目标和当前任务，然后指出下一个行动。跳过根本原因分析、内部修复、次要待办事项和破折号引导的枝节内容。）

3. 模型推理：使用 Sonnet 模型对打包后的消息进行处理，生成摘要。
4. 结果展示：将生成的摘要展示在界面上。

资源消耗与缓存问题

尽管 /recap 生成的摘要较短，但其背后的 API 请求成本不容忽视，主要原因在于缓存命中率不稳定：

• 缓存机制：理论上，系统可能通过缓存参数判断是否重复生成摘要，以减少不必要的 API 调用。
• 实际观测：有用户观察到，在特定场景下（如使用中转服务切换账号），缓存命中率可能低于 10%。这意味着绝大多数情况下，每次触发 /recap 都会产生一次完整的 API 请求。
• Token 消耗：由于需要将“整个当前 session 的对话历史”全部打包发送给模型，即使最终生成的摘要很短，输入端（Input）的 Token 消耗依然巨大。对于 Token 敏感型用户或按量付费的中转服务用户，这是一笔不小的额外开支。

关闭方法

为了节省 Token 并避免不必要的 API 请求，用户可以通过以下三种方式禁用 /recap 功能：

1. 通过配置命令关闭： 在终端中输入 /config，找到 Session recap 选项，将其设置为 False。

2. 修改配置文件： 直接编辑用户主目录下的配置文件 ~/.claude/config.json，添加或修改以下字段：

   "awaySummaryEnabled": false
   

3. 通过环境变量关闭： 设置环境变量 CLAUDE_CODE_ENABLE_AWAY_SUMMARY 为 0：

   export CLAUDE_CODE_ENABLE_AWAY_SUMMARY=0
   

关键要点

• 默认开启：/recap 功能在 Claude Code v2.1.108 及之后版本中默认启用，旨在提供会话中断后的上下文恢复。
• 触发条件：自动触发需离开会话约 5 分钟；也可通过手动输入 /recap 触发。
• 高成本原因：每次触发（尤其是缓存未命中时）需将完整会话历史打包发送给 Sonnet 模型，导致输入 Token 消耗巨大。
• 缓存不可靠：实际使用中发现缓存命中率可能极低（<10%），特别是在使用中转服务时，导致频繁的 API 请求。
• 关闭方案：可通过 /config 命令、修改 ~/.claude/config.json 中的 awaySummaryEnabled 字段，或设置环境变量 CLAUDE_CODE_ENABLE_AWAY_SUMMARY=0 来禁用该功能。

意义与影响

这一发现揭示了 AI 编程工具在“用户体验优化”与“资源成本控制”之间存在的潜在矛盾。对于普通用户而言，/recap 提供的上下文恢复功能确实能提升工作流的连贯性；但对于重度开发者、Token 预算有限者或依赖中转服务的用户，这一默认开启的功能可能成为隐形的成本黑洞。

该案例也提醒开发者和技术社区：

1. 默认设置的权衡：软件默认开启的功能未必适合所有用户群体，提供清晰、易用的关闭入口至关重要。
2. 透明化资源消耗：工具应更透明地展示后台 API 请求的频率和 Token 消耗，帮助用户做出知情决策。
3. 缓存策略的优化：对于高频触发的摘要功能，优化缓存策略或采用更轻量级的本地摘要算法，可能是平衡体验与成本的关键方向。

通过主动关闭 /recap，用户可以显著降低无谓的 API 请求，将宝贵的 Token 资源集中在核心的代码生成与调试任务上，从而实现更高效、更经济的 AI 辅助编程工作流。