Compact large idle sessions before prompt cache expiry

What variant of Codex are you using?

CLI

What feature would you like to see?

Problem

Long-running Codex CLI sessions can accumulate a very large context and then sit idle for several hours.

For example:

1. I start a long-running task before going to bed.
2. Codex finishes the task at 4 AM with ~300k tokens of context.
3. The CLI remains open, but the session is idle.
4. I return at 9 AM and send a small follow-up message.
5. If the previous prompt cache is no longer reusable, that follow-up may require processing the large session context again.

There is a window between the task finishing and the prompt cache becoming cold where Codex could potentially compact the session more efficiently.

Proposal

Add an optional idle compaction mode for large sessions.

After a turn or task has completed, if the session remains idle and its context is above a configurable threshold, Codex could automatically compact it before the existing prompt cache is expected to expire.

Conceptually:

if no task is running
and session is idle
and context > threshold
and cached prefix is approaching expiry:
    compact session

The intent is not to compact more aggressively during normal interactive use. It is specifically to take advantage of an idle period to prepare a large session for a later resume.

If Codex knows or can estimate the relevant cache lifetime internally, I think that would be preferable to requiring users to configure a fixed timer.

A possible opt-in configuration could look something like:

[compaction]
compact_on_idle = true
min_context_tokens = 100000

Codex could then choose when during the idle period to perform the compaction.

Expected behavior

Using the overnight example:

1. A long-running task finishes with a large context.
2. The session becomes idle.
3. Before the existing cached prefix is likely to become cold, Codex compacts the session.
4. The compacted state replaces the large active history.
5. When the user returns several hours later, the next turn starts from the smaller compacted context rather than the full pre-compaction history.

This should only happen while the CLI/session is still running. I am not proposing that Codex start a background process after the CLI has exited.

Why this helps

Current automatic compaction is primarily driven by context pressure.

For unattended or overnight sessions, context pressure may not be the best trigger. The session may already contain hundreds of thousands of tokens but receive no new input for hours.

In that situation, waiting until the user sends the next message can be the least useful time to discover that the large prefix is no longer cached.

Idle compaction would move that work into the period where the user is not waiting and where the existing session context may still benefit from cache reuse.

Related issues

• #27008 discusses the same general problem of expensive long-session resumes, but proposes persistent inference state / KV-cache capsules. This proposal is intentionally narrower: use the existing compaction mechanism before an idle session's cache becomes cold.
• #29967 proposes speculative/background compaction before the normal context-pressure threshold. That proposal is driven by context utilization during active sessions; this proposal is driven by session idleness and resume cost.
• #18007 proposes asynchronous/background compaction to avoid interruptions during active use. This proposal instead targets sessions that have stopped doing work and may remain untouched for hours.

Additional information

I think this would be most useful as an opt-in feature initially, with safeguards such as:

• do not compact while a turn or tool call is active
• require a minimum context size
• reset/cancel the idle trigger if the user resumes interacting
• compact at most once during an idle period
• preserve the existing behavior when the option is disabled