GPT-5.5 context window oscillates between 258400 and 353400 effective tokens in Codex Desktop

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

• #29426

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Codex Desktop auto-compacts short resumed sessions even when context usage is far below window #29426 _Powered by Codex Action_

no dublicate.

Clarification: the main issue here is not auto-compaction.

The core issue is that the same Codex Desktop installation/account receives different model catalog entries for the same gpt-5.5 slug.

Current lower catalog:

context_window = 272000
effective_context_window = 258400
comp_hash = 2911

Previously observed higher catalog on the same machine:

context_window = 372000
effective_context_window = 353400
comp_hash = 3000

Question: why is this account/session currently assigned the 272k catalog variant while other users and earlier sessions on the same machine get the 372k variant?

The request is for clarification/fix around model catalog assignment / rollout stability for gpt-5.5, not compaction behavior.

Config clarification: no active local context/window override is set.

To remove ambiguity around local configuration, here are the relevant active config settings from this Windows install.

Global config, sanitized excerpt from ~/.codex/config.toml:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"
personality = "pragmatic"
approval_policy = "never"
sandbox_mode = "danger-full-access"
web_search = "live"
service_tier = "default"

[windows]
sandbox = "elevated"

[desktop]
show-context-window-usage = true
composerEnterBehavior = "cmdIfMultiline"
followUpQueueMode = "steer"
usePointerCursors = true
reduced-motion-preference = "system"
sansFontSize = 15
codeFontSize = 13

Project config, full relevant content from .codex/config.toml:

approval_policy = "never"
sandbox_mode = "danger-full-access"
web_search = "live"

[windows]
sandbox = "elevated"

I also checked the active config files for context/catalog overrides:

~/.codex/config.toml
  HasContextOverride: false
  HasCompactOverride: false
  HasCatalogOverride: false
  HasGpt55Catalog: false
  Model: gpt-5.5

<project>/.codex/config.toml
  HasContextOverride: false
  HasCompactOverride: false
  HasCatalogOverride: false
  HasGpt55Catalog: false

The only file nearby that contains old override-like text is a Markdown note in the workspace:

<project>/CONTEXT_WINDOW_PROMPT.md
  IsActiveConfig: false
  HasContextOverride: true
  HasCompactOverride: true
  HasCatalogOverride: false

That file is not a Codex config file and is not loaded as config.toml. The active config files above do not set:

model_context_window
model_auto_compact_token_limit
model_catalog_json

So the current 272000 -> 258400 effective catalog result is not coming from an active local context-window override.

Additional diagnostic: regenerating models_cache.json did not change the result.

I tested whether this was caused by a stale local model cache.

I did not delete any session/history data. I only renamed the local model catalog cache:

~/.codex/models_cache.json

to a backup file:

~/.codex/models_cache.backup-20260702-150424.json

Then I ran the Desktop runtime diagnostic again:

$desktop = 'C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\aec6b7c6fcdfb66a\codex.exe'
$json = & $desktop debug models | ConvertFrom-Json
$m = $json.models | Where-Object slug -eq 'gpt-5.5' | Select-Object -First 1

Codex recreated ~/.codex/models_cache.json immediately.

Before renaming the cache:

fetched_at: 2026-07-02T12:03:59.134494800Z
etag: W/"d95bbacc229182d305ba11bace65668f"
client_version: 0.142.3
context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95
effective_context_window: 258400
comp_hash: 2911

After regenerating the cache:

fetched_at: 2026-07-02T12:04:25.120477700Z
etag: W/"d95bbacc229182d305ba11bace65668f"
client_version: 0.142.3
context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95
effective_context_window: 258400
comp_hash: 2911

So this is not a stale local models_cache.json issue. After forcing the cache to be regenerated, the backend/catalog still returns the lower gpt-5.5 entry:

272000 raw -> 258400 effective
comp_hash = 2911

This strengthens the suspicion that the issue is server-side catalog assignment / rollout state for this account/session, not local cache corruption.

Additional context: 272000 appears to be an official GPT-5.5 input-budget boundary, but that does not explain the Codex Desktop oscillation.

OpenAI Help Center currently describes GPT-5.5 Thinking Pro tier as:

400k total = 272k input + 128k max output

OpenAI API docs for GPT-5.5 also mention a long-context pricing threshold above:

272K input tokens

So 272000 does not look like a random corrupted local value.

However, the unresolved Codex Desktop question is that the same gpt-5.5 slug on the same Windows Desktop installation/account has previously received this higher Codex catalog entry:

context_window = 372000
effective_context_window = 353400
comp_hash = 3000

and currently receives:

context_window = 272000
effective_context_window = 258400
comp_hash = 2911

Could you clarify which gpt-5.5 catalog entry is expected for Codex Desktop, and why this account/session can move between the 272000 and 372000 raw context-window variants?

The main ask is still not about API context limits or auto-compaction. It is about Codex Desktop model catalog assignment for the same gpt-5.5 slug.

Additional isolation test: clean CODEX_HOME still gets the 272k catalog entry.

I tested whether the reduced GPT-5.5 context window could be caused by local Codex state/config under ~/.codex.

Procedure:

# Create a brand-new temporary CODEX_HOME
# Copy only auth.json into it
# Do not copy config.toml, memories, model-catalogs, global state, or models_cache.json
$env:CODEX_HOME = "%TEMP%\codex-clean-home-*"
codex.exe debug models

The temporary home contained only these files after the command ran:

auth.json
models_cache.json

Result for gpt-5.5:

context_window = 272000
max_context_window = 272000
effective_context_window_percent = 95
effective = 258400
comp_hash = 2911

I also tested these runtime overrides separately, and they did not change the catalog result:

-c service_tier="priority"
-c model_reasoning_effort="high"

Both still returned:

context_window = 272000
effective = 258400
comp_hash = 2911

This makes a normal local configuration issue unlikely. In this clean environment there was no config.toml, no project config, no old models_cache.json, no model_catalog_json, no model_context_window, and no model_auto_compact_token_limit.

The only meaningful shared input left in that test was auth.json, so the current evidence points toward an account/backend model-catalog assignment or entitlement path rather than stale local Codex configuration.

I found a reproducible workaround for the reduced context-window issue on my machine.

This may be related to the auto-compaction behavior reported here, but in my case the root cause was more basic: Codex was reading a model catalog where gpt-5.5 had a reduced context window.

Symptom

On the same account/client, gpt-5.5 sometimes showed only about 258k effective context in the Desktop hover:

Used 25k / 258k tokens

Expected / working value:

Used 31k / 353k tokens

The raw/effective values behind this were:

bad state:  272000 raw -> 258400 effective
good state: 372000 raw -> 353400 effective

This happened in both new and old threads. It also reproduced in the VS Code Codex extension, so it did not look like only one old Desktop conversation was corrupted.

Important detail: gpt-5.4 still shows around 258k, which appears normal for that model. The issue here is specifically when gpt-5.5 is selected but still receives the 272000 / 258k catalog values.

Things that did not fix it

• Creating a new thread.
• Fully restarting Codex Desktop.
• Signing out / signing in again.
• Switching between Desktop and VS Code extension.
• Deleting the normal generated models_cache.json; Codex recreated it with the same reduced 272000 value.
• Testing with a clean CODEX_HOME containing only auth data; the reduced catalog value still came back.

That made it look like the client was receiving, caching, or selecting a different model-catalog entry for gpt-5.5, rather than the thread history itself being the primary cause.

Workaround that fixed it

I pinned Codex to a local model catalog file via model_catalog_json.

In config.toml:

model = "gpt-5.5"
model_catalog_json = 'C:\Users\<USER>\.codex\models_cache.local.json'

Use a real absolute Windows path there. I did not rely on %USERPROFILE% expansion.

Then in models_cache.local.json, the gpt-5.5 entry must contain the larger context-window values:

{
  "slug": "gpt-5.5",
  "context_window": 372000,
  "max_context_window": 372000,
  "comp_hash": "3000",
  "effective_context_window_percent": 95,
  "use_responses_lite": false
}

The critical part is not only context_window.

use_responses_lite also mattered. A local catalog I tested originally had:

"use_responses_lite": true

With that value, gpt-5.5 failed in Codex Desktop with:

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

Changing it to:

"use_responses_lite": false

fixed that error.

Verification

After restarting Codex and selecting gpt-5.5, codex debug models showed:

gpt-5.5
context_window: 372000
max_context_window: 372000
effective_context_window_percent: 95
comp_hash: 3000
use_responses_lite: false

The Desktop hover then showed:

Used 31k / 353k tokens

I also tested an older existing thread. After switching that thread from 5.4 to 5.5 and sending a new message, the same old thread started showing the larger 353k effective window. So old threads were not permanently broken in my case.

Practical steps for anyone hitting this

1. Confirm you are actually on gpt-5.5, not gpt-5.4.
2. Run codex debug models and check the gpt-5.5 entry.
3. If gpt-5.5 shows context_window: 272000, the client/catalog is in the reduced state.
4. Create a local catalog file, for example:

C:\Users\<USER>\.codex\models_cache.local.json

1. Add model_catalog_json to config.toml with the absolute path to that file.
2. Make sure the local gpt-5.5 entry has:

"context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95,
"comp_hash": "3000",
"use_responses_lite": false

1. Restart Codex Desktop / VS Code extension.
2. Select gpt-5.5.
3. Check the hover or codex debug models.

Expected result:

372000 raw / 353400 effective

Caveats

This is a workaround, not a clean product fix.

Pinning model_catalog_json means Codex will use the local model catalog instead of the live server-provided one. That can hide future official catalog updates until the local file is removed or updated.

Once the upstream catalog consistently returns the correct gpt-5.5 values, the safer long-term fix is to remove the model_catalog_json override and go back to the live catalog.

Also, do not paste a full config.toml publicly without checking it first. Mine contained unrelated MCP/server settings and private keys. Only the model and model_catalog_json lines were relevant here.

Questions for maintainers

• Why would gpt-5.5 receive 272000 context-window metadata on one install/account/session while another setup receives 372000?
• Is this controlled by a rollout bucket, service tier, account capability, stale model catalog, or client channel?
• Should gpt-5.5 ever be served with use_responses_lite: true if Desktop then rejects it with X-OpenAI-Internal-Codex-Responses-Lite?
• Could Codex expose the active model-catalog source and raw/effective context values more clearly in the UI or debug models, plus a supported catalog refresh/reset command?

Additional detail about the X-OpenAI-Internal-Codex-Responses-Lite error:

In my case the context-window value and the request channel were two separate parts of the failure.

The local catalog entry had to satisfy both conditions:

"context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95,
"comp_hash": "3000",
"use_responses_lite": false

If context_window is still 272000, Codex works but the UI shows only about 258k effective context.

If context_window is changed to 372000 but use_responses_lite remains true, Codex Desktop tries to route gpt-5.5 through the Lite responses channel and fails with:

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

So the working state was not just "set the larger context window". It was:

gpt-5.5 + 372000 raw context + use_responses_lite=false

I also applied the same fix to an isolated VS Code Codex profile with its own CODEX_HOME. Before the fix, that separate profile's generated models_cache.json also had:

"context_window": 272000,
"max_context_window": 272000,
"comp_hash": "2911",
"use_responses_lite": false

After adding model_catalog_json to that profile's config.toml and pointing it at a local catalog with the corrected gpt-5.5 entry, codex debug models reported:

slug: gpt-5.5
context_window: 372000
max_context_window: 372000
effective_context_window_percent: 95
comp_hash: 3000
use_responses_lite: False

This suggests two likely catalog-side problems:

1. Some clients/profiles/accounts are still receiving or regenerating a stale gpt-5.5 catalog entry with 272000 / comp_hash 2911.
2. Some catalog variants may set use_responses_lite=true for gpt-5.5, even though Desktop then rejects that route for this model.

For anyone debugging this locally, check both values. Looking only at context_window is not enough.

THX ### --_-