OpenAI 将 Codex 模型上下文大小从 372k 降至 272k
OpenAI 已将其 Codex 编码代理的上下文窗口从 372k tokens 暂时降至 272k，这引发了关于大型、长时间运行的软件项目中成本节省与能力之间取舍的讨论。许多用户表示，自动且不透明地“压缩”对话历史和代码上下文，会扰乱复杂工作流，尤其是在大型代码库、多仓库或大型规则文件场景中；而另一些人则认为，良好的规划、子代理以及外部 Markdown“记忆”基本可以抵消较小窗口的影响，并避免在极长上下文下的质量损失。与 Anthropic 的百万 token 模型和 DeepSeek 风格缓存的比较凸显了一个更广泛的张力：前沿工具究竟应优先追求巨大的原始上下文，还是更智能、更可控的上下文管理与 harness 设计。
上下文大小缩减与原因
- Codex 的上下文窗口从 372k tokens 降到了 272k；提交记录和推文表明，这似乎是临时的成本/使用控制措施，而不是能力变化。
- 有人指出，这样可以避免触发更高价的长上下文档位，而这些档位此前会让用户意外产生费用。
- 一条评论提到，底层模型最多可处理 1M 上下文，但 Codex 的客户端限制更低，以将总量（输入 + 最大输出）控制在计费阈值之下。
理解成本/轨迹图
- 一些读者觉得帖子里的成本图很难懂；另一些人解释说，它表示累计成本会随着轮次大致呈二次增长，直到发生压缩；较小的上下文（例如 200k）会比更大的上下文（300k）稳定地更便宜。
- 对于曲线究竟反映的是二次注意力成本，还是仅仅是线性的累计成本，大家存在分歧。
对真实工作负载的影响
- 相当多的人表示，272k 对大型代码库、逆向工程，或者包含大量计划、审查和长时间运行代理的工作流来说太小了；他们通常会接近上限，并频繁触发压缩。
- 也有人认为，大多数问题都可以而且应该拆分成低于约 200–300k 的块；更小的上下文会带来更好的质量和更低的成本。
压缩：质量、控制与变通方案
- 许多人抱怨 Codex 的自动压缩：
- 会在剩余上下文约 10–20% 时触发，而且没有办法禁用或回滚。
- 有时会导致模型“忘记”最近的任务或之前读过的代码，迫使重新扫描并消耗 tokens。
- 也有人表示，自早期版本以来，Codex 的压缩已经显著改进，对他们来说运行良好。
- 常见的缓解策略包括：
- 使用 Markdown 的“plan”/“rules”/“report”文件作为持久记忆，而不是依赖聊天历史。
- 大量使用子代理、分层规划，以及能保存并重新注入先前上下文的外部工具。
- 在 200–300k 左右手动重启会话或清空上下文。
与其他模型和 Harness 的比较
- 一些用户表示，他们会继续使用或转向拥有约 1M 上下文的模型（例如 Anthropic、DeepSeek 以及其他产品），尽管在几十万 tokens 之后也会出现类似的退化。
- 另一些人认为，长上下文营销夸大了真实可用上下文；他们在许多模型上都看到从 120–300k 左右开始出现“迟钝区”。
- 还有人更喜欢可调压缩、历史树以及更强用户控制的替代开源或第三方 harness。
安全性与 Harness 设计
- 同一提交在执行破坏性操作前增加了更严格的系统提示指导（例如，不要递归删除 home 或 root 目录），以回应真实发生过的误删案例。
- 有人支持进一步隔离（容器、受保护的
rm包装器），也有人怀疑是否应该让代理执行破坏性命令。