Codex 开启 1M 上下文教程：GPT-5.6 Sol 配置与 OpenCodex 冲突避坑

今天早上，Tibo 发了一条推文：现在 Codex 里可以给 GPT-5.6 Sol 启用 1M 上下文窗口了，并且给出了两种设置方式。

不少小伙伴看到这个估计都爽飞了。1M 上下文放到现在的大模型环境里，那还叫个事儿？但在 Codex 中，这件事还真没那么顺利。

不过我得泼点冷水。我自己研究了一圈，发现这 1M 其实就是一个深坑。

一次性设置 1M 上下文

现在可以直接在 Codex CLI 中用下面这行命令设置 1M 上下文。所谓“一次性”，指的是当前 session 退出之后，1M 上下文就结束了。

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

可以看下，当前窗口下确实一次性设置了 1M 上下文窗口。

没有设置的话是这样的，截图里没有 context windows 相关选项。

长期开启 1M 上下文

如果你想要长期开 1M 上下文，可以打开 ~/.codex/config.toml，然后添加或更新这些配置：

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

这里两项配置很好理解：model_context_window 告诉 Codex 当前窗口按 1M 来算，model_auto_compact_token_limit 则把自动压缩触发线放在 900k，达到阈值直接进行上下文压缩。

其实这个设置完成后就直接是 1M 上下文了。

坑点：OpenCodex 会重写你的配置

但我这里遇到一个坑。如果你像我一样之前安装了 OpenCodex，你会发现你的 1M 配置一直不生效。

每次设置完成后再重新执行 codex，进入、退出之后，你刚刚加的 1M 上下文配置就没了。

这不是 Codex 官方把你的配置删了，而是 OpenCodex 的问题。

原因不是官方 Codex 自动清理配置，而是你安装的 OpenCodex 启动 shim 在重写它。

你的 Codex 启动流程是：

codex
  → 先执行 ocz ensure
  → 同步 OpenCodex 模型目录
  → 重写 ~/.codex/config.toml
  → 再启动官方 Codex

OpenCodex 明确删除根级别的这两个配置：

model_context_window = 1000000
model_auto_compact_token_limit = 900000

相关逻辑位于：

• codex.sh：启动前执行 opencodex ensure
• inject.ts：说明这些全局覆盖会优先于模型目录
• inject.ts：stripRootContextWindowOverrides()
• inject.ts：每次注入时调用清理

OpenCodex 这样做，是因为这两个配置是全局覆盖，会导致所有模型都被误报成 1M，而不是只影响 gpt-5.6-sol。

两种不生效的解决尝试

第一种是关闭 OpenCodex 对 Codex 的管理，用这两条命令：

ocx codex-shim uninstall
ocx stop

第二种是在 OpenCodex 中添加 OpenAI API Key provider：

model = "openai-apikey/gpt-5.6-sol"

通过 ocx gui 的方式来配置，我在 ocx 中设置了一下 1M 上下文。

但这种方式也不行。它改的只是 Context Cap，也就是上下文上限，只能降低模型原本的窗口，不能提高实际窗口大小。

所以我目前只改了上下文状态。目前的状态是：

而且 OpenCodex 默认上下文窗口是直接在源码中硬编码的。要改默认上下文窗口配置，就需要直接改源码。

下面这些源码位置都直接硬编码了：

// metadata.ts
export const NATIVE_GPT56_CONTEXT_WINDOW = 372_000;

// registry.ts
const OPENAI_API_GPT56_CONTEXT_WINDOW = 1_050_000;
const OPENAI_CODEX_GPT56_CONTEXT_WINDOW = 372_000;

// parsing.ts 这行不应该，改上面两个位置就可以了。
entry.context_window = override.contextWindow;
entry.auto_compact_token_limit = Math.floor(override.contextWindow * 0.9);

也就是说，ocx 不支持修改 1M。想用的话，只能停掉代理。

ocx 的 webui 中也提供了停止代理的选项。

停掉代理还不够，还要关自动启动

那是不是停掉代理之后就行了呢？

其实也不行。

因为你只停掉了 ocx 的代理进程，没有关闭 Codex 自动启动和配置注入。

问题出在 codex shim 上。我的实际执行配置加载流程是：

这条链路里最关键的是 codex shim。

ocx stop 只停掉了眼前这个代理进程。只要自动启动还开着，下一次执行 codex，shim 就会再跑一遍 ocx ensure，然后把代理和配置重新拉起来。

所以你只是停掉 ocx 的代理还不够，还得关闭 ocx 的自托管。

两条命令关闭自托管：

ocx system settings --auto-start off
ocx stop

关掉之后重新使用 /status 命令查一下。

果然有 1M 了。

但你以为这就完了吗？

并不是。

假如你本地改变了 1M 上下文窗口长度，服务端其实也有 1M 限制。也就是说，你本地用着 1M，服务端仍然会给你当作 272k 来看待，所以会忽略很多上下文，导致 token 效率极低。

之前通过订阅方式使用，从产品角度给你定死了 1M。之前这种方式只适合 api-key，但刚刚 Tibo 已经发话了：现在订阅用户也能享受 1M 上下文窗口了。

这里补一句时间线：上面我提到服务端仍按 272k 处理，说的是这次开放之前的状态。现在订阅用户也能请求 1M，变化的是可用上限，但 272k 之后的额外计费并没有一起消失。

不过，如果你要使用 1M 上下文，超出 272k 的部分是需要单独计费的。Tibo 人家没提这话，为什么不说，大家自己心里有数。

之前关于上下文窗口 272k 这个事，在 OpenAI 社区里闹得沸沸扬扬。

作为“计费护栏”：OpenAI 的计费规则中，一旦输入超过 272K Token，整个请求的输入价格就会翻倍，即 2 倍；输出价格变为 1.5 倍。Codex 将上限设为 272K，就是为了避免用户在不知情的情况下产生高昂费用。

所以中转的各位老铁们，这里就要提醒你们一下了：如果此时这个单独计费开关没有打开，你可能分分钟被搞破产。

各位使用中转的老铁们，假如你的中转站老板没开这个开关，那你得手下留情了。

如果你想进一步了解 Codex、OpenAI 以及上下文窗口相关的配置细节，可以到云栈社区翻一翻技术文档和避坑指南。