Add history message compression to prevent context overflow

[fannnzhang]

Description

Currently, Codex maintains the full history of messages without any compression or summarization mechanism. This can cause problems in long-running tasks:

• The accumulated conversation history may exceed the maximum context length of the underlying large language model.
• Once the context window is exceeded, older parts of the history are dropped, which can lead to loss of important information.
• This often results in failed executions or unexpected outputs, as the model no longer has access to the full task context.

Proposed Solution

Introduce a history compression mechanism, such as:

• Summarizing older messages into a shorter form while preserving key details.
• Allowing configurable strategies (e.g., summarization, truncation, or selective retention).
• Providing hooks for custom compression strategies, so developers can tailor it to their use case.

Benefit

This feature would make Codex more reliable for handling long-running tasks and ensure better alignment with the model’s context limitations, improving both stability and predictability.

Are you interested in implementing this feature?

Yes, I am interested in working on this feature. However, I believe message history compression can be a complex task. It may be best to start with a basic version first, and then gradually improve it.

Additional information

N/A

[AdsQnn]

I always had the impression that this is what /compact is for :)

[fannnzhang]

。。 of course not. I wasn't referring to the /compact command. What I'm talking about is a functionality that actively compresses the historical messages. In scenarios where a long task is running, it could generate a lot of continuous output, leading to an unnecessarily long history of messages. In such cases, do you think the /compact feature could help?

Of course, the ideal solution would be if the CLI tool automatically handles this, just like Roo code does. By automatically managing and compressing historical messages, it makes the tool much more powerful compared to the original CLI tools

[AdsQnn]

I completely agree with you on this one :) However, when reading your comment, I got the impression that you were saying Codex doesn’t have any kind of compression or summarization mechanism at all.

I think something like an /autocompact feature could really help — it would effectively increase the limits, improve performance and quality, and prevent situations where files are repeatedly loaded earlier in the context. Right now, I sometimes get the feeling that the model is duplicating content in its responses because of that.

It would be great if the /autocompact threshold could be configurable. For example, with the API, there’s a common issue where the context grows beyond TPM limits — being able to automatically adapt the context to fit within specific constraints would make a big difference.

It’s just that for this to work, you only need:

input_size ≥ config_autocompact

and then, under the hood, call the same method that /compact uses.
That should make it work as an initial implementation.
The input has a practically real-time value.

Maybe you have an idea for a more sophisticated mechanism? :)

But I think there's already a PR with that change, and it will be finished soon.

[fannnzhang]

ea225df yea i can see that pr has been merged into codebase

[waldoalvarez00]

+1, Claude Code does this autocompact when close to the context limit. It is very useful because you can get close to the context limit in the middle of a task. CC launches autocompact and resumes the task with the new smaller context. Codex fails miserably hitting a limit against the APIs. You have to live with a sharp eye to run compact if you are lucky and the task lets you do it.