Tibo 公布三行配置，GPT-5.6 Sol 在 Codex 可开 100 万 token 上下文

北京时间 8 月 17 日凌晨 4 点 12 分，OpenAI 员工 Tibo（X 账号，简介标注「Codex & ChatGPT @OpenAI」）发帖，公布在 Codex 中为 GPT-5.6 Sol 开启 100 万 token 上下文窗口的配置方法：打开 ~/.codex/config.toml，在顶层（任何 [section] 标题之前）写入三行设置，保存后重启客户端、新开会话。他同时确认，GPT-5.6 Sol「有文档记载的 1,050,000 token 窗口」。

四个多小时后他再发一帖（）：「GPT-5.6 Sol 1M in Codex。以前这只能通过 API Key 使用，我们刚刚拨动了开关，现在通过 ChatGPT 账号的使用也生效了。」截至发稿，配置指南帖获得约 843 次转发、1.07 万点赞、143 万浏览。

配图截自中文博主，均为中文翻译视图。

三行配置各管一件事

Tibo 逐行解释了三个参数的作用：model = "gpt-5.6-sol" 选择模型；model_context_window = 1000000 告诉 Codex 使用 100 万 token 的上下文预算；model_auto_compact_token_limit = 900000 让自动历史压缩（compaction）在大约 90 万 token 时启动，「留出一些余量」。不想改默认配置的人，可以用下面的命令为单次 CLI 会话临时启用：

更大窗口的收益很具体：Tibo 写道，更大的上下文让 Codex「在总结旧材料之前，保留更多代码、工具输出和对话历史」。前提是模型本身支持。登记的是 1,050,000 token 上下文窗口、128,000 token 最大输出，标准费率为每 100 万 token 输入 5 美元、输出 30 美元。

105 万写在文档里，27.2 万才是默认值

这份指南引来这么大反应，背景是一个月前的一次下调。7 月 13 日，用户在报告：Codex 把 gpt-5.6-sol 的目录窗口从 372,000 砍到 272,000，套用 95% 的折算系数后，有效窗口从 353,400 掉到 258,400，而官方模型页仍标着 1,050,000。

报告者把这次下调称为「严重回退」，并在期望行为清单里写明：应允许用户「在接受相应用量或价格影响的前提下」，选择进入已公布的长上下文档位。这正是 Tibo 现在公布配置所回应的诉求。

补上了仓库侧的证据：7 月 18 日，Codex 仓库合并 PR #33972，把 GPT-5.6 Sol、Terra、Luna 三个模型的报告窗口修正为 272,000。该报道的判断是：272K 不是技术天花板，而是一道计费边界。

272K 之后整单按 2 倍计价

计费规则写在上：「输入超过 272K token 的请求，按整单 2 倍输入价、1.5 倍输出价计费。」也就是说，会话一旦跨过 27.2 万 token，整个请求都进入溢价档，而不是只对超出部分加价。AI Weekly 认为，Codex 把默认目录对齐到这条价格线，是为了让默认会话不会在用户不知情时跨进溢价区间。

这解释了 Tibo 两次强调的警告：配置帖说默认值「在性能和成本上已经调到最优」，结尾还留了一句「Have fun, but also know that we tuned the default carefully!」；开关帖则写「当前的上下文长度作为默认值是有原因的，我们把它调到了近乎完美」。

社区的提醒更直白。创业者 Udit Goenka（，约 6 万粉丝）在引用帖里写：「别用它，你的每周额度几个小时就会耗尽。」

中文博主 AYi（）则把场景分了两类：一次性吞下整个 monorepo、长周期调试、逆向工程这类需要保留大量工具输出和多轮修改历史的任务，值得开 100 万；日常写小功能，默认配置「反而更快更省更稳」。

开满 100 万，实际能填多少？

配置生效后的实测出现在引用帖里。开发者 Jare（）报告：把 model_context_window 设为 1,000,000 后，Codex 只显示约 828K。他给出的算式是「模型目录把窗口封顶在 872K，再套用 95% 的有效上下文系数，得到 828.4K」，所以 900K 的自动压缩阈值根本够不到。他在帖末问：「这是预期行为吗？」

872K 这个封顶值与 Codex 保留输出预算的机制对得上。指出，目录窗口要把 128,000 token 留给输出，输入预算再按 95% 折算：1,000,000 − 128,000 = 872,000，乘以 95% 得 828,400，正好落在 Jare 报告的数字上。

另一个方向的实测口径来自 Hermes Agent 联合创始人兼首席工程师（Nous Research）：他称自己在 Hermes Agent 里探测到「371K 才是实际绝对上限」。两个实测口径都与文档里的 105 万相去甚远。

评论区要的是一个下拉菜单

评论区里获得高赞的声音，是嫌它不够像产品功能。开发者 SamG（）给 Codex UI 团队提了一个「Codex Work Mode」下拉菜单方案：Balanced（约 300K，较早压缩）、Large Codebase（约 600K，保留更多仓库和工具历史）、Long-Running Investigation（约 1M，晚压缩，适合逆向工程、迁移和调试），这条回复获得 297 个赞。

开发者 Tatenda Zhou（）的同类评论拿到 102 个赞：「这对普通用户来说太复杂了，你们不能像 Claude 那样在 GUI 和 CLI 里加个选项吗？」

配置里的 1,000,000 与实测可填的 828,400 之间仍差着 17 万多 token。Jare 已经把这个问题问了出来：「这是预期行为吗？」