先确认客户端版本，再谈开启 1M
Codex 最近放开了 GPT-5.6 Sol 的 1M token 上下文，而且这次支持直接用 ChatGPT 账号登录开启，不再像之前那样只对 API key 开放。消息一出，很多人第一反应是去改 config.toml。但实际操作中，这个开关最容易卡在客户端版本上。
有人用同一台 Mac 里的两份 Codex 做了对照测试：codex-cli 0.143.0 被服务端拒绝，提示 The 'gpt-5.6-sol' model requires a newer version of Codex；而 ChatGPT App 自带的 0.148.0-alpha.9 成功建立 Sol 会话，返回 CONFIG_OK。两次测试都用了 --ephemeral、--ignore-user-config 和只读沙箱，模型、上下文窗口、自动压缩阈值完全一致，排除了个人配置干扰。
值得注意的是，旧版本并没有在本地配置解析阶段报“未知字段”，而是请求真正到达服务端后才被拦下。这说明问题不在参数写法，而在客户端能力。遇到类似错误，最直接的动作就是升级 Codex，而不是反复调整账号权限或上下文数字。动手之前，先运行 codex --version 看看当前版本。
这里有个容易被忽略的细节：--strict-config 让两版客户端都走过了字段解析，旧版的失败发生在服务端检查模型之后。也就是说，客户端版本是硬门槛，配置只是后续步骤。
临时会话验证：参数怎么设，为什么留余量
对于第一次验证，Tibo 给出的临时命令很适合。它只影响当前 CLI 会话，退出后不会把 1M 默认值写进配置：
codex -m gpt-5.6-sol \
-c model_context_window=1000000 \
-c model_auto_compact_token_limit=900000
model_context_window 把可用上下文预算设为 100 万 token，model_auto_compact_token_limit 让 Codex 在约 90 万 token 时开始压缩，留出余量。这两个参数必须放在顶层；如果写进 ~/.codex/config.toml，要放在所有 [section] 标头之前。保存后还要重启客户端并新建会话，旧会话不会自动扩成 1M。
GPT-5.6 Sol 的文档窗口是 1,050,000 token，但 Codex 配置停在 1,000,000，并在 900,000 开始压缩。这几组数字是有意为之。系统指令、工具定义、工具返回和下一次模型输出都要占用窗口，直接把预算和压缩阈值顶到模型上限，长回合反而容易没有余量。
另外，1M 并没有取消自动压缩，只是把压缩点往后推。对话继续增长，到了约 90 万 token 仍会整理旧历史。原始上下文保留得更久，但线程不会因此永远不压缩。用短提示词测试只能验证版本和权限，想判断 1M 的实际质量，还是需要跑一次包含大段代码、工具输出或对话历史的真实长任务。
建议的做法是：先开一个临时会话，完成一次确实会变长的任务，记录三件事——启动阶段有没有版本或权限错误，长任务里自动压缩何时出现，任务结束前后的剩余额度差了多少。第一项决定能不能用，后两项才回答值不值得用。没有额度读数时，只记录压缩和结果完整性，别自己编一个节省比例。
1M 的代价：超出默认窗口的部分按 2 倍计费
Tibo 在说明里提醒，Codex 的默认上下文已经按性能和成本仔细调过。Vaibhav 补充了更具体的边界：超过默认上下文窗口的 token，会按 2 倍计入使用限额。这句话要按原话理解，它说的是“超出默认窗口的那部分 token”加倍，不是整条会话价格翻倍，更不能据此直接推算账单。
对 ChatGPT 套餐用户来说，最直接的感受是同一段时间里的可用额度可能掉得更快。打开 1M 之前看一眼剩余额度，做完同类任务再看一次，比猜测更可靠。如果任务根本没有逼近默认窗口，或者额度消耗明显上升，那就没必要长期开着。
1M 适合那些连续历史很难拆开的任务。比如跨大量文件的迁移，前面定下的兼容规则会反复影响后面的修改；或者故障排查已经积累了很长的工具输出，过早压缩会丢掉关键约束。日常修一个 PR、查一段日志、改两个文件，默认窗口通常够用。能分给独立 Agent 的支线，也不必全塞进同一个 1M 会话。
上下文上限变大，不会自动提高推理质量。模型只会获得更多可读材料，噪声也会跟着进去。这就像给一个人更多资料，不代表他就能更专注；关键还是任务本身是否需要那么长的记忆。
逐步打开，随时可以退回
稳妥的做法是分三步走：先用 codex --version 过版本门；随后用上面的 -c 参数开一次临时会话，确认模型能启动、工具能正常调用；最后挑一个确实会变长的任务，看压缩次数、结果完整性和额度消耗，再决定是否写进全局配置。每次测试只改这两个上下文参数，模型和任务尽量保持相同，结果才有比较价值。
如果消耗明显上升，或者任务根本没有逼近默认窗口，退出临时会话就结束。已经写进配置文件的，把 model_context_window 和 model_auto_compact_token_limit 两行删掉，重启客户端并开新会话，即可回到模型默认值。
1M 值得保留给那些“必须记住很多东西”的工作。普通任务继续用默认设置，省下来的额度更实在。先升级，再测试，最后决定要不要长期打开——这个顺序能省掉不少折腾。