GPT-5.6 Sol still receives 272K max_context_window after long-context rollout; Terra and Luna receive 872K

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

• #38917

Powered by Codex Action

Potentially related to #38917, but not a duplicate.

#38917 reports that the documented 1M override for GPT-5.6 Sol does not take effect and that Sol remains capped at 272K.

This report is narrower and concerns the post-rollout catalog inconsistency observed in the same fresh /models response and ETag:

• gpt-5.6-sol: max_context_window = 272000
• gpt-5.6-terra: max_context_window = 872000
• gpt-5.6-luna: max_context_window = 872000

So long-context catalog metadata is already enabled for Terra and Luna on this account, but not for Sol. That model-specific discrepancy is the issue being reported here.

This also reproduces in the Codex CLI, not only the Desktop app.

The affected behavior is the same: after a fresh /models refresh, gpt-5.6-sol receives max_context_window = 272000, while Terra and Luna receive 872000 in the same catalog response/ETag.

Could this issue also receive the CLI label?

Im using high context on Sol and my models_cache.json Sol has the same "max_context_window": 872000 as others ( I did not manually edit it or smh)

Im using high context on Sol and my models_cache.json Sol has the same "max_context_window": 872000 as others ( I did not manually edit it or smh)

Thanks. That appears to be the expected post-rollout state for accounts that have received the expanded Sol profile.

On my account, however, a fresh server-delivered model catalog still returns max_context_window: 272000 for Sol, while Terra and Luna return 872000 in the same fetch and under the same ETag. I did not manually edit the cache.

I attached a screenshot showing the model entries, ETag, fetch timestamp, and context-window fields. This suggests the rollout is active but Sol’s expanded profile is not being delivered consistently to every account.

<img width="603" height="722" alt="Image" src="https://github.com/user-attachments/assets/5274cdda-c3f0-4ffa-9e4d-8eae5ec3843b" />

Resolved on my account.

A fresh server-delivered model catalog now returns:

gpt-5.6-sol: context_window = 272000, max_context_window = 872000
gpt-5.6-terra: context_window = 272000, max_context_window = 872000
gpt-5.6-luna: context_window = 272000, max_context_window = 872000

New GPT-5.6 Sol chats now honor the expanded context window as expected.

I attached a sanitized catalog excerpt with the new ETag and fetch timestamp. The model-specific rollout/catalog discrepancy is no longer reproducible for me.

Closing as resolved. Thanks.

<img width="563" height="682" alt="Image" src="https://github.com/user-attachments/assets/f6711188-9b1d-4621-a3c0-cb5d49226645" />

This is still reproducible on another ChatGPT-authenticated account as of 2026-08-20.

Environment:

• Codex CLI: 0.148.0
• Fresh server-delivered catalog fetched at 2026-08-20T05:29:09Z

The same catalog response currently returns:

gpt-5.6-sol:   context_window = 272000, max_context_window = 272000
gpt-5.6-terra: context_window = 272000, max_context_window = 872000
gpt-5.6-luna:  context_window = 272000, max_context_window = 872000

A local long-context configuration is therefore still capped for Sol. Temporarily changing only Sol's max_context_window in models_cache.json to 872000 is respected, but the next server catalog refresh rewrites Sol back to 272000; Terra and Luna remain at 872000.

Since the original reporter's account has received the corrected Sol profile but another account still has not, the rollout/catalog discrepancy appears to remain account-scoped or incomplete. Please reopen this issue or continue tracking affected accounts.

This is still reproducible on another ChatGPT-authenticated account as of 2026-08-20. Environment: Codex CLI: 0.148.0 Fresh server-delivered catalog fetched at 2026-08-20T05:29:09Z The same catalog response currently returns: `` gpt-5.6-sol: context_window = 272000, max_context_window = 272000 gpt-5.6-terra: context_window = 272000, max_context_window = 872000 gpt-5.6-luna: context_window = 272000, max_context_window = 872000 ` A local long-context configuration is therefore still capped for Sol. Temporarily changing only Sol's max_context_window in models_cache.json to 872000 is respected, but the next server catalog refresh rewrites Sol back to 272000; Terra and Luna remain at 872000`. Since the original reporter's account has received the corrected Sol profile but another account still has not, the rollout/catalog discrepancy appears to remain account-scoped or incomplete. Please reopen this issue or continue tracking affected accounts.

Reopening based on the reproduction above. My account remains resolved and receives 872000 for Sol, but another ChatGPT-authenticated account still receives the original server-delivered 272000 Sol profile while Terra and Luna receive 872000. This indicates the issue was resolved for my account, but the rollout/catalog discrepancy is not yet resolved globally.

Same issue here. A fresh /models response gives:

gpt-5.6-sol max_context_window = 272000
gpt-5.6-terra max_context_window = 872000
gpt-5.6-luna max_context_window = 872000

Sol is the only model still receiving the reduced context profile.

One possibility I think is worth considering is that this may be an account-level risk-control profile rather than a random rollout bug.

What makes me suspicious is that the restriction is model-specific: only Sol is capped at 272000, while Terra and Luna on the same account retain the expanded 872000 profile. There also does not appear to be a large wave of users reporting this exact post-rollout combination.

OpenAI has previously used account-level abuse/fraud controls that can reduce available Codex usage without making the underlying mechanism transparent to users, and there have also been community reports of substantial quota reductions on accounts suspected of proxying, resale, or other high-risk usage patterns.

You also mentioned elsewhere that you use two accounts. Multiple accounts by itself is obviously not evidence of abuse, but together with the fact that only a small subset of accounts seem to receive this exact Sol-only reduced profile, it raises the possibility that the server may be assigning different model entitlements based on an internal account risk classification.

To be clear, this is only a hypothesis.

A working workaround is to use a local model catalog. Copy ~/.codex/models_cache.json to ~/.codex/model_catalog_sol_872k.json, then change context_window and max_context_window for gpt-5.6-sol to 872000.

Add this to ~/.codex/config.toml:

model_catalog_json = "C:/Users/<username>/.codex/model_catalog_sol_872k.json"

Restart Codex and create a new task. The effective context window should then be 828400.

Adding another fresh account-specific data point. This issue is still reproducible for me as of August 24, 2026.

Environment

• ChatGPT plan: Pro
• Platform: macOS, Apple Silicon
• Codex CLI: 0.149.1
• Authentication: ChatGPT account, not API key
• Catalog fetched with a clean CODEX_HOME, without user config or a local model-catalog override

Fresh server-delivered catalog

Fetched at 2026-08-24T11:17:31Z:

gpt-5.6-sol:
  context_window = 272000
  max_context_window = 272000

gpt-5.6-terra:
  context_window = 272000
  max_context_window = 872000

gpt-5.6-luna:
  context_window = 272000
  max_context_window = 872000

Catalog ETag:

W/"b4d7f0fd6e7ee4a84d6883adb8a1bc06"

Sol is therefore still clamped to an effective context window of 258400 tokens on my account, while the same catalog response grants the expanded profile to Terra and Luna.

This does not appear to be a client limitation or config parsing issue. When I use a pinned local model catalog with Sol set to:

context_window = 512000
max_context_window = 512000

a fresh live thread reports modelContextWindow = 486400 as expected.

The server-delivered Sol profile has remained at 272000 across multiple fresh catalog fetches, ETags, restarts, and Codex CLI versions from 0.147.0 through 0.149.1.

Adding a controlled client-side result and a minimally invasive workaround.

Environment

• Codex Desktop: 26.820.60940
• Bundled CLI: 0.150.0-alpha.8
• macOS / Apple Silicon
• Existing preferences:

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

Clean baseline

A fresh model-catalog request from a temporary CODEX_HOME, with no user config and no local catalog, returned:

gpt-5.6-sol:   context_window = 272000, max_context_window = 272000
gpt-5.6-terra: context_window = 272000, max_context_window = 872000
gpt-5.6-luna:  context_window = 272000, max_context_window = 872000

A separate controlled run requesting model_context_window = 800000 still reported an effective window of 258400. Changing the requested value alone therefore does not bypass the catalog maximum.

Separate local-catalog workaround

1. Copy the freshly delivered models_cache.json to a separate file. Do not edit the refreshable cache in place.
2. In the copied file, change only the Sol maximum:

{
  "slug": "gpt-5.6-sol",
  "context_window": 272000,
  "max_context_window": 872000
}

The default context_window remains 272000; only max_context_window changes.

1. Point config.toml to the separate catalog while preserving the original preferences:

model = "gpt-5.6-sol"
model_catalog_json = "/absolute/path/to/model_catalog_sol_872k.json"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

1. Fully restart Codex.

Verified behavior

• The Desktop task reports an effective context window of 828400.
• A fresh CLI run with the same local catalog also reports 828400.
• Trace output reports an auto-compaction threshold of 784800, preserving the normal 90%-of-resolved-window behavior.

The client clamps a requested context override to the catalog maximum, as implemented in model_info.rs. Auto-compaction is then clamped to 90% of the resolved raw window in openai_models.rs.

Caveat

model_catalog_json loads a full catalog at process startup; it is not a live one-field overlay. This pins the catalog snapshot and can hide later model-catalog updates. It should be removed after the server-delivered Sol maximum is consistently corrected.

This is a temporary diagnostic workaround, not a backend fix.