因为很多人第一眼看到这个消息，可能会理解成：

“Codex上下文从20多万升级到100万了，性能直接翻四倍。”

其实没那么简单。

更准确地说，GPT-5.6 Sol 这个模型本身一直就有约 1.05M Token 的上下文窗口。OpenAI目前官方模型页面写的是 1,050,000 Token，上限并不是这两天才突然增加的。

真正发生变化的是：

以前模型有这么大的“脑容量”，Codex这一层却不一定让你全部用上。

现在OpenAI开始把这层限制放开，让高级用户可以自己决定：

我要给Codex多大的上下文，以及什么时候开始自动压缩。

我觉得这件事情对于真正拿Codex做大型项目的人来说，比单纯模型Benchmark上涨几个点实际多了。

---

先把“1M上下文”到底是什么讲明白

很多人看到：

1M Context Window

第一反应是：

“是不是Codex一次能写100万Token代码？”

不是这个意思。

你可以把上下文窗口理解成Codex当前这次工作时的：

工作记忆。

这里面可能装着：

你的要求。

系统指令。

项目代码。

Codex读取过的文件。

前面的聊天。

工具返回结果。

运行日志。

修改记录。

测试结果。

它自己的推理和任务状态。

这些东西全部都要占上下文。

所以一个Coding Agent真正干长任务的时候，上下文消耗速度其实非常快。

普通聊天可能聊半天都用不了多少。

但是Codex进去一个大型Repository：

读几十个文件。

跑几次测试。

看几千行日志。

修改代码。

继续读取。

再测试。

上下文一下就上去了。

这时候1M真正解决的问题不是：

“能写更多代码。”

而是：

“干活干到一半，不容易忘记前面发生过什么。”

这才是重点。

---

Codex以前最让我难受的，其实就是Compact

做小项目感觉不到。

但是让Codex连续干比较长的任务，你很容易碰到：

Context automatically compacted

也就是上下文自动压缩。

为什么需要Compact？

因为上下文不可能无限增长。

快装满的时候，Codex需要把前面大量内容总结、压缩，然后腾出空间继续工作。

这个设计本身没有问题。

甚至是必须的。

问题在于：

压缩不是无损压缩。

这点特别重要。

假设最开始我告诉Codex：

重构支付模块，但是旧版Android客户端仍然在使用 /api/v1/payment，这个接口至少三个月不能删除。另外数据库里的 legacy_order_id 暂时也不能动。

Codex干了两个小时。

中间：

读代码。

改代码。

跑测试。

看日志。

不断加入新上下文。

然后Compact了几次。

后面你突然发现：

它把 /api/v1/payment 给删了。

你问：

我不是一开始告诉你不能删吗？

它可能已经只剩下一份压缩后的任务摘要了。

那条看起来不起眼、实际上非常重要的约束，在Compact过程中被弱化甚至丢失了。

这才是大型Agent任务最麻烦的地方。

---

所以前段时间社区对Codex上下文限制不满，我完全能理解

因为这里会出现一个特别别扭的情况：

GPT-5.6 Sol明明支持1.05M。

结果你在Codex里面实际干活，Agent可能远远没到这个数字就开始Compact。

社区此前确实有人专门提交Issue，希望Codex允许高级用户使用Sol完整的1.05M上下文，并且能够自行控制自动压缩阈值；当时提到的正是 model_context_window 和 model_auto_compact_token_limit。

甚至还有用户报告过，Codex实际有效窗口一度只有约25.8万Token，而模型本身宣传的是1.05M。

所以这次调整某种程度上就是：

模型原本有一间100平方米的仓库，但是Codex以前只允许你使用其中一部分。

现在终于开始允许：

“行，你确实有需求的话，自己把仓库打开。”

---

现在最有意思的是这两个配置

目前OpenAI Codex的源码配置里已经明确存在：

model_context_window

以及：

model_auto_compact_token_limit

前者控制模型可使用的上下文窗口大小。

后者控制：

上下文使用到多少Token以后触发自动Compact。

这两个参数看起来很技术。

实际上特别好理解。

假设只是举例：

model_context_window = 1050000

model_auto_compact_token_limit = 900000

大概就是告诉Codex：

这次允许使用约105万Token的上下文。

然后：

接近90万Token的时候，再考虑自动压缩。

而不是Codex自己按照一个更保守的默认阈值提前Compact。

对高级用户来说，这其实等于把：

“Codex什么时候开始失忆？”

这件事情的一部分控制权交还给用户。

---

这对小项目其实没什么意义

这点我觉得一定得说。

比如你让Codex：

做一个贪吃蛇。

改一个CSS。

修一个登录按钮。

写一个Python脚本。

解释一个报错。

上下文可能10万Token都用不到。

你给它：

25万。

50万。

100万。

最后结果可能完全一样。

就像：

你今天要搬10箱矿泉水。

给你一个20平方米仓库。

够了。

换成100平方米仓库。

水不会因此变好喝。

所以看到：

Codex支持1M上下文！

千万不要理解成：

以后所有Coding能力提升4倍。

完全不是这么回事。

---

真正受益的是“大项目 + 长任务”

比如这种任务：

阅读整个项目，把原来的用户权限系统迁移到新的RBAC架构，保持旧API兼容，修改数据库Migration，补测试，同时检查前端调用，最后跑完整测试。

Codex可能需要读取：

数据库Schema。

几十个后端文件。

前端代码。

API。

测试。

配置。

文档。

Git历史。

运行日志。

然后修改几十个文件。

这种任务的上下文才是真正吃紧。

如果只有20多万Token：

读着读着。

Compact。

继续读。

Compact。

继续改。

Compact。

等做到后面：

它可能已经不太记得最开始为什么这么改了。

而如果能够真正利用接近1M上下文：

前面读取的架构。

用户最初的要求。

已经做过的修改。

测试结果。

重要约束。

能够更长时间留在当前工作记忆里。

这种体验提升可能非常明显。

---

我甚至觉得这对Agent比对普通ChatGPT更重要

普通聊天里面：

1M上下文。

听起来很厉害。

但大多数人根本聊不到。

你一天和ChatGPT聊几百轮吗？

不会。

但是Coding Agent不一样。

Agent会疯狂产生上下文。

比如：

读取文件 → 5000 Token。

搜索代码 → 3000 Token。

运行测试 → 日志8000 Token。

读取另外几个文件 → 15000 Token。

修改。

重新运行。

又一堆日志。

然后继续搜索。

所以Agent时代，一个很容易被低估的问题就是：

AI不仅需要智商，还需要工作记忆。

一个程序员智商特别高。

但每工作半小时：

“刚才产品经理说什么来着？”

“这个接口为什么不能改？”

“刚才那个Bug在哪？”

“我前面为什么这么设计？”

你也受不了。

所以我现在越来越觉得评价Coding Agent不能只看：

SWE-bench多少分。

Terminal-Bench多少分。

模型推理能力多强。

还得看：

它连续工作几个小时以后，还记不记得自己在干什么。

---

但是，1M上下文也绝对不是越大越好

这个地方特别容易被营销带偏。

很多人的理解是：

25万 < 50万 < 100万。

所以：

无脑开100万最好。

我反而不建议。

为什么？

因为上下文越大，并不意味着模型对每一个Token的注意力都一样好。

你往上下文里塞：

几十万行无关日志。

整个 node_modules。

大量重复代码。

几十份没关系的文档。

以前已经不用的讨论。

反而可能增加噪音。

模型需要在100万Token里面寻找真正重要的10行东西。

这不一定比在20万Token里面找更容易。

这也是为什么OpenAI自己的工程文章专门谈到了避免“context bloat”，也就是避免上下文无意义膨胀。

所以：

大上下文解决的是容量问题，不是信息管理问题。

这两个一定要分开。

---

还有成本和速度问题

这一点API用户应该特别容易理解。

OpenAI目前GPT-5.6 Sol的API定价页面明确写着：

超过272K输入Token以后，整个请求的输入价格会按照2倍计算，输出价格也会提高到1.5倍。

也就是说：

1M不是免费的午餐。

上下文越大：

推理成本可能越高。

延迟可能增加。

缓存策略更重要。

无关内容越来越多。

Agent管理上下文也越来越复杂。

对于ChatGPT订阅里的Codex，用户未必直接按照每百万Token看到一张API账单，但后台计算成本不会凭空消失。

所以我完全能理解为什么OpenAI一开始比较保守。

如果所有Plus用户默认：

1.05M直接拉满。

然后一个简单的CSS问题也背着几十万Token历史跑。

那计算资源会浪费得非常夸张。

---

所以我觉得这次OpenAI真正做对的一点，不是“默认给所有人1M”

而是：

允许高级用户自己决定。

这个思路我非常赞同。

普通用户：

继续使用官方默认。

Codex自己Compact。

不用管Token。

体验简单。

高级用户：

我知道自己正在处理几十万行的大项目。

我知道这个任务要跑几个小时。

我知道Compact正在导致关键信息丢失。

那我自己提高：

model_context_window

以及：

model_auto_compact_token_limit

这其实才是比较合理的产品设计。

默认追求效率，高级用户追求上限。

而不是让所有人为少数人的极限需求买单。

---

但我也不建议大家现在马上把config.toml全部改成1M

尤其新手。

如果你现在使用Codex根本没有遇到：

频繁Compact。

长任务忘记要求。

大型Repository理解断层。

任务进行几个小时以后质量明显下降。

那就别改。

官方默认值通常是在：

成本。

速度。

稳定性。

上下文质量。

之间做过权衡的。

你为了看到：

Context Window：1.05M

觉得很爽。

实际上平时只用了8万。

没有任何意义。

---

我觉得真正会玩的用户，以后可能反而会准备几套配置

比如：

日常开发

中等上下文。

正常Compact。

追求：

快。

省。

响应及时。

大型重构

扩大Context Window。

提高Auto Compact阈值。

让Codex尽量保留：

架构。

任务历史。

约束。

已经做过的修改。

超长Agent任务

接近1M。

但同时严格控制：

哪些文件让它读取。

哪些日志需要保留。

哪些结果可以总结。

也就是说：

上下文管理以后可能会变成AI编程的一项基本功。

以前程序员研究：

CPU。

内存。

数据库。

缓存。

现在还要多研究一个：

AI的工作记忆怎么分配。

挺魔幻的。

---

还有一个我觉得更深层的影响：Skills可能又要重新评价

前一段时间大家讨论：

GPT-5.6越来越强以后，是不是很多Skills没必要了？

我觉得这次1M Context放开以后，这个问题反而更有意思。

因为未来Codex可能越来越像：

一个拥有超大工作台的程序员。

Skill负责：

告诉它公司的规则和工作方法。

1M Context负责：

让它在长任务里面持续记住当前项目发生了什么。

GPT-5.6 Sol负责：

推理和执行。

三者结合起来以后，Coding Agent真正的瓶颈开始从：

“会不会写代码？”

转向：

“能不能长期、稳定、不中断地完成一个复杂工程任务？”

我觉得这才是这次调整最值得关注的地方。

---

所以我怎么看这次Codex放开1M上下文？

我觉得这是一个：

普通用户几乎没感觉，重度用户可能非常舒服

的更新。

如果你平时就是：

改几个文件。

写小项目。

Vibe Coding。

做小工具。

真的没必要太关注1M。

但是如果你每天让Codex：

处理大型Repository。

跨几十个文件重构。

跑长时间Agent任务。

做复杂迁移。

分析大量测试日志。

维护多模块项目。

那么这次变化很重要。

因为以前GPT-5.6 Sol已经有一个很大的“脑容量”，只是Codex没有完全把它交给你。

现在开始允许高级用户真正利用它。

不过我觉得最重要的变化甚至不是：

258K → 1.05M。

而是OpenAI开始承认一个事情：

Coding Agent的上下文管理，不应该永远是一个完全隐藏在产品内部的黑盒。

不同项目需要的工作记忆完全不同。

一个5000行的小工具和一个500万行的企业项目，本来就不应该使用完全相同的上下文策略。

所以允许用户自己控制Context Window和Auto Compact阈值，我觉得方向是对的。

以后真正会使用Codex的人，可能不会再简单问：

“哪个模型最聪明？”

而会开始问：

“这个任务应该给模型多少推理能力、多少上下文，以及什么时候压缩？”

这其实和电脑发展很像。

最开始大家只关心：

CPU快不快。

后来才开始关心：

内存多大。

缓存怎么用。

任务怎么调度。

AI Agent现在可能也正在经历这个阶段。

GPT-5.6 Sol解决的是“大脑够不够聪明”。

1M Context解决的，则是这个聪明的大脑能不能在干几个小时活以后，还记得自己为什么出发。

我觉得后者对于Codex这种真正开始接管长时间编程任务的Agent来说，可能比很多人想象中更重要。

---

顺便补充一下事实层面：OpenAI官方API文档目前确认 GPT-5.6 Sol 的上下文窗口为 1,050,000 Token；Codex开源配置中也已经存在 model_context_window 与 model_auto_compact_token_limit 两项设置。社区此前确实长期反馈Codex有效上下文和过早Compact的问题，因此这次变化更准确地说是Codex层面对Sol既有大上下文能力的进一步开放，而不是GPT-5.6 Sol突然从25万升级成了100万。