GPT-5.5 Codex session hits unrecoverable compaction failure around ~220k tokens despite advertised 400k context
What version of Codex CLI is running?
0.124.0
What subscription do you have?
GPT-5.5 is marketed as a Codex model with 400K context and tuned long-running behavior, but it appears not to support /responses/compact/native compaction. As a result, every GPT-5.5 Codex session is effectively non-recoverable once it approaches the context limit. This makes GPT-5.5 unusable for long-running Codex work despite being positioned as the recommended Codex model.
Which model were you using?
gpt-5.5
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
GPT-5.5 is marketed as a Codex model with 400K context and tuned long-running behavior,
but it appears not to support /responses/compact/native compaction.
As a result, every GPT-5.5 Codex session is effectively non-recoverable once it approaches 272k tokens context.
This makes GPT-5.5 unusable for long-running Codex work despite being positioned as the recommended Codex model.
What steps can reproduce the bug?
Environment
- Codex CLI version:
<paste codex --version here> - OS:
<Windows / macOS / Linux> - Auth mode: ChatGPT login / Codex subscription
- Plan: Pro
- Model:
gpt-5.5 - Also reproducible when
gpt-5.5is used as a subagent from agpt-5.4parent session.
Config
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
# I tried both the default settings and explicit lower limits.
# The failure still happens once the session gets close to the effective context limit.
model_auto_compact_token_limit = 180000
tool_output_token_limit = 8000
Reproduction steps
Start a fresh Codex session using gpt-5.5 xhigh.
Work on a non-trivial repository task that causes the session context to grow.
For example:
- ask Codex to inspect multiple source and test files;
- run test/build commands with tool output;
- continue several implementation/debugging turns until the session reaches roughly 200k–220k tokens.
- Wait for Codex to trigger remote compaction automatically, or continue the task until compaction is required.
- The remote compaction task fails.
After the first failure, continuing the same session usually keeps failing because the same oversized conversation history is reused. The session effectively becomes unrecoverable.
error belike:
Error running remote compact task:
{"error":{"message":"invalid_request_error: 请求格式非法,请检查请求结构是否符合 API 规范", "type":"invalid_request_error", "code":"invalid_request_error"}}
or
Error running remote compact task:
unexpected status 503 Service Unavailable:
所有供应商暂时不可用
url: /v1/responses/compact
### What is the expected behavior?
_No response_
### Additional information
_No response_
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This may be related to #19306 / #19319, but I think this report captures the downstream failure mode rather than only the displayed context-window mismatch.
The issue is not just that GPT-5.5 reports ~258400 instead of the advertised 400K context window.
The practical failure is:
This appears consistent with #19255, which reports auto compact errors near the effective context limit with
model_context_window_tokens=Some(258400)and subagent failures.So even if the root cause overlaps with #19306 / #19319, the user-visible bug here is the unrecoverable compaction failure, not only the context-window display value.
Same here
Same here, something isn't right. I now try to drastically scope my sessions with subagents and handing off work to (parallel) sessions via
app-server, but it's a far cry from the advertised 400K or _"Codex automatically compacts its context"_.Error running remote compact task: stream disconnected before completion: error sending request for urlis (still) a real productivity killer.(https://chatgpt.com/backend-api/codex/responses/compact)
A weak workaround to get past a compaction hump is switching from
gpt-5.5togpt-5.3-codexor evengpt-5.4-mini(and then back togpt-5.5), but this really hurts session performance and likely also thrashes context caches + quota consumption.I am seeing a closely related issue on Codex CLI under Windows 11 + WSL2.
My GPT-5.5 Codex session reported:
Earlier in the same session, Codex explicitly changed its behavior because the context was above 70%:
Environment:
For large-codebase work, this makes the usable session much smaller than expected. Once the session is above 70%, Codex starts behaving as if it must conserve context, so the practical working limit is around 180K tokens, not 400K.
The issue is not only the displayed number. The practical problem is that long-running GPT-5.5 Codex work becomes fragile too early. This directly affects whether GPT-5.5 Codex can be used seriously for large software projects.
Also seeing this on Codex Desktop for macOS.
Thread ID:
019e0390-d329-74c3-b8ab-13a32d339c9bCodex App:
26.429.61741 (2429)Error:
This is still happening today (2026-05-07).
MACOS 26.4 >>>>>:
<img width="1054" height="140" alt="Image" src="https://github.com/user-attachments/assets/9d0aad07-6744-4406-b076-c6966a577d5e" />
<img width="1054" height="140" alt="Image" src="https://github.com/user-attachments/assets/f36d1d45-8ae9-4f84-9135-51df019e1883" />
<img width="408" height="260" alt="Image" src="https://github.com/user-attachments/assets/2849eb01-f9dc-413b-92fb-6858dd6a9879" />
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.