Codex's 1M Context Window Is a Billing Trap, Not a Free Upgrade

This morning, I saw a tweet from tibo.

He told everyone that you can now use a 1M context window, and gave two ways to set it up.

I believe many of you are thrilled to see this. A 1M context in today's large model environment, is that even a big deal? But in Codex, it's been a bumpy road.

However, I have to pour some cold water on this. After looking into it myself, I found that this 1M is actually a deep pit.

Let's first talk about the one-time setup method.

Now, you can directly set a 1M context in Codex CLI with the following command. "One-time" means that once you exit this session, the 1M context is gone.

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

As you can see, a 1M context window is indeed set for the current session.

Without the setting, it looks like this. You can see from the screenshot that there is no context windows option.

If you want to enable the 1M context permanently, you can open ~/.codex/config.toml and add or update these configurations.

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

The two configs here are easy to understand. model_context_window tells Codex to treat the current window as 1M, and model_auto_compact_token_limit sets the auto-compaction trigger line at 900k, triggering context compression directly when the threshold is reached.

Actually, once this is set, you have a 1M context.

But I ran into a pitfall here. If you, like me, previously installed OpenCodex, you will find that your 1M config never takes effect.

Every time you finish setting it up, re-enter with codex, and then exit.

You'll find the 1M context config you just added is gone.

This isn't Codex officially deleting your config.

This is an OpenCodex problem.

Two ways to solve it:

The first is to disable OpenCodex's management of Codex, using these two commands.

ocx codex-shim uninstall
ocx stop

The second is to add an OpenAI API Key provider in OpenCodex.

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

Configure it via the ocx gui. I set up the 1M context in ocx.

But this method doesn't work either. What this changes is only the Context Cap (context upper limit). It can only lower the model's original window, not increase the actual window size.

So I've only changed the context status for now. My current status is:

Moreover, OpenCodex's default context window is hardcoded directly in the source code.

So if you want to change the default context window config, you need to modify the source code directly......

It's hardcoded in the following source locations:

// 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 This line shouldn't be needed, just change the two positions above.
entry.context_window = override.contextWindow;
entry.auto_compact_token_limit = Math.floor(override.contextWindow * 0.9);

In other words, ocx does not support modifying to 1M. So if you want to use it, you can only stop the proxy.

ocx's webui also provides an option to stop the proxy.

So, is it enough to just stop the proxy?

Actually, no.

Because you've only stopped ocx's proxy process, you haven't disabled Codex's auto-start and config injection.

The problem lies with the codex shim.

My actual execution config loading flow is:

The most critical part of this chain is the codex shim.

ocx stop only stops the current proxy process. As long as auto-start is still on, the next time you execute codex, the shim will run ocx ensure again, pulling the proxy and config back up.

So just stopping ocx's proxy isn't enough; you also need to disable ocx's self-hosting.

Two commands to disable self-hosting:

ocx system settings --auto-start off
ocx stop

After disabling, re-check using the /status command.

Sure enough, the 1M is there.

But do you think this is the end of it??

It's not.

And even if you change the 1M context window length locally, the server side also has a 1M limit. This means that even if you use 1M locally, the server side will still treat it as 272k, thus ignoring a lot of context, leading to extremely low token efficiency.

Previously, when using it via subscription, from a product perspective, it was capped at 1M.

This method was only suitable for api-keys before, but tibo just spoke up, and now subscribers can also enjoy the 1M context window.

A note on the timeline here. When I mentioned above that the server side still treats it as 272k, I was referring to the state before this opening. Now that subscribers can also request 1M, what has changed is the available upper limit; the extra billing beyond 272k has not disappeared along with it.

However, if you want to use the 1M context, the portion exceeding 272k requires separate billing. tibo didn't mention this. Why didn't he say it? Everyone can figure that out for themselves.

Regarding the 272k context window, this previously caused a huge uproar in the OpenAI community.

As a "billing guardrail": In OpenAI's billing rules, once the input exceeds 272K Tokens, the input price for the entire request doubles (2x), and the output price becomes 1.5x. Codex set the upper limit to 272K to prevent users from incurring high costs unknowingly.

So, for those of you running API proxies, a word of caution here: if you haven't turned on this separate billing switch, you might go bankrupt in minutes.

So, to all you proxy users, if your proxy station owner hasn't turned on this switch, you'd better show some restraint...