Conversation Compaction Telemetry / Context Health

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #21468
• #21777
• #21324
• #21295

Powered by Codex Action

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.

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.

"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.

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.

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.

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.

@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.

> 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. 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.

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.

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 | critical
• compactions_this_session
• last_compaction_at
• last_compaction_trigger
• degraded_reason
• recommend_new_thread = true|false

Then 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.

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.

<img width="1358" height="115" alt="Image" src="https://github.com/user-attachments/assets/c1081f79-9b7d-42f1-8422-53fa34f03288" />

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

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.

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.

@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.

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.

but some people like to invest mental energy into monitoring things! And most of these people are software developers ;)

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:

• show a progress indicator or phased status such as “preparing context”, “uploading/packing”, “compacting”, “resuming turn”
• show elapsed time and last progress update
• show a warning after a threshold, e.g. “This is taking longer than expected”
• make Stop/Cancel semantics clear during compaction
• optionally recommend “start a new thread” when the session is degraded or compaction has failed repeatedly

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.

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:

• The UI may show something like 180k / 258k tokens used.
• The assistant currently cannot access that value directly.
• Without direct telemetry, the assistant may try to estimate from visible text or character counts, which is unreliable because it cannot access the raw full transcript, hidden tool state, compacted summaries, injected context, or the UI meter.
• This leads to bad guidance in long sessions, such as telling users the context is still below a handoff threshold when the actual UI meter is already around 70%.

Requested behaviour:

• Expose read-only current context-window usage to the agent/session runtime, for example:
• context_window_tokens
• context_used_tokens
• context_used_percent
• compactions_this_session
• last_compaction_at
• recommend_new_thread or equivalent health signal
• The model should be able to use this value when advising the user whether to continue, compact, or start a fresh thread.
• This should be clearly separated from billing/quota usage. The request is about active context-window pressure and session health, not account usage accounting.

Why 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.

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._

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.