[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.707.30751 (bundle build 5018), bundled CLI codex-cli 0.144.0-alpha.4, model catalog client version 0.144.0.
What subscription do you have?
ChatGPT Pro.
What platform is your computer?
Darwin 27.0.0 arm64 arm
macOS 27.0 (26A5378j), Apple Silicon.
What issue are you seeing?
Codex currently gives gpt-5.6-sol threads a 353,400-token effective context window even though the public GPT-5.6 Sol API model specification advertises a 1,050,000-token context window.
This is not only a UI rounding problem. The freshly fetched, server-provided Codex model catalog contains the following metadata for gpt-5.6-sol:
{
"context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95,
"auto_compact_token_limit": null
}Codex core therefore computes and uses this effective window:
372,000 * 0.95 = 353,400App Server exposes model_context_window: 353400 in the thread's task_started and subsequent token-usage events, and the Codex App displays a total window of approximately 353k.
With auto_compact_token_limit absent, Codex derives the default compaction threshold from 90% of the raw catalog window:
372,000 * 0.90 = 334,800No context-window, auto-compaction, project-level, environment-variable, or provider override is configured locally. The catalog was freshly fetched with a current ETag, so this does not appear to be stale local metadata.
The current evidence establishes a Codex catalog/runtime cap. It does not claim that the upstream model endpoint itself rejects inputs above 372,000 tokens.
What steps can reproduce the bug?
- Use the Codex App version above with the official
openaiprovider and a ChatGPT Pro account. - Select
gpt-5.6-soland start a fresh local thread. - Open the context-window indicator. Codex reports a total usable window of approximately
353ktokens. - Inspect the
gpt-5.6-solentry in~/.codex/models_cache.json; observecontext_window: 372000,max_context_window: 372000, andeffective_context_window_percent: 95. - Inspect the sanitized thread metadata; observe
task_started.model_context_window: 353400and the same value in subsequent token-usage events.
What is the expected behavior?
The public API model specification lists a 1,050,000-token context window for GPT-5.6 Sol:
https://developers.openai.com/api/docs/models/gpt-5.6-sol
Absent a documented Codex-specific preview cap, the Codex catalog should match that raw model window or clearly disclose the product-specific limit. With the same 95% effective-window policy, a 1,050,000-token raw window would imply approximately 997,500 usable tokens:
1,050,000 * 0.95 = 997,500The current 353,400-token effective budget is only about 35.4% of the effective window implied by the published API model specification, a reduction of about 64.6%. The derived 334,800-token default compaction threshold is only about 31.9% of the published 1.05M raw window.
Additional information
Codex computes the effective window from the resolved catalog metadata and effective_context_window_percent:
The protocol defines the effective percentage and derives the default compaction limit when no explicit limit is supplied:
App Server exposes the computed model context window through the thread token-usage protocol:
The practical impact is severe for repository-scale analysis, long-running agentic coding sessions, large specifications, tool-heavy workflows, and multi-agent coordination because Codex begins managing context pressure at roughly one third of the published raw model capacity.
Related but not duplicate reports:
- #30875 reports GPT-5.5 catalog/runtime context-window oscillation involving the same 353,400-token value.
- #19464 and #30910 request larger GPT-5.5 Codex windows but do not report this GPT-5.6 Sol catalog mismatch against the published 1.05M specification.
Please confirm whether the 372,000-token Codex cap is intentional. If it is not, the gpt-5.6-sol catalog metadata should expose the correct raw and maximum context window. If it is intentional, Codex should document the product-specific limit clearly instead of presenting 353,400 as the model's context window without explanation.
14 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Pretty much the same as it was for GPT 5.5. Let me add some weight here:
It is a critical miss on Open AI's side to release a model like SOL with a 300k tokens context window. Literally: what is the point? Below 1M as useless as it gets for a frontier model.
ChatGPT Pro user here. This 372K catalog cap (353.4K effective) on GPT-5.6 Sol is a hard blocker for my work.
I verified it locally: overriding the client catalog/context to 1.05M, disabling Responses Lite, and switching from WebSocket to HTTP all still produced a server-side context-window error at 380,005 input tokens. So this is not a UI or client accounting issue.
I specifically need a true ~1M context window on the current top model inside Codex under the ChatGPT subscription. API-only 1.05M access does not solve the subscription use case. If this remains capped, I will move long-context work to Claude Code.
Please align Codex Pro with GPT-5.6 Sol's advertised 1.05M window, or publish a concrete rollout timeline.
gpt 5.5 in codex with 400k context window is Ok because now we have gpt 5.6
gpt 5.6 in codex with 372k (holy how could it be even less than gpt 5.5 's) context window is NOT Ok because we haven't gpt 6, while claude code with Opus supports 1M long time ago!
Update (July 13): this appears to have regressed further. With Codex CLI 0.144.1 and a freshly fetched model catalog, gpt-5.6-sol now reports
... yielding 258400 effective tokens.
On July 9, the same setup reported 372000 -> 353400 effective tokens.
codex debug modelsand app-server usage agree, so this is not a client display issue.Is the 272K Codex subscription cap intentional, and if so, where is it documented?
Same issue appeared today for me - PRO subscription on win11 app - Poland.
This may answer your doubts.
<img width="928" height="810" alt="Image" src="https://github.com/user-attachments/assets/23831b11-6ef3-46b2-b129-45541f84eeb3" />
Source: https://x.com/thsottiaux/status/2076495156757577895
Please expose the full ~1M-token context for GPT‑5.6 Sol in the Codex App, CLI, and IDE. Competing coding workflows using Chinese models already provide 1M context, while Codex compacts much earlier despite the API model supporting 1.05M.
Please offer 1M as an opt-in setting, potentially with a higher credit multiplier, and allow
model_context_window = 1000000to be honored instead of catalog-clamped.+1
99% of long horizon work has become waiting on compacting.
+1 its been weeks since Tibo says they will bring back the 373k context window... It is completely unacceptable.
Additional current evidence: Windows, ChatGPT Pro, Codex 0.146
I can reproduce the same issue on the current Windows Codex Desktop build after a full application restart.
Environment:
Freshly downloaded model catalog after restart:
context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95
Fresh turn telemetry reports:
task_started.model_context_window: 258400
This exactly matches 272000 * 95% = 258400.
I also tested the documented top-level override:
model_context_window = 1050000
The setting remains present and config validation succeeds, but it is clamped by the server-delivered max_context_window of 272000. The running thread therefore remains at 258400.
For diagnosis, temporarily changing the local catalog context_window and max_context_window to 1050000 caused a fresh session to report 997500 effective tokens. After restarting Codex, the remote catalog was downloaded again, restored both values to 272000, and the runtime returned to 258400. This demonstrates that the restriction is imposed by the current Codex catalog and is not a UI rounding problem or a malformed local configuration.
The official GPT-5.6 Sol page still documents a 1,050,000-token context window: https://developers.openai.com/api/docs/models/gpt-5.6-sol
Please clarify whether 272000 is an intentional Codex product limit for ChatGPT Pro. If intentional, disclose it explicitly in the model picker and plan documentation. If not intentional, please correct max_context_window in the server-delivered Codex catalog so the documented override and the published model capacity can be used.
I hit this while running an endurance test against the Codex backend. A connectivity probe measured the actual accepted context size for the subscription endpoint (chatgpt.com/backend-api/codex/responses):
Token counts are the provider's own usage.input_tokens, not client-side estimates, and the rejections reproduce.
The same models accept 600,007 tokens through api.openai.com/v1/responses, so this is a limit imposed by the subscription transport, not
the model. That distinction isn't documented anywhere I could find — the published figure is the 1,050,000 model window, and the error
message is a generic context_length_exceeded that doesn't state the actual ceiling.
By comparison, Anthropic and Moonshot both return the limit in the error text (prompt is too long: 1050081 tokens > 1000000 maximum, exceeded model token limit: 262144), which makes it trivial to configure a client correctly. Including the effective cap in the Codex error would save a lot of guessing.
<img width="1467" height="824" alt="Image" src="https://github.com/user-attachments/assets/2061bd77-54f3-4f3c-811e-ad2138fe0b60" />
Apparently openai doesn't care about us and is forcing us to give up gpt 5.6, for after 2 weeks there is still no proper answer or solution.
Just spawn 6 subagents and pray for your ctx window.
As it stands, I believe this is to squash any real viability on mainstream
Hermes/openclaw. By the time you get to actual work, it ends up in a death
loop of context compaction.
On Mon, Aug 3, 2026 at 8:29 AM akakoori @.***> wrote: