Claude Code 不用一种算法解决上下文膨胀。它根据缓存状态、信息价值和压缩成本，逐步删除工具结果、复用后台记忆，最后才调用模型重写整段对话。
这套设计的关键不是“压得多小”，而是尽量推迟信息损失和额外模型调用。
一条分层管线
Claude Code 的主查询大致按以下顺序处理历史消息：
原始消息
→ Snip
→ Microcompact
→ Context Collapse
→ Autocompact
→ 模型请求
Microcompact 位于 autocompact 之前。只要删除旧工具结果就能回到安全范围，Claude Code 就不必把整段对话总结成一条新消息。
几种机制处理的对象并不相同：
| 机制 | 处理对象 | 是否改变本地历史 | 是否需要新的模型调用 | 主要目标 |
|---|---|---|---|---|
| Cached Microcompact | 旧工具结果 | 否 | 否 | 保留缓存前缀 |
| Time-based Microcompact | 旧工具结果 | 是 | 否 | 缩小冷缓存请求 |
| Session Memory Compact | 已提取的会话记忆 | 是 | 压缩时不需要 | 快速重建上下文 |
| Full Compact | 整段对话 | 是 | 是 | 生成完整语义摘要 |
当前恢复代码除 Microcompact、Session Memory Compact 和 Full Compact 外，还包含 Snip、Context Collapse 和 API Context Management。Claude Code 在一条管线中依次尝试成本更高、信息损失更大的策略。
Microcompact 先删除低价值信息
工具结果通常是上下文中增长最快的部分。一次文件读取、搜索或 shell 命令可能产生数千 token，而模型后续真正需要的往往只是结论。
Microcompact 因此只处理一组明确的工具：
- Read
- Bash 和 PowerShell
- Grep
- Glob
- WebSearch
- WebFetch
- Edit
- Write
白名单把删除范围限制在可重新获取或容易失效的内容中。用户指令、模型回答和其他语义消息不会进入同一套删除逻辑。
这不是摘要。Microcompact 不生成更短的自然语言，而是直接移除或替换旧工具结果。它速度快、信息损失可控，也不需要额外调用模型。
热路径用缓存编辑
当服务端缓存仍然有效时，直接修改历史消息会产生一个问题：旧前缀的内容发生变化，已有 prompt cache 可能无法继续复用。
Cached Microcompact 的设计目标是在服务端缓存中删除部分工具结果，同时保持其余前缀可复用。客户端为旧 tool_result 建立引用，再通过 cache_edits 指定需要删除的结果。本地消息数组保持不变，编辑信息只在构造 API 请求时加入。
恢复代码采用数量阈值控制这条路径：
可压缩工具结果不超过 10 个
→ 不处理
超过 10 个
→ 删除较早结果
→ 保留最近 5 个
状态由 Claude Code 客户端维护。它记录已经出现和已经删除的 tool ID，并把已发送的编辑固定在原来的用户消息位置。API 请求层负责加入引用和编辑块，服务端才是实际执行缓存编辑的一方。
这条路径只用于主线程，因为 cached Microcompact 使用模块级共享状态。如果 Session Memory、提示建议等 fork agent 也注册自己的工具结果，主线程可能尝试删除并不属于自身对话的 ID。
冷路径直接改写历史
缓存已经过期时，继续维护缓存引用没有收益。Time-based Microcompact 会直接把旧工具结果替换为：
[Old tool result content cleared]客户端随后把缩小后的历史发送给 API。因为旧缓存本来就无法复用，这次改写不会额外牺牲一次有效的 cache hit。
恢复代码的默认时间阈值是 60 分钟，并明确把它解释为服务端的一小时缓存 TTL。这项功能默认关闭，需要远程实验配置开启。
冷热路径因此处理同一类信息，却采用不同动作：
缓存仍热
→ 不改本地历史
→ 请求服务端编辑缓存
缓存已冷
→ 直接改写本地历史
→ 缩小即将重新写入的请求
这里的决策依据是缓存经济性。
API Context Management 是另一套机制
恢复代码还使用 Anthropic API 的 context_management 字段。它与私有 cached Microcompact 有相似目标，但不是同一条协议。
其中的工具清理策略默认在输入达到 180,000 token 时触发，要求至少清除约 140,000 token，使剩余上下文接近 40,000 token。这些数字是恢复代码中的默认配置，不应直接视为所有 Claude Code 用户的线上参数。
同一个模块还定义了 clear_thinking。当前请求层始终传入 clearAllThinking: false，因此主请求保留全部 thinking。
恢复代码表明系统具备 clear_thinking 策略的表达能力，但当前主请求没有启用这项策略。
Session Memory 把总结提前到后台
删除工具结果只能缓解上下文增长，不能长期保存任务状态。Session Memory 负责把重要信息持续写入一个结构化的 Markdown 文件。
它通过后台 fork agent 周期性提取：
- 用户目标；
- 已完成工作；
- 关键决策；
- 文件和代码状态；
- 未完成任务。
恢复代码的默认配置是在上下文达到 10,000 token 后启动记忆；此后至少增长 5,000 token，并满足工具调用或自然对话边界条件时更新。默认工具调用阈值是三次。
当 autocompact 真正触发时，Claude Code 可以直接读取已经生成的 Session Memory，删除已被覆盖的旧消息，再保留少量最近历史。这个压缩动作本身不需要重新调用模型。
记忆内容由后台 fork agent 调用模型生成。Session Memory 优化的是 autocompact 的关键路径：
传统压缩
→ 上下文接近上限
→ 临时调用模型生成摘要
→ 用户等待
Session Memory
→ 后台增量维护摘要
→ 上下文接近上限
→ 直接读取已有记忆
模型调用被提前执行并分摊到会话过程中。
Full Compact 是最后的语义重写
Session Memory 可能不存在、内容为空、边界失效，或者压缩后仍然超过阈值。此时 autocompact 会退回 compactConversation()，调用模型生成完整摘要。
Full Compact 通过 fork agent 复用主对话的 prompt cache。请求限制为一轮，并在提示词开头和结尾反复要求模型只返回文本、不得调用工具。
完整历史与压缩指令
→ 单轮 fork agent
→ 生成结构化文本摘要
→ 删除旧消息
→ 恢复计划、文件和工具状态maxTurns: 1 控制了成本，也带来新的失败模式：如果模型在唯一一轮中尝试调用工具，就可能没有摘要文本，只能退回另一条生成路径。
源码注释记录，Sonnet 4.6 上这种 fallback 曾达到 2.79%，而 4.5 上约为 0.01%。因此代码后来加入更强的禁用工具提示。
完整总结通常是成本最高的路径，因为模型必须重新读取大段历史并生成新的语义表示。实际成本取决于上下文长度、缓存命中、模型、输出长度和计费策略，恢复代码未给出固定倍数。
恢复代码不能证明私有协议
这份仓库明确声明自己是反编译和恢复实现，而不是 Anthropic 发布的官方源码。
Cached Microcompact 尤其需要保留证据边界。
恢复仓库把真实的 cache-editing beta header 留成空字符串。请求层也明确说明，没有该 header 就发送 cache_reference 和 cache_edits 会得到 API 400。
代码内部还存在两套不一致的编辑结构：
Microcompact 层：
delete_tool_result + tool_use_id
API 请求层：
delete + cache_reference两者通过 as any 连接，没有可见的格式转换。因此这份仓库可以证明 Claude Code 存在缓存编辑的设计和客户端状态机，却不能单独证明私有协议的准确 wire format，也不能证明当前恢复版本能够真正执行 cached Microcompact。
压缩的核心是成本分层
Claude Code 的上下文管理把复杂性分布在三个位置：
- Microcompact 用确定性规则删除低价值数据；
- Session Memory 用后台模型调用提前保存任务状态；
- Full Compact 在其他机制不足时重写完整语义。
三者分别优化缓存成本、交互延迟和信息保真度。它们不是互斥的压缩算法，而是一条逐步升级的处理链。
这套设计真正有价值的地方，是把“压缩多少”改写成了三个更具体的问题：
哪些内容可以直接删除？
哪些信息已经被其他状态保存？
什么时候值得付出一次完整模型调用？好的 Agent Harness 不会等上下文耗尽后统一总结。它会先利用数据类型、缓存状态和已有记忆，把昂贵的语义压缩留到最后。