OpenAI 悄悄缩减 Codex 上下文窗口
OpenAI reduces Codex Model Context Size from 372k to 272k
OpenAI 的 Codex 项目刚刚完成了一次关键更新，将模型上下文大小从 372k 直接砍到了 272k。这次变动通过 Pull Request #33972 合并到了 0.144 版本中，主要涉及捆绑模型元数据的刷新。虽然官方没有大张旗鼓地解释原因，但这种对核心参数的调整往往意味着底层架构的优化或策略转向。对于依赖长上下文能力的开发者来说，这绝对是一个值得关注的信号，或许 OpenAI 正在重新平衡性能与成本，或者为下一代模型架构铺路。
OpenAI 将 Codex 模型的上下文大小从 372k 缩减到了 272k。
HN 评论区
164- tekacs
我知道很多人喜欢说压缩功能让这个问题变得无关紧要，但很不幸，对于我做的绝大多数事情来说，压缩过程中丢失的细节程度实在太多了。
也许如果你的计划没那么复杂，或者你不需要进行那种充满细枝末节的讨论，那可能还行？
缺乏长上下文是我至今仍在使用 Anthropic 的主要原因。
最糟糕的情况是，你需要它记住好几篇论文，或者需要全分辨率处理的大型复杂材料，结果上下文窗口永远卡在 16%。你大概聊了五分钟，它就开始压缩，然后你得等着它重新读取，再次回到 16%……如此循环往复。
372 虽然不完美，但它好太多了，简直是救星。它把原本 12% 到 20% 的利用率提升到了 40% 左右。
- dannyw
这事儿发生的时候就在 Twitter 上被讨论过，Tibo 在这里给了一些解释：https://x.com/thsottiaux/status/2076543065045795309
- onetrickwolf
我不确定他们这么做是不是因为这个原因，但我认为无论如何，超过这个上下文大小通常都是个错误。
人们似乎没意识到，在更大的上下文中模型会变得多么“笨”，而且 token 成本会高多少。我从来不让 Claude 达到 300k，通常我也不压缩，而是把任务拆分成能塞进 300k 的块。我尽量保持文档干净精简，代码库模块化。
这确实有点烦人，有时候大上下文对一次性任务很有用，但我认为如果你经常超过 300k，那你肯定损失惨重，而且代码库设计得可能也不太好。
- damsta
我不喜欢他们的上下文压缩功能，我觉得现在 1M token 的上下文应该是底线了。每天我都能看到 GPT 5.5 和 5.6 在每次压缩后挣扎一会儿才能恢复全速，有时候还会过度关注那些被压缩进上下文里的旧引导信息。
- davidkuennen
我从来没觉得 Codex 的上下文大小是个问题。我不清楚他们的压缩机制是怎么工作的，但它就是能一直跑下去，仿佛根本没有上下文限制一样。至少在我的经验里是这样的。
- throwatdem12311
我日常主要用 Opus，而且经常用 /clear 清空。1M 上下文听起来很棒，但一旦你用到 50% 左右，效果就会迅速下降。我通常是在上下文用到 30% 到 40% 时就 /clear 一次，这样模型的表现会好得多。根据我的经验，压缩功能帮不上什么忙，从头开始、让模型重新加载上下文效果要好得多。我有多个技能，还有一堆按功能分类的 markdown 文档，用来辅助首次加载，告诉模型去哪里找任务相关的信息。效果很棒。
- Fr4nZ82
大上下文窗口让大家都懒得去决定什么内容才真正值得放进去……压缩功能让情况更糟，它是对所有内容一次性应用有损压缩，所以你真正需要的细节很可能就丢了。我一直认为每轮对话都重新传输完整聊天记录是个根本性问题……根据我对对话代理的经验，我每轮都会清空上下文，并用我自己编写的记忆/上下文插件重新注入所有相关信息，所以小上下文不再是问题，因为模型读取的是几 k 精心策划的状态，而不是 200k 的滚动记录。编程代理更难，我还没搞定那部分，但在我看来，解决上下文问题的真正方向应该是这样：制定一个策略，保留完成当前任务或执行下一个任务所需的内容，丢弃其余部分。这可以通过一个专门为此设计的独立 LLM 来实现。
- bel8
这对我的工作量来说太小了。
我尽量把它控制在 200k 以下，但我的 DeepSeek 和 MiMo 会话有时在我试图挤进最后一次迭代时，会膨胀到 350k token，然后我就压缩。
OpenAI 不能复制 DeepSeek 的 K/V 缓存技术（来自已发表的论文）让它变得超级便宜吗？