Repository navigation
Conversation Compaction Telemetry / Context Health #22220
Description
What variant of Codex are you using?
App
What feature would you like to see?
Feature Request: Conversation Compaction Telemetry / Context Health
Problem
Long Codex sessions currently provide almost no visibility into context compaction behavior.
Users cannot easily determine:
- how many compactions already happened in the current conversation
- whether context quality may already be degraded
- when the last compaction occurred
- whether Codex is entering a compaction loop
- how aggressively the runtime is compacting relative to remaining context
This creates several UX and reliability problems already visible across multiple issues:
- repeated compaction loops
- progressive loss of reasoning continuity
- silent degradation of long-running agentic sessions
- inability to diagnose token amplification behavior
- confusion between freezes vs active auto-compaction
After several compactions, session quality can noticeably degrade due to summarization loss and recursive compression effects, but the user currently has no telemetry to understand that state.
Proposed Solution
Expose lightweight compaction telemetry directly in the UI and/or /status.
Suggested fields:
Compactions: 4
Last compact: 12m ago
Current context used: 82%
Estimated context integrity: Medium
Possible additional telemetry:
- average interval between compactions
- compact trigger threshold
- auto-compaction mode
- warning when compaction frequency accelerates
- warning after N compactions in same session
- "possible compaction loop detected"
Why This Matters
Codex is increasingly used for:
- long-running coding sessions
- large repository analysis
- agentic workflows
- multi-hour debugging sessions
In these scenarios, context management becomes part of system observability.
Right now, users can observe symptoms of degradation, but not the actual internal state transitions causing it.
Even a simple visible counter would significantly improve:
- debuggability
- user trust
- workflow planning
- issue reporting quality
- understanding of model behavior
Related Issues
- Auto-Compaction Indicator at start of turn #9773 Auto-Compaction Indicator at start of turn
- Extend compaction prompt to reduce loss over multiple compactions #14347 Extend compaction prompt to reduce loss over multiple compactions
- Control over auto-compaction parameters #4106 Control over auto-compaction parameters
- codex just compacts repeatedly for hours at a time before it is able to make a change #14120 repeated compact loops
- Context compaction regression in CLI v0.118 — 2x more frequent compactions cause token usage explosion #16812 excessive compaction regression
Possible Minimal MVP
Even just this would already help substantially:
text Compactions this session: 3
shown either:
- in /status
- in session metadata
- or near the context percentage indicator
Additional information
No response
Activity
github-actions commentedon May 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon May 11, 2026
We're working on an update to our compaction mechanism — incorporating a bunch of reliability and efficacy improvements. Our long-term goal is to make compaction transparent to users so it's not something they need to invest mental energy in monitoring. We would like to see if we can get close enough to that ideal with our updated compaction mechanism before we invest in UI like you're suggesting here. I'm cautiously optimistic that such a UI will not be needed.
Keesan12 commentedon May 18, 2026
A compaction counter would help, but the really useful step is to treat compaction as observable runtime state rather than an invisible maintenance act. I would love to see compactions_this_session, last_compaction_at, compaction_trigger, and some warning when compaction frequency is accelerating. Once you can see that, users can finally separate 'the model is getting worse' from 'the session has been recursively compressed five times.' We have been tracking the same distinction in MartinLoop because long-run quality and cost both depend on it.
bazik210 commentedon May 21, 2026
"it's not something they need to invest mental energy in monitoring... I'm cautiously optimistic that such a UI will not be needed."
Ye, right, without context ui it will eat lot's of tokens and users even won't know that when it will exceed model limits (like with gpt-5.4 with big context window), and ofc seems openai want the users to pay more, also auto-compact result to huge tokens loss and for openai better user don't know when this will happen, it's all about money as always.
Keesan12 commentedon May 21, 2026
I think that compromise is the right shape: keep compaction mostly invisible in the main UI, but surface a small structured health record somewhere operators can inspect when quality/cost suddenly shifts. The minimum useful fields for me would be: compactions_this_session, last_compaction_at, compaction_trigger, provider_or_model_used, and a degraded/fallback reason when maintenance had to take a lower-confidence path. That preserves the low-noise UX goal without leaving long-running sessions completely opaque when people are trying to debug drift or cost spikes.
adam-aggrow commentedon May 21, 2026
This is a bit hand-wavy. "Transparent" or "invisible"? Hopefully by "transparent" you mean you intend to shed more light on what's happening with the context rather than concealing it. It's far too important in relation to the health of the model/session and if anything we need more visibility.
NN1985 commentedon May 21, 2026
@etraut-openai > We're working on an update to our compaction mechanism — incorporating a bunch of reliability and efficacy improvements. Our long-term goal is to make compaction transparent to users so it's not something they need to invest mental energy in monitoring. We would like to see if we can get close enough to that ideal with our updated compaction mechanism before we invest in UI like you're suggesting here. I'm cautiously optimistic that such a UI will not be needed.
What I'm reading here is that you intentionally removed a visual indicator (the context usage meter that disappear from the recent update) that was actively useful in our daily workflows, one that directly informed both model performance (context rot) and our ability to manage spend per response, on the basis that you're working toward a solution that MIGHT or SHOULD eventually make it unnecessary.
That's bad UX. You removed user control before delivering the improvement that would justify its removal. The correct sequence IMO is ship the better compaction, confirm it actually eliminates the need, then sunset the indicator. What happened here is that you took away the steering wheel because you're optimistic the car will eventually drive itself.
Until you're confident (not cautiously optimistic but confident) that you've solved transparent context management, users need visibility into where they stand. That indicator let us know when to start a new thread, when to compact, and when we were burning tokens unnecessarily. It was lightweight, glanceable, and genuinely useful. All you've done is just blindfold us while the underlying problem remains unsolved.
Just giving candid direct feedback, not an attack.
NN1985 commentedon May 21, 2026
It's THE single most important thing we have that directly impacts model performance (context rot) AND controls how much we spend per response. Taking away that indicator is super, super hostile before you haven't "solved" the underlying problem. Please revert this change. I expect things kind of force change from the team at Mountain View or Anthropic, but NOT Codex.
Keesan12 commentedon May 21, 2026
One low-noise compromise would be to make compaction health a thresholded status record instead of a permanently loud meter.
Something like:
health = healthy | degraded | criticalcompactions_this_sessionlast_compaction_atlast_compaction_triggerdegraded_reasonrecommend_new_thread = true|falseThen normal sessions stay quiet, but once compaction cadence or fallback quality crosses a threshold, the operator gets an explicit receipt that explains why quality/cost may drift. That keeps the UI mostly clean without forcing people to guess whether they are seeing model weakness or aggressive maintenance.
Keesan12 commentedon May 22, 2026
The /status surface gets a lot more useful if it carries both cadence and decision context: current health bucket, trigger, degraded reason, and whether the model recommends a fresh thread or safe continuation. Without that, people see motion but not the actual continuation policy.
NN1985 commentedon May 23, 2026
The current solution for context health visibility relies on a side panel that doesn't work for all workflows. It disappears on narrow windows and is unusable for users running vertical/portrait monitor setups.
Propose adding the context indicator to the top bar shown here, rather than requiring a click or hover on the info tooltip seen, toggled via a preference to be always visible regardless of window size or sidebar state. This keeps it out of the bottom composer area, as the team intends, while providing passive, always-visible context awareness for users who need it.
@etraut-openai
Keesan12 commentedon May 25, 2026
This is the sort of telemetry that could turn compaction from a black box into an operator tool. I’d want a compact health state, the trigger that caused it, and a start a new thread recommendation when the session is degraded. That makes it much easier to decide when to keep going versus deliberately reset.
NN1985 commentedon May 25, 2026
@Keesan12 Agreed, but unfortunately after the recent "donutgate" scandal over at #23794, OpenAI purposely hid the only info we already had about context health, and they openly stated the reason: they wanted to establish a narrative that Codex has the appearance of "infinite context," and since indicators about context health remind people that it does not in fact have infinite context, the indicator was purposely removed in order to not remind people of that reality (framed as positive by them as removing a mental burden or thing a user needs to track), despite hurting user control and insight.
So unfortunately, given their view on this issue, it seems highly unlikely OpenAI will adopt this proposal.
rebroad commentedon May 28, 2026
but some people like to invest mental energy into monitoring things! And most of these people are software developers ;)
NightGlowww commentedon Jun 8, 2026
I’d like to add a UX-focused request here: when Codex is automatically compacting context, the UI should show an observable progress state instead of leaving the user waiting with a vague status.
In Codex Desktop, I recently hit a case where the UI showed “Automatically compacting context” for several minutes, then the turn was interrupted and I had to press Continue. From the user side, it is very hard to tell whether Codex is still actively compacting, waiting on a server response, retrying, stalled, or safe to stop.
A low-noise solution would be enough:
The goal is not to force users to monitor context all the time. It is to avoid the unsafe feeling of waiting blindly during a long-running maintenance operation, especially when work may be in progress and users need to decide whether to stop, continue, or fork the thread.
Stache73 commentedon Jun 14, 2026
I would like to add one specific requirement to this telemetry request: the context/usage telemetry should be available to the Codex agent/model itself, not only to the human-facing UI.
Concrete use case:
180k / 258k tokens used.Requested behaviour:
context_window_tokenscontext_used_tokenscontext_used_percentcompactions_this_sessionlast_compaction_atrecommend_new_threador equivalent health signalWhy this matters:
Power users can set workflow rules such as “recommend handoff around 50% context usage”, but the assistant cannot follow that rule reliably unless it can read the same context telemetry the user sees. Making the telemetry model-visible would reduce misleading estimates, improve long-session handoffs, and make Codex more trustworthy during large debugging or implementation sessions.
Necmttn commentedon Jun 21, 2026
Even if compaction stays quiet in the main UI, it should leave a durable health record for diagnostics.
Minimum fields:
compact_id, source turn range, summary revision/model, token and byte deltas, trigger, status, degraded reason, and whether a fresh thread is recommended. This can live in/status, logs, or an export before it becomes visible UI. That gives bug reports a way to distinguish improved compaction from silent repeated maintenance.Generated with ax.
sandynz commentedon Jun 25, 2026
I hit the same UX issue during automatic context compaction.
The most confusing part is that when compaction starts, the CLI can appear stuck for a while with no visible status. A small immediate message such as “Compacting context...” would already help distinguish expected
maintenance work from a hang or network issue.
For my use case, a full telemetry panel is nice to have, but the highest-impact fix would be a clear start-of-compaction indicator.
grtninja commentedon Jul 24, 2026
Concrete Windows/Desktop example of why a visible compaction counter and health state are necessary.
A July 23 long-running
/goalscreenshot shows a dense sequence of repeatedContext automatically compactedevents—many of them separated by only one generic command row—before the session reaches the usage limit. The same screen shows the goal paused after about 5d 10h, still at Step 1/8, with 373 subagents done and 5 shown as working.The UI provides no cumulative count, average interval, pre/post occupancy, reclaimed tokens, summary size, retained tool-state size, or warning that compaction frequency has become pathological. The user must manually count event rows and cannot tell whether each compaction made meaningful headroom.
For diagnostic usefulness, the minimal telemetry should include:
The measurable post-compaction ~80% case is separately tracked in #35032; the broader parent/step/subagent state inconsistency is #35052.