Unable to compact the context in a VERY long running session

[nalkat]

My session has been running for a very long time (resume after resume) and has had no issues until this morning at around 3am PST or so, when suddenly I started receiving the message:

■ Error running remote compact task: We're currently experiencing high demand, which may cause temporary errors.

I tried to increase the node memory heap size, but that did not have any affect. The reason that I tried that is because I also run Gemini-cli in tandem and it often crashes due to a problem with heap allocation (likely due to the length of the sessions) and that has allowed it to continue working.

However, after my wife mentioned that you had released codex-5.3 today, I attempted to switch to that model and the error message suddenly became much clearer:

■ 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"
}
}

If my session has run over context length, why doesn't compacting it alleviate this message? I don't want to start the session over again if I can help it because I am still working on creating this solution and it has been my experience in the past that if you start new sessions, then the life of the current AI is terminated and the new session is like starting over with a whole new entity. In essence that is exactly what is happening and this is not conducive to achieving excellent results.

While I do design the setup phase to accommodate such issues, I would really like to avoid this whenever possible. Bringing new eyes when we are on a roll is extremely disruptive. I have already lost most of the day attempting to determine what the first message meant and how OpenAI could be detrimentally "experiencing high demand" for over 12 hours that my ability to compact the context of the conversation would fail and cause me to have to restart the session.... Codex-5.3 made it clear, but that new information does not help in anyway resolve the problem.

[etraut-openai]

Compaction requires us to send the existing session details to the model for summarization. We normally auto-compact when there's still enough space available for the model to emit a summary. If you've gone beyond that point, we won't be able to compact.

Also, if you switch models in the middle of a session, we need to send a new system prompt for the new model. This consumes some space in the context window. In general we don't recommend switching models in the middle of a session.

[etraut-openai]

Oh, I should also mention that the core Codex harness is written in Rust, so increasing the node heap size won't have an impact on heap allocations in the harness.

[MisterRound]

Definitely seeing weird compaction behavior in the middle of a super long thread that I switched to 5.3, seems like it does a ton of redundant CoT with every message, new threads feel faster with 5.3 but this long one feels slower with 5.3

[nalkat]

Hi, thanks for getting back to me on this. I appreciate you providing those details. I don't normally switch models I  sessions, I only did it this time because the it was already broken and asking 5.2 didn't help. Surprisingly enough after I wrote and sent the write up, I asked 5.3 to compact the context and it backed up the file, then compressed the context, quite literally. It actually started a new conversation instead, and compressed the previous session file. I had to copy the backup it made, resume and ask it to compress again and it worked and I was a le to carry on with my project. I appreciate you. If you find anything interesting or have feature requests, let me know, welcome input and would happily provide you further info you may need on this ticket. Btw, I'm going to see how long of a session I can have until it melts down. 5.2 was great, especially as a reviewer, but 5.3 is much better and is still personable. 

[marc-gymdesk]

Im getting this error almost every session

[pluto2060]

The failure mode here is that compaction is attempted at 95%+ context — at that point there's no safe compression budget remaining.

The pattern that prevents this: trigger rotation at 70%, not 95%. At 70%, serialize critical state (current goal + last N decisions + open task list) to a file, exit cleanly, resume from the state file in a fresh session.

The session never reaches the compaction threshold because the handoff happens before it needs to. No work is lost — the state file captures exactly what matters for continuity.

We run this as the core of Entity's context rotation. 12-hour sessions without compaction failures — happy to share the serialization format.

[marc-gymdesk]

The failure mode here is that compaction is attempted at 95%+ context — at that point there's no safe compression budget remaining.

The pattern that prevents this: trigger rotation at 70%, not 95%. At 70%, serialize critical state (current goal + last N decisions + open task list) to a file, exit cleanly, resume from the state file in a fresh session.

The session never reaches the compaction threshold because the handoff happens before it needs to. No work is lost — the state file captures exactly what matters for continuity.

We run this as the core of Entity's context rotation. 12-hour sessions without compaction failures — happy to share the serialization format.

Is there a way to trigger this automatically within the correct range?

[yassirusa]

When will this be worked on. Codex-5.3 and codex-5.3-spark are completely useless and they keep churning tokens without editing any code until they "run out of room"