Codex 默认上下文从 272k 抬到 500k，第 7 天交出一项实改

第 7 天改了哪个数字

据 Tibo（Thibault Sottiaux）在 X 上的说明，这次调整只动了一个默认值：GPT-6.1 Sol 在 Codex 与 Work 里的默认上下文，从 272k token 抬到 500k token。几个事实点：

• 旧默认 272k，新默认 500k，增幅约 84%（官方说法是「约 80%」）。
• 官方称不额外收费，套餐价格不变。
• 用户仍可手动调整上下文长度，上限 1M；第三方模型列表给出的 GPT-6.1 Sol 总窗口约 105 万 token、单次输出上限 128k。
• 适用范围是 Codex 与 ChatGPT Work 两个入口，帖子没有提及 API 的默认行为有无变化。

与前一天的「周末重置」相比，这是 28 天承诺里第一类真正改动产品形态的项目——前者是把额度回满，这次是把单次会话能装下的东西变多。

为什么偏偏是 272k

272k 这个数字并不是随手定的。按多家第三方模型目录的记录，GPT-6.1 Sol 在 API 计费上恰好以 272k 输入为分界：此线以内按标准单价，超过之后整次请求改按更高的长上下文单价计。Codex 把默认值卡在这条线上，等于让绝大多数会话落在便宜的区间里，成本好控制。

这次越过分界线、直接放到 500k，说明 OpenAI 愿意在订阅产品里吞下这部分长上下文成本。这和 API 用户的处境不同——按 token 付费的开发者，跨过 272k 仍要面对更高单价，「不额外收费」只对订阅侧成立。

窗口变大，智能体少「失忆」

对编程智能体来说，上下文长度最直接的影响是压缩（compaction）发生的时机。Codex 在会话接近上限时会把早先的对话和工具输出压成摘要，再继续干活；压缩之后，模型对前面读过的文件、试过又放弃的方案，记忆就只剩摘要里那几句。

默认值从 272k 到 500k，意味着在大仓库里连续跑长任务时，第一次压缩来得更晚，跨多个模块的重构、长串测试日志的排查，被迫「重读一遍」的次数会少一些。这类收益在小项目里几乎感觉不到，在动辄几十万 token 日志与代码的任务里才明显。

大窗口的账单藏在哪里

「不额外收费」不等于没有代价。智能体每一轮调用都要把当前上下文完整送进模型，窗口装得越满，每一轮消耗的 token 越多。Codex 与 Work 按周计额度，如果用量按 token 折算，同样的任务在 500k 默认下可能更快触到周上限——官方帖子没有说明额度折算方式是否随之调整，这一点目前仍不清楚。

另一层是质量。长上下文模型普遍存在越往后越「看不清」的问题，业内常称为上下文腐烂；窗口变大能少压缩几次，但塞进去的旧信息未必都被有效利用。保留手动调节到 1M、也允许调小，某种程度上就是把这个取舍交还给用户。

所以第 7 天这项改进的成色，要过一阵子从两个方向看：长任务的完成率有没有肉眼可见的提升，以及用户抱怨额度掉得更快的声音会不会随之变多。前者成立，它就是 28 天里分量较重的一项；后者先出现，这次扩容就只是把压力从模型记忆挪到了周额度上。