探讨让Claude Code使用Codex专用Compact模式
速览
本文讨论了一种提升Claude Code能力的玩法，即尝试让其使用Codex专用的Compact模式。作者指出Codex在Compact后能保持上下文，而Claude Code在多次Compact后能力会严重下降。作者计划通过模仿Codex的实现或调用专用模型来开发插件，但尚未找到现成方案，故发帖求助或预告自行开发。
AI 深度解读
背景
在当前的 AI 编程辅助生态中，Claude Code 和 Codex 是两款备受关注的工具。用户普遍反馈，Codex 在长时间对话中表现出的上下文保持能力优于 Claude Code。这一差异主要源于两者在“压缩”（compact）机制上的不同实现。
Codex 在供应商为 OpenAI 时，使用的是专用的压缩模型（例如 gpt-5.5-openai-compact）、专用的提示词以及专用的策略。这种专用化设计使得 Codex 能够在压缩上下文后，依然保持较高的推理能力和代码生成质量。相比之下，Claude Code 在压缩上下文时，通常使用与原始模型相同的模型和策略。许多用户发现，Claude Code 在经过几轮压缩后，其能力会出现严重下降，导致在完成复杂任务（如代码检验）时，往往不得不重新开始新的对话。
尽管 Claude Code 拥有自动模式（automode）等吸引用户的特性，但其压缩机制的局限性成为了一个明显的痛点。
核心内容
作者基于对 Claude Code 压缩机制局限性的观察，提出了一种技术设想：让 Claude Code 使用类似于 Codex 的专用压缩机制，以解决其压缩后能力大幅下降的问题。
具体而言，作者认为问题的核心在于“压缩”环节。如果能让 Claude Code 采用 Codex 的压缩方式，即使用专用的压缩模型、提示词和策略，理论上可以保留上下文的同时维持模型性能。
为了实现这一目标，作者设想了以下技术路径：
- 通过 OpenAI 格式的接口，接入某家中转站（例如 hotaru 提供的服务）的压缩模型。
- 模仿 Codex 的压缩实现逻辑。
- 将这一功能封装为 Claude Code 的插件或类似组件。
然而，作者在现有的工具链中未能找到现成的解决方案，甚至连使用其他模型进行简单压缩的功能都未找到。这可能是因为作者疏忽未找到，也可能是因为市面上尚缺乏此类工具。因此，作者表示如果确实没有现成方案，将考虑自行开发这一功能，并表达了启动 Claude Code 和 Codex 进行开发的意愿。
关键要点
- 性能差异根源：Codex 在 OpenAI 供应商下使用专用压缩模型（如
gpt-5.5-openai-compact）、专用提示词和专用策略，从而在压缩后保持上下文质量；而 Claude Code 使用同款同模型的压缩策略，导致压缩后能力显著下降。 - 用户痛点：Claude Code 用户在进行代码检验等复杂任务时，因压缩后能力衰退，往往被迫中断当前对话并开启新对话，影响了工作流的连续性。
- 技术设想：通过 OpenAI 兼容接口接入第三方中转站（如 hotaru）的压缩模型，模仿 Codex 的压缩逻辑，为 Claude Code 开发专用压缩插件。
- 现状与行动：目前未找到现成的替代压缩方案，作者计划若无法找到现有工具，将自行开发该功能。
意义与影响
这一讨论揭示了当前 AI 编程助手在上下文管理上的技术分化。专用压缩模型和策略在保持长对话质量方面显示出明显优势，而通用压缩策略则面临性能衰减的挑战。
作者提出的“为 Claude Code 引入专用压缩机制”的设想，如果得以实现，将可能显著提升 Claude Code 在处理长上下文任务时的稳定性和效率，缩小其与 Codex 在用户体验上的差距。这也反映了开发者社区对于优化工具链、通过插件或中间件形式弥补原生功能不足的积极探索。若此类插件或方案成熟，可能会推动 Claude Code 等工具在复杂工程场景中的应用深度，促进不同 AI 编程助手之间在核心技术实现上的相互借鉴与竞争。