Repository navigation
[Backend/model catalog] GPT-5.6 Sol is originator-gated: coding clients get 272K while the same account gets 872K #40258
Description
What issue are you seeing?
Summary
On the same ChatGPT Pro account, the authenticated /backend-api/codex/models?client_version=0.149.0 endpoint returns two different GPT-5.6 Sol catalog variants based solely on the HTTP originator request header.
Codex coding surfaces receive:
{
"slug": "gpt-5.6-sol",
"context_window": 272000,
"max_context_window": 272000
}The same request, with the same authorization token, account ID, URL, client version, and network path, receives max_context_window: 872000 when the coding originator is absent or replaced by a non-coding originator.
This causes Codex App/CLI to clamp an explicit model_context_window = 372000 override to 272,000. After the normal 95% effective-window factor, the UI reports 258,400 tokens.
Controlled result
originator header |
Sol max_context_window |
Response ETag |
|---|---|---|
codex_cli_rs |
272000 | bee0ee83ca1fe7b0d482cee5cf45ee98 |
codex-tui |
272000 | bee0ee83ca1fe7b0d482cee5cf45ee98 |
Codex Desktop |
272000 | bee0ee83ca1fe7b0d482cee5cf45ee98 |
codex_vscode |
272000 | bee0ee83ca1fe7b0d482cee5cf45ee98 |
| omitted | 872000 | 88ec06819eef0168a374351aeec2bc6c |
foo |
872000 | 88ec06819eef0168a374351aeec2bc6c |
codex |
872000 | 88ec06819eef0168a374351aeec2bc6c |
codex_atlas |
872000 | 88ec06819eef0168a374351aeec2bc6c |
codex_chatgpt_desktop |
872000 | 88ec06819eef0168a374351aeec2bc6c |
Terra and Luna remain at max_context_window: 872000 in both catalog variants.
A structural comparison of the raw, un-deserialized response bodies shows that only gpt-5.6-sol changes. Its only differing fields are:
| Field | Coding-originator catalog | Other/no-originator catalog |
|---|---|---|
max_context_window |
272000 | 872000 |
minimal_client_version |
0.142.2 | 0.144.0 |
available_in_plans |
includes an additional ent26 entry |
no ent26 entry |
Both variants include pro in available_in_plans. The account continuously reports plan_type: pro.
The raw response contains no cohort, experiment, rollout, bucket, region, entitlement, or downgrade-reason field. Response headers also contain no experiment/cohort marker.
User-visible regression timeline
With the same account, Codex CLI 0.149.0, model, and model_context_window = 372000 configuration:
- Last observed effective window of 353,400:
2026-08-21T08:58:30Z - First observed effective window of 258,400:
2026-08-22T13:16:48Z
No CLI-version or local configuration change occurred between those observations.
This narrows the behavior reported in #39144: the server-side catalog split is reproducibly selected by originator, rather than by the account subscription alone.
What steps can reproduce the bug?
- Authenticate to the ChatGPT Codex backend with one account.
- Request the model catalog without an
originatorheader:
curl -H "Authorization: Bearer <redacted-access-token>" -H "ChatGPT-Account-ID: <redacted-account-id>" "https://chatgpt.com/backend-api/codex/models?client_version=0.149.0"- Record
gpt-5.6-sol.max_context_window; it is 872000. - Repeat the identical request, changing only this header:
-H "originator: codex_cli_rs"- Record
gpt-5.6-sol.max_context_window; it is now 272000. - Repeat with
codex-tui,Codex Desktop, andcodex_vscode; all return the same 272K catalog ETag. - Repeat with
codex_atlasorcodex_chatgpt_desktop; both return the 872K catalog ETag. - In Codex App/CLI, configure
model_context_window = 372000and select Sol. - Start a fresh thread. The remotely delivered
max_context_window = 272000clamps the configured value, producing a 258,400 effective context window.
No credentials, account IDs, or response cookies are included in this report.
What is the expected behavior?
GPT-5.6 Sol should receive the same 872,000 Codex override ceiling across supported Codex coding originators, consistent with Terra/Luna and the bundled 0.149.0 catalog.
If the 272K Sol limit is intentional for specific product surfaces, the distinction and rollout/eligibility criteria should be documented. The model-catalog response should not silently downgrade only Sol based on originator while the same account receives 872K through another first-party originator.
Additional information
Related issue: #39144
Relevant upstream change: #39102 / commit 2eee483e49f88b868f67364134a658b3298e6c14 explicitly raises the bundled maximum context override for GPT-5.6 Sol, Terra, and Luna to 872,000.
Codex 0.149.0 sends originator as a default request header. For ChatGPT authentication, the remote model catalog is authoritative, and the local override is clamped to the remotely supplied max_context_window.
The official GPT-5.6 Sol model page currently advertises a 1,050,000-token model context window. This report concerns the Codex product catalog limit and its originator-dependent server-side selection, not the underlying model specification.
Activity
github-actions commentedon Aug 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Proview-China commentedon Aug 23, 2026
A clarification on intent: we have isolated the immediate trigger/mechanism, but not the backend rationale. The catalog selects the lower Sol variant when the request uses a supported Codex coding originator. What remains unknown is whether that behavior is deliberate.
Could a maintainer clarify whether this is:
If it is intentional, please document the reason and the eligibility/routing criteria. If it is a bug, please prioritize a fix. I had been using model_context_window = 372000 reliably (353,400 effective after the 95% factor), and the sudden server-side clamp to 272,000 (258,400 effective) is a material regression in my established workflow. Restoring at least the previously working 372K configuration would resolve the immediate disruption.
For timeline context, I set model_context_window = 372000 only after Tibo's public post on X indicating that 1M context support was available. The 372K configuration then worked reliably before this regression appeared.
I am aware that I could edit ~/.codex/models_cache.json locally to force the larger value, but I explicitly do not want to bypass the server-delivered catalog or rely on an unsupported cache modification. I want to remain within officially supported behavior and avoid any risk that such a workaround could be misclassified as circumvention or abusive access.
As a half-Chinese user, I would rather not look like I am trying some gray-market workaround from China — half joking, but that is exactly why I prefer an officially supported fix over patching a local cache.
Proview-China commentedon Aug 23, 2026
btw, if it's astra or sth else, close the issue without leaving any info.
Lang45 commentedon Aug 23, 2026
I can independently reproduce the same catalog behavior and user-visible result through the normal Codex coding-client path. After allowing Codex to refresh its remote model catalog, I inspected the three GPT-5.6 entries from the same fetch. Sol was returned with
context_window: 272000andmax_context_window: 272000, while Terra and Luna both retainedmax_context_window: 872000. All three entries reported the same 95% effective-window factor.I then compared the refreshed remote catalog with
codex debug models --bundled. The bundled catalog reportsmax_context_window: 872000for Sol, confirming that the lower Sol limit exists only in the server-delivered coding-client catalog.For completeness, I was able to restore the larger window locally without editing the refreshable models_cache.json. I generated a separate model catalog from the normal remote catalog, changed only gpt-5.6-sol.max_context_window from 272000 to the 872000 value already present in the bundled catalog, and loaded that file through the documented model_catalog_json setting.
After restarting Codex and opening a fresh Sol task, the 258.4K clamp was removed and the larger configured window was honored. I did not change the originator header, authentication, or any network request.
This is only a client-side workaround.
XiaoDaiGua-Ray commentedon Aug 28, 2026
I can independently reproduce this issue on macOS in Codex Desktop with ChatGPT authentication.
Environment:
Configuration:
model_context_window = 1000000model_auto_compact_token_limit = 900000Observed behavior on the same ChatGPT-authenticated account:
context_window = 272000,max_context_window = 272000max_context_window = 872000max_context_window = 872000effective_context_window_percent = 95.The Codex UI reports
195,131 / 258Kremaining/used capacity for the Sol task, and the local trace recordsfull_context_window_limit = 258400. This exactly matches the 272,000 server-side cap after the 95% effective-window factor.The local 1M configuration does not change the Sol result; the server-delivered model metadata is authoritative and clamps the local value. I did not modify the refreshable model cache or any request headers. Terra and Luna receive the expanded profile in the same installation and account.
The public GPT-5.6 model documentation lists a 1.05M context window for Sol, Terra, and Luna:
https://developers.openai.com/api/docs/models/compare
Could you please check whether this is an incomplete rollout, an account/entitlement mismatch, or an originator-specific model-catalog configuration? If the 272K Sol limit is intentional for Codex coding clients, please document the eligibility and routing rules; otherwise, please restore the expanded Sol profile.
Proview-China commentedon Sep 2, 2026
Problem solved.
Thank you Tibo and the codex/chatgpt team.
Thank you for releasing the 872 k context window on the server side.
samiralibabic commentedon Sep 17, 2026
Solved how?
XiaoDaiGua-Ray commentedon Sep 22, 2026
@samiralibabic just need upgrade codex!