Codex 开放 100 万上下文，我为什么劝你先别开？

8 月 17 日，OpenAI Codex 团队的 Tibo 分享了一个很多人等了很久的配置：在 Codex 里，可以手动把 GPT-5.6 Sol 的上下文窗口开到 100 万 token。

配置只有三行：

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

重启 Codex，开启一个新会话，就能使用。

不到一小时，宝玉转发了这条消息，但给出了一个看起来有点反直觉的判断：暂时不想改，当前默认配置已经很顺滑；更短的上下文配合良好的压缩，效果可能更好，成本也更低。

我更赞同这个判断。

100 万上下文当然有价值，但它不是一个应该默认打开的“性能开关”。更准确地说，它是一条应急车道：平时没有必要走，碰到少数不能丢失原始信息的大任务时，才值得临时切进去。

这三行配置到底改了什么

GPT-5.6 Sol 的官方上下文上限是 105 万 token，最大输出为 12.8 万 token。

model_context_window = 1000000 告诉 Codex，这个会话最多可以使用约 100 万 token 的上下文。

model_auto_compact_token_limit = 900000 则把自动压缩推迟到 90 万 token 左右。也就是说，在触发压缩之前，Codex 可以保留更多原始代码、终端输出、工具返回结果和对话历史。

这里最容易产生一个误解：把上下文窗口扩大到 100 万，模型是不是就“升级”了？

不是。

模型没有因此变得更会推理，也没有自动获得更强的代码能力。你只是允许它在每次决策时看到更多历史信息。多出来的可能是关键证据，也可能是重复日志、过期计划、失败尝试和已经被推翻的假设。

窗口更大，解决的是“能不能装下”的问题，不负责解决“该装什么”和“模型能不能用好”的问题。

100 万上下文的第一个代价：贵

GPT-5.6 Sol 的 API 标准价格是每百万输入 token 5 美元、每百万输出 token 30 美元。但官方还有一条很关键的规则：输入超过 27.2 万 token 后，整次请求的输入按 2 倍计价，输出按 1.5 倍计价。

注意，是整次请求进入更高价格区间，而不是只对超过 27.2 万的部分加价。

如果你通过 Codex 订阅使用模型，不能把这套 API 单价直接换算成订阅额度。但这个价格断点已经把产品取舍写得很清楚：超长上下文不是常规工作区，而是一种成本更高的能力。

更关键的是，Agent 不是只请求一次模型。随着任务推进，代码、工具输出和历史轨迹会被反复带入后续决策。一个膨胀到几十万 token 的会话，每多走一步，都可能继续为前面的历史付费。

所以，100 万 token 不是一张只能刷一次的大卡，而是可能在长任务里被反复结算的上下文。

第二个代价：慢，而且未必更准

OpenAI 在压缩文档里明确写道，压缩的目的之一，就是在会话增长时平衡质量、成本和延迟。

这句话反过来也成立：把压缩阈值从默认值推迟到 90 万，相当于主动接受更大的请求和更长的处理链路。具体延迟会受缓存、网络、工具调用和服务实现影响，但“输入更多，处理负担更大”并不神秘。

质量问题更容易被忽略。

《Lost in the Middle》研究发现，长上下文模型对信息位置并不完全鲁棒，关键内容位于开头或结尾时表现较好，落在长上下文中部时可能明显变差。Chroma 在后续的 Context Rot 实验中也观察到，即使任务难度不变，只增加无关输入，模型表现也可能随着上下文变长而下降。

这些研究不能直接证明 GPT-5.6 Sol 在 100 万 token 下会出现同样幅度的退化，因为模型和实验条件不同。但它们足以推翻一个常见想当然：模型能接收 100 万 token，不代表它能同等可靠地利用其中每一个 token。

在编码场景里，这个问题会更复杂。长会话中不只有文档，还有失败的命令、旧版代码、重复报错、临时方案和互相冲突的要求。全部保留，看起来像“记忆更完整”，也可能只是让模型在更大的噪声堆里找答案。

压缩不等于失忆

很多人想打开 100 万上下文，是因为害怕自动压缩之后，Codex 忘掉前面做过什么。

这个担心并非没有道理。任何压缩都有信息损失的可能，尤其是罕见的错误细节、精确日志和早期约束。但把压缩理解成“删掉前面的聊天记录”也不准确。

按照 OpenAI 的定义，压缩会用更少的 token 带入后续任务所需的关键状态，让长会话继续运行。它做的事情更接近整理工作台：保留当前目标、重要决策和必要推理，清掉已经失去价值的过程噪声。

默认参数经过调优，原因也在这里。大多数编码任务需要的不是无限保留全部过程，而是在当前阶段保留足够、干净、可执行的信息。

如果压缩做得好，更短的活跃上下文反而可能让模型更稳定。宝玉所说的“现在已经很顺滑”，并不保守，而是在尊重一套已经被实际调过的系统默认值。

哪些任务值得临时打开 100 万

我会在下面几类任务中考虑打开：

大型单体仓库迁移，需要同时追踪多个子系统、接口和依赖关系。
长时间故障调查，早期的原始日志、命令输出和时间线证据必须随时回查。
跨大量文件的遗留系统重构，很多隐含约束无法提前准确提炼。
多文档审计、合规检查或引用核对，压缩后丢失原文细节的代价很高。
同一会话多次因为压缩而丢掉关键事实，并且任务又无法合理拆分。

共同点不是“任务很难”，而是原始信息必须长期共存，提前摘要会明显伤害结果。

普通 Bug 修复、单个 PR、常规功能开发、局部重构，没有必要为了“可能有用”就把窗口拉满。能通过缩小搜索范围、控制工具输出、阶段性总结或拆给子 Agent 解决的问题，也不该先用 100 万上下文硬装。

我会怎么开：按需，不改全局默认

Tibo 给出的单次启动命令最适合试用：

codex -m gpt-5.6-sol \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=900000

这样只影响当前启动，不会让之后每个小任务都默认进入超长上下文。

如果经常处理超大任务，可以单独创建 ~/.codex/long-context.config.toml：

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

需要时再启动：

codex --profile long-context

这个用法比直接修改 ~/.codex/config.toml 更稳妥。日常任务继续使用官方默认值，只有确定需要保留大量原始上下文时，才进入长上下文 profile。

判断是否值得开启，也不要只看“有没有报错”。最好用同一个真实任务比较四件事：任务是否一次完成、关键约束有没有丢、等待时间是否增加、token 或订阅额度消耗是否明显上升。

100 万上下文真正改变了什么

这次更新最有价值的地方，不是 Codex 从此应该一直背着 100 万 token 工作，而是用户终于可以自己决定何时推迟压缩。

默认值服务于大多数任务，100 万上下文服务于少数极端任务。两者并不冲突。

过去我们常把上下文窗口当成模型能力排行榜上的一个数字。进入 Agent 时代后，它更像一种系统资源：装得越多，成本越高，噪声越多，调度也越困难。优秀的 Agent 不应该记住一切，而应该知道什么必须保留，什么可以压缩，什么应该交给另一个独立上下文处理。

所以，我不会默认打开 100 万上下文。

但我会保留这个 profile。等到一个任务确实需要几十万 token 的原始证据同时在线时，再把它作为应急能力启用。

能开到 100 万，是能力。

知道什么时候不开，才是使用能力。