auto compaction - expose compaction to agent

Open 💬 5 comments Opened May 8, 2026 by Szpadel

What variant of Codex are you using?

cli

What feature would you like to see?

Problem description

During goal runs, a new iteration is often started when most of the context window is already filled. The agent then proceeds to read additional files anyway, triggering compaction during the process. This can waste the work done in that iteration, because the agent may effectively have to start over after compaction.

Proposition 1

The simplest solution would be to check available context before starting the next goal slice and trigger compaction when context usage exceeds a configured threshold.

Ideally, this threshold should be configurable, including an option equivalent to “always compact before starting a new slice.”

When a goal is paused or finished, this action should not be attempted automatically, because the user may want to continue iterating on the knowledge already accumulated in the current context.

Proposition 2

This is not exclusive with the previous option, but it is definitely more complex and may require model training for optimal behavior.

Assuming the agent is not currently aware of its own context usage, the system could provide hints after the model crosses configured context-usage marks. For example:

context left: plenty
context left: moderate
context left: low
context left: critical

The agent could also be given a special tool call to trigger compaction, with safeguards such as requiring some minimum context usage before the tool is available.

This would be a more powerful version of Proposition 1, allowing the agent to decide when compaction is appropriate based on its current progress. I would expect the agent to trigger compaction early after reaching an implementation milestone, rather than waiting until the context is almost full.

Proposition 3 (bonus one)

This is an extension of Proposition 2 and would likely require significant RL or other training.

Consider partial compaction, where the agent can decide which parts of the context should be preserved as-is and which parts are no longer needed.

For example, the agent could decide to drop outdated file reads from the context while keeping the latest versions. It could also choose to preserve specific reasoning, summarize other reasoning, or discard irrelevant intermediate steps.

This would require a sophisticated API for the agent and would likely need to be performed server-side. I am deliberately leaving this as a vague idea for consideration.

Summary

I believe Proposition 1 is the easiest to implement and would have the largest immediate impact.

The remaining suggestions could be used as experiment ideas. If such experiments are performed, I would be very interested in any follow-up, even in a heavily redacted or limited form, if anything can be shared. I would be happy to know whether the idea was useful in practice.

Additional information

_No response_

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗