Codex 手动开百万 Token 上下文：官方给了开关，也说了默认值为什么小

这个需求积压了很久。GPT-5.6 Sol 在文档里标称的上下文窗口是 105 万 Token，而 Codex 客户端实际给到的有效额度长期只有二十多万——社区实测和 openai/codex 仓库里的 issue 都指向 272K 这个量级，更早在 GPT-5.5 时期还有人专门开 issue 抱怨 258K 的有效上限会把长时间运行的开发任务打断。标称值和手里能用的额度差了近四倍，这种落差每隔一段时间就会在 issue 区重新炸一次。

三行配置，一次重启

Tibo 给的做法很直接：在 ~/.codex/config.toml 的顶层（也就是任何 [section] 标题之前）写入模型名、model_context_window = 1000000 和 model_auto_compact_token_limit = 900000，保存后重启客户端并开一个新会话，老会话不会追认新设置。不想改全局的，也可以用命令行参数只让某一次 CLI 会话生效。

两个参数是配套的：前者放开窗口上限，后者决定 Codex 在攒到多少 Token 时开始自动压缩历史。只抬高前者、不同步后者，压缩阈值和窗口就会错位——这也是后面那堆麻烦的来源。

默认值为什么不是一百万

官方的说法是这个默认值"在性能与成本上被调到了最优"。这句话听着像客套，但拆开看确实是两笔实账。

• 钱：窗口越大，每一轮对话重新带进去的历史越多，计费的输入 Token 也水涨船高。同一个任务，开着百万窗口跑完可能贵出好几倍。
• 效果：塞进去的上下文不等于被用上的上下文。历史越长，模型在里面翻找关键那几行代码的准确率越容易掉，长上下文里的"中段遗忘"是公认的现象。
• 速度：每轮都要处理几十万 Token 的输入，首字延迟会明显变长，交互式改代码时体感最差。

换句话说，Codex 默认压低窗口，本质是替大多数用户做了一个"别把钱和时间花在低边际收益的历史上"的决定。争议点从来不是这个判断对不对，而是它没给需要例外的人留一个明面上的开关——现在算是补上了。

打开之后可能坏掉的东西

值得先看一眼再动手的是自动压缩这条安全网。在 openai/codex 仓库的多个 issue 里，有用户报告手动指定 model_context_window 之后出现过副作用：配置值不被尊重、界面显示的剩余上下文和实际不符，以及更麻烦的一类——某些版本里一旦覆盖服务端下发的窗口目录值，auto-compaction 就再也不触发了。

自动压缩失灵在长任务里不是小事。它意味着会话攒到上限时不会自动瘦身，而是直接撞墙报错，正在跑的一长串改动可能就断在那儿。这类反馈是社区提交的、也跟具体版本相关，不代表现在必然复现，但如果你打算把这套配置用在一整天的长会话上，值得先拿一个不重要的项目试一遍，确认压缩还会按 90 万这个阈值动起来。

谁真的需要开

按这套参数的实际收益划线：需要一次性把整个大仓库、成篇日志或者长迁移记录留在同一个会话里的人，开了确实少一大截来回喂料的功夫；而绝大多数改几个文件、跑几轮测试的日常活，开百万窗口只会换来更慢的响应和更高的账单。真要开，配套的习惯是每天新起会话、别让一个上下文无限膨胀下去。

另外，长会话本身对网络稳定性的要求比短对话高得多——一次几十万 Token 的请求在传输中断掉，重试的成本远不止时间。国内环境下用 Codex 频繁遇到会话中断、请求失败的，多数问题出在出口环境而不是配置，可以先用 GPT / Codex IP 检测确认落地 IP 和风控状态，再回头调这些参数，顺序反了容易白折腾。至于 CLI 本身怎么配得更稳，Codex 稳定使用那篇里有更细的部分。