ERROR codex_core::compact_remote: remote compaction failed

Resolved 💬 4 comments Opened Mar 2, 2026 by Gusarich Closed Jun 29, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

2026-03-02T17:05:11.672329Z ERROR codex_core::compact_remote: remote compaction failed turn_id=019caf82-2300-7823-8bb7-649a014dec7f last_api_response_total_tokens=117322 all_history_items_model_visible_bytes=470164 estimated_tokens_of_items_added_since_last_successful_api_response=10162 estimated_bytes_of_items_added_since_last_successful_api_response=40646 model_context_window_tokens=Some(121600) failing_compaction_request_model_visible_bytes=483682 compact_error={
  "error": {
    "message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "context_length_exceeded"
  }
}
ERROR: Error running remote compact task: {
  "error": {
    "message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "context_length_exceeded"
  }
}

thread ids: 019caf82-22df-7e33-8aef-07b30337dde0 and 019caf3f-2f08-7fc0-8857-125bede02bca

happened with gpt-5.3-codex-spark, codex-cli 0.107.0-alpha.3, using exec

View original on GitHub ↗

4 Comments

garitar · 5 months ago

I hit what looks like the same failure on codex-cli 0.115.0 on Darwin 25.2.0 arm64, model gpt-5.3-codex-spark with xhigh reasoning.

One extra data point that may help narrow root cause: on this machine, the live Codex model cache at ~/.codex/models_cache.json says Spark has:

{
  "slug": "gpt-5.3-codex-spark",
  "context_window": 128000,
  "effective_context_window_percent": 95
}

So Codex's effective window becomes 121600, which exactly matches the failing runtime log:

ERROR codex_core::compact_remote: remote compaction failed ...
last_api_response_total_tokens=116010
estimated_tokens_of_items_added_since_last_successful_api_response=11672
model_context_window_tokens=Some(121600)
...
"code": "context_length_exceeded"

That suggests this may not just be a generic overflow. If the default auto-compaction threshold is still 90% of raw context, Spark only has 6400 tokens of slack between compact trigger (115200) and effective hard ceiling (121600). In this failure, the last successful response was already at 116010, and the next accumulated step added 11672, so a single search/tool-heavy step seems able to outrun the remaining headroom.

Another bad outcome from the same run: after the compaction failure, Codex wrote an empty final artifact instead of a useful terminal failure result:

Warning: no last agent message; wrote empty content ...

So I think there may be two separate problems here:

Spark's current effective window / compaction timing is too tight for long search-heavy sessions.
When compact_remote overflows, Codex can degrade to an empty final output artifact.

If useful, I can provide a tighter repro packet, but the failing shape here was a broad audit-style run with web search and bounded scratch enabled.

nos1609 · 4 months ago

Got the same issue on gpt-5.4 with codex-cli 0.120.0

Error running remote compact task: { "error": { "message": "Your input exceeds the context window of this model. Please adjust your input and try again.", "type": "invalid_request_error", "param": "input", "code": "context_length_exceeded" }

korenmic · 3 months ago

Error running remote compact task: { "error": { "message": "Your input exceeds the context window of this model. Please adjust your input and try again.", "type": "invalid_request_error", "param": "input", "code": "context_length_exceeded" } }

Getting it in 5.5 in codex desktop too when trying to run /compact

etraut-openai contributor · 1 month ago

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 /feedback and open a new bug report.