Problem
In Codex desktop, automatic context compaction can block the user-visible turn for a long time. In one recent session, the UI showed:
Context compactedWorked for 1m 17s
During that period, the user cannot distinguish useful agent work from context maintenance, so the compact step feels like a visible stall.
Proposal
Could Codex reduce perceived latency by preparing compaction before it becomes blocking, or by doing it in the background?
Possible approaches:
- Start preemptive/incremental compaction once the conversation crosses a soft threshold, before the hard context limit is reached.
- Maintain a background compacted checkpoint while normal interaction continues.
- Run compaction while the session is idle or after a discrete task phase completes.
- If compaction must block, show progress that makes it clear the delay is context maintenance rather than task execution.
Why this matters
A one-minute-plus compact step is noticeable enough to interrupt the development flow. Even if total compute time is unchanged, moving part of the work off the critical path would make Codex feel much more responsive.
Environment
- Product: Codex desktop app
- Observed compact duration: 1m 17s
- Date observed: 2026-04-25
Problem
In Codex desktop, automatic context compaction can block the user-visible turn for a long time. In one recent session, the UI showed:
Context compactedWorked for 1m 17sDuring that period, the user cannot distinguish useful agent work from context maintenance, so the compact step feels like a visible stall.
Proposal
Could Codex reduce perceived latency by preparing compaction before it becomes blocking, or by doing it in the background?
Possible approaches:
Why this matters
A one-minute-plus compact step is noticeable enough to interrupt the development flow. Even if total compute time is unchanged, moving part of the work off the critical path would make Codex feel much more responsive.
Environment