Is GPT-5.6's Context 1.05M, 500K, or 400K?

GPT-5.6’s context window is not as clear-cut as it seems. The official API page says 1.05M, but in daily Codex use, it is nearly impossible to push a session to that number. A recent adjustment further complicated the picture: the window in Codex, originally about 500K, became 400K. Looking at different version configurations, you may also see a bundled input budget sometimes at 372K, sometimes 272K, alongside a 128K maximum output limit. Adding input and output together yields two product totals — 500K and 400K. Some users online even report that the runtime shows only about 258K. What exactly are 1.05M, 500K, 400K, 372K, 272K, 258K, and 128K? Let’s take them apart one by one.

The Short Answer: API Remains 1.05M, Codex Goes Back From ~500K to ~400K

When dealing with the same model, developers encounter seemingly contradictory limits across different scenarios. To make sense of these numbers, you need to separate the model’s underlying specification from the product’s default packaging quota.

The underlying API model specification is clear and stable. According to the GPT-5.6 Sol API page and the GPT-5.5 API page, both models have a context window upper bound of 1,050,000 tokens over the API channel, with a maximum output limit of 128K. This is the model’s total capacity ceiling, not merely an input quota.

Once the model is routed into the Codex client through a ChatGPT subscription, the applicable product quota conventions change. This split already existed in the GPT-5.5 era: OpenAI announced in the article introducing GPT-5.5 that GPT-5.5 inside Codex has 400K of context space. Its default configuration splits this space into a 272K input budget and a 128K maximum output limit, which arithmetically add up to exactly 400K.

In the GPT-5.6 era, this product quota went through a swing. In the earlier Codex v0.144.5 release, the bundled input budget was set at 372K. Together with the 128K output limit, this arithmetically yielded about 500K of total space, though this was not an independently announced product commitment. Subsequently, the Codex CLI v0.144.6 release notes corrected the GPT-5.6 limit to 272K. According to PR #34009 in the changelog, this change involves only bundled model metadata (locally packaged prompt templates and metadata such as context_window and max_context_window). That PR only proves a change in local metadata; it cannot be used to infer the underlying intent of the official adjustment, nor can it prove that all cloud-side service behavior changed as a result. Furthermore, while Codex relies on these bundled configurations to plan session budgets, the configuration delivered by the cloud server may likewise override the local defaults.

Updating the client does not mean this limit exists only on the client side. In fact, the client needs accurate metadata to initiate compaction in time before sending the session to the cloud, preventing the backend from rejecting requests for exceeding the quota. At the same time, the Codex backend can dynamically push an updated model catalog to override the locally bundled defaults. According to a runtime report on GitHub (issue #32806), at least one runtime report shows that users of older client version 0.144.3 — released before v0.144.6 — had already received the 272K limit delivered from the cloud. Therefore, neither pinning version v0.144.5 nor manually modifying local values can reliably preserve the original 372K behavior. These changes, while altering when the client locally plans compaction, cannot compel the cloud backend to accept requests exceeding the quota.

In actual operation, some developers will also see a fourth number. According to the aforementioned runtime report, under certain runtime environments model_context_window may report an effective quota of about 258,400 tokens. This value is merely the 95% effective window performance observed by a single developer in a specific session; it is not a fixed compaction trigger threshold, and actual compaction triggering still depends on the specific routing tied to the account.

The Arithmetic Behind 500K and 400K: Default Input Budget Corrected From 372K to 272K

Both composite quotas above are derived by adding the default input budget and the maximum output limit.

In version v0.144.5, Codex assigned GPT-5.6 a 372K input budget. Together with the 128K output limit, this arithmetically yielded a product total of about 500K, causing the local client to use this as the planning target for long sessions. In the latest v0.144.6, Codex corrected the input budget back to 272K, and under the same 128K maximum output limit, the product total dropped back to about 400K accordingly.

This means GPT-5.6 in Codex has returned to the same quota standard as GPT-5.5. The default input budget available to developers is once again unified at 272K, while the underlying API model specification was not lowered.

How the 100K Budget Reduction Affects Billing and Long Tasks

The drop in input budget from 372K to 272K (i.e., Codex total from ~500K to ~400K) means that compaction triggers sooner for long tasks. When a session accumulates enough tokens to hit the budget cap, Codex will automatically compress the conversation history in the background. With the input budget reduced by 100K, the effective budget difference between the two is 95K tokens under the aforementioned 95% effective window performance; however, the actual compaction trigger point remains influenced by account, routing, and runtime factors, and is not a fixed 95K advance.

For standalone calls using an API key, 272K is a key billing boundary. According to the official API documentation, once a single request’s input tokens exceed 272K, the input and output rates for that request are billed at 2× and 1.5× respectively. While this rate adjustment applies only to that specific request and does not mean the entire bill is doubled, it does significantly raise the cost of long sessions.

When using the ChatGPT subscription channel, users do not directly pay for overages, but this still imposes server-side resource and capacity planning pressure, and 272K happens to coincide with the billing boundary. In the issue #19464 discussion, engineering contributor Eric Traut mentioned that supporting a 1M-level context on the client side requires server-side implementation and capacity planning. This reflects backend resource considerations, but cannot be taken as an official explanation of the motive behind this version adjustment.

At the same time, local configuration changes on the client side cannot reliably unlock a larger window in the cloud; large-context operation still requires cloud-side cooperation. Therefore, standalone API-key calls and Codex client sessions through a ChatGPT subscription do not share the same context quota conventions.

Guarding against context overruns or premature compaction in long tasks cannot rely on looking at the model specification alone. Developers need to establish a clear set of checking rules: first read the active runtime’s model_context_window, then observe the actual compaction behavior under the current account routing, and test long tasks under the same routing. Only when all four — model specification, product channel, runtime window, and actual compaction behavior — are considered together do they define the context boundary truly available to a session.