一招教你在 Codex 中开启 1M 上下文，但最好别用了还是 。。。

今天早上，我看 tibo 发了一条推文。

他告诉大家，现在你可以使用 1M 上下文窗口了，并且给出了两种设置方式。

我相信不少小伙伴看到这个都爽飞了。1M 上下文拿到现在的大模型环境中，那还叫个事儿？但是放在 Codex 中，还是挺坎坷的。

不过我得泼点冷水，我自己研究了一圈，我发现这 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 上下文的话，你可以打开 ~/.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 的话，你会发现你的 1M 配置一直不生效。

就是你每次设置完成再重新使用 codex 进入之后再退出。

你会发现你刚刚加的 1M 上下文配置没了。

这不是 Codex 官方给你把配置删了。

这是 OpenCodex 的问题。

两种方式来解决：

第一种是关闭 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，就是避免用户在不知情的情况下产生高昂费用。

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

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