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

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop app version: 26.623.5546.0

Installed Windows package:

OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0

Desktop runtime checked locally:

codex-cli 0.142.3

What subscription do you have?

ChatGPT Plus / Codex Desktop shows full access.

What platform is your computer?

Windows x64.

What issue are you seeing?

Codex Desktop is reporting different effective context-window sizes for the same gpt-5.5 model across different launches and threads on the same Windows installation.

The same installation has recently reported both:

258400 effective tokens = 272000 * 95%
353400 effective tokens = 372000 * 95%

Right now, fresh/new threads report the smaller value:

17k / 258k tokens

This does not appear to be caused by an active local config override. The active global and project config files do not contain:

model_context_window
model_auto_compact_token_limit
model_catalog_json

Fresh check from the Desktop runtime currently returns:

codex-cli 0.142.3
slug: gpt-5.5
display_name: GPT-5.5
context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95
effective_context_window: 258400
comp_hash: 2911
checked_at: 2026-07-02 01:54:45 +03:00

The current models_cache.json also contains the smaller catalog value:

context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95
comp_hash: 2911

However, recent rollout logs from the same machine contain both effective window values:

2026-06-27T20:00:41Z -> model_context_window: 353400
2026-06-28T04:54:21Z -> model_context_window: 353400
2026-06-30T18:40:03Z -> model_context_window: 353400
2026-07-01T11:07:26Z -> model_context_window: 258400
2026-07-01T12:26:00Z -> model_context_window: 353400
2026-07-01T22:45:45Z -> model_context_window: 258400

One long-running rollout contains both values:

rollout-2026-06-27T21-56-17-019f0a70-7e54-7b23-a839-100347b54895.jsonl

258400 count: 1075
353400 count: 1422

Another rollout also contains multiple values:

rollout-2026-06-25T19-25-40-019eff99-f610-7693-8766-6637de02a8ff.jsonl

258400 count: 88
260300 count: 13
353400 count: 34

So this looks like a model-catalog / rollout stability issue rather than a UI-only issue. The Desktop runtime's own debug models output and models_cache.json currently report the lower value.

What steps can reproduce the bug?

This is intermittent, so I cannot force a deterministic repro yet. The observable pattern is:

Start Codex Desktop on Windows.
Use model gpt-5.5.
Start a new thread or resume an existing one.
Hover the context-window indicator in the composer.
Observe that the effective context limit is sometimes around 258k, while recent sessions on the same installation reported around 353k.
Run codex debug models against the Desktop runtime and inspect the gpt-5.5 entry.
Compare with rollout logs: recent sessions contain both 258400 and 353400 as model_context_window.

Diagnostic command used:

$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
[pscustomobject]@{
  codex_version = ((& $desktop --version) -join ' ')
  slug = $m.slug
  display_name = $m.display_name
  context_window = $m.context_window
  max_context_window = $m.max_context_window
  effective_context_window_percent = $m.effective_context_window_percent
  effective_context_window = [int]($m.context_window * $m.effective_context_window_percent / 100)
  comp_hash = $m.comp_hash
  checked_at = (Get-Date).ToString('yyyy-MM-dd HH:mm:ss zzz')
}

Config verification:

$paths = @(
  'C:\Users\<user>\.codex\config.toml',
  'C:\Users\<user>\Documents\6_Work\1_codex\.codex\config.toml'
)

foreach ($p in $paths) {
  if (Test-Path -LiteralPath $p) {
    $text = Get-Content -LiteralPath $p -Raw
    [pscustomobject]@{
      Path = $p
      HasContextOverride = ($text -match '(?m)^\s*model_context_window\s*=')
      HasCompactOverride = ($text -match '(?m)^\s*model_auto_compact_token_limit\s*=')
      HasCatalogOverride = ($text -match '(?m)^\s*model_catalog_json\s*=')
      Model = ([regex]::Match($text,'(?m)^\s*model\s*=\s*"([^"]+)"').Groups[1].Value)
    }
  }
}

Current result:

HasContextOverride: false
HasCompactOverride: false
HasCatalogOverride: false
Model: gpt-5.5

What is the expected behavior?

For the same installed Codex Desktop version, same account, same model slug (gpt-5.5), and no active local model override:

the model catalog should be stable, or
if the account is being moved between rollout cohorts / catalog variants, Codex should expose enough diagnostic information to explain the change, and
a new thread should not unpredictably alternate between lower and higher effective context windows without a visible reason.

Additional information

Related issues I found before filing:

Those look related to context-window instability / mismatch, but this report is specifically for Codex Desktop on Windows where the same gpt-5.5 slug oscillates between 258400 and 353400 effective context tokens, with the current local catalog back at:

272000 * 95% = 258400
comp_hash = 2911

There was an earlier local experiment with manual context/catalog overrides while trying to diagnose this, but those overrides have been removed. The current active config is clean:

no model_context_window
no model_auto_compact_token_limit
no model_catalog_json

Screenshots are available showing the UI reporting 258k effective tokens in multiple sessions, including a case where auto-compaction was displayed around 135k / 258k.

Could you clarify whether gpt-5.5 is expected to have multiple active context-window catalog variants in Codex Desktop?

If this is expected rollout behavior, it would help if Codex surfaced the active catalog/variant reason somewhere in diagnostics. If not expected, this looks like a stale or oscillating model catalog/cache issue for gpt-5.5.

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

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

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

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

Add model_catalog_json to config.toml with the absolute path to that file.
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

Restart Codex Desktop / VS Code extension.
Select gpt-5.5.
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:

Some clients/profiles/accounts are still receiving or regenerating a stale gpt-5.5 catalog entry with 272000 / comp_hash 2911.
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 ### --_-

fix(codex): correct the gpt-5.6 context window to the 272K OpenAI act…

Navigation Menu

Repository navigation

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

What version of the Codex App are you using (From "About Codex" dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Symptom

Things that did not fix it

Workaround that fixed it

Verification

Practical steps for anyone hitting this

Caveats

Questions for maintainers

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using (From "About Codex" dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 1, 2026

i4w7w4a commented on Jul 1, 2026

i4w7w4a commented on Jul 1, 2026

i4w7w4a commented on Jul 1, 2026

i4w7w4a commented on Jul 2, 2026

i4w7w4a commented on Jul 2, 2026

i4w7w4a commented on Jul 2, 2026

i4w7w4a commented on Jul 2, 2026

Symptom

Things that did not fix it

Workaround that fixed it

Verification

Practical steps for anyone hitting this

Caveats

Questions for maintainers

i4w7w4a commented on Jul 2, 2026

i4w7w4a commented on Jul 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions