›_ Codex Issues
Codex Issues / #40258

[Backend/model catalog] GPT-5.6 Sol is originator-gated: coding clients get 272K while the same account gets 872K

Open 💬 5 comments Opened Aug 23, 2026 by Proview-China
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

~~~json
{
"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?

  1. Authenticate to the ChatGPT Codex backend with one account.
  2. Request the model catalog without an originator header:

~~~bash
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"
~~~

  1. Record gpt-5.6-sol.max_context_window; it is 872000.
  2. Repeat the identical request, changing only this header:

~~~bash
-H "originator: codex_cli_rs"
~~~

  1. Record gpt-5.6-sol.max_context_window; it is now 272000.
  2. Repeat with codex-tui, Codex Desktop, and codex_vscode; all return the same 272K catalog ETag.
  3. Repeat with codex_atlas or codex_chatgpt_desktop; both return the 872K catalog ETag.
  4. In Codex App/CLI, configure model_context_window = 372000 and select Sol.
  5. Start a fresh thread. The remotely delivered max_context_window = 272000 clamps 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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39144
  • #40106
  • #38917

Powered by Codex Action

Proview-China · 4 days ago

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:

  • a permanent product policy,
  • a temporary or emergency mitigation,
  • a staged rollout/experiment, or
  • an unintended backend regression?

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 · 4 days ago

btw, if it's astra or sth else, close the issue without leaving any info.

Lang45 · 4 days ago

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: 272000 and max_context_window: 272000, while Terra and Luna both retained max_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 reports max_context_window: 872000 for 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 · 7 hours ago

I can independently reproduce this issue on macOS in Codex Desktop with ChatGPT authentication.

Environment:

  • ChatGPT Desktop: 26.825.31414
  • Bundled Codex CLI: 0.150.0-alpha.12.2
  • Model: gpt-5.6-sol
  • Reasoning effort: Ultra
  • Observed: 2026-08-28 (Asia/Shanghai)

Configuration:
model_context_window = 1000000
model_auto_compact_token_limit = 900000

Observed behavior on the same ChatGPT-authenticated account:

  • GPT-5.6 Sol: context_window = 272000, max_context_window = 272000
  • GPT-5.6 Terra: max_context_window = 872000
  • GPT-5.6 Luna: max_context_window = 872000
  • All three report effective_context_window_percent = 95.

The Codex UI reports 195,131 / 258K remaining/used capacity for the Sol task, and the local trace records full_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.