Conversation Compaction Telemetry / Context Health

[ANTVirGEO]

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

[github-actions]

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

• Make /compact summaries visible and support prompt-guided compaction in Codex CLI #21468
• auto compaction in goal / expose compaction to agent #21777
• Add TUI usage status line items for context and token usage #21324
• Expose Codex SDK context window usage, matching CLI "Context XX% used" #21295

Powered by Codex Action

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

[hoteye]

One practical compromise may be to keep compaction mostly transparent in the normal UI, but expose structured health state in /status and debug logs. In long-running agent workflows, users may not need to manage compaction directly, but they do need enough signal to distinguish “model is stuck”, “tool loop is running”, and “context maintenance is happening”.

In AgentHub I’m treating this as task/runtime observability rather than a prominent UI feature: lightweight counters, last maintenance time, degraded/fallback reasons, and provider/model used for background maintenance. That kind of low-noise status surface might preserve the goal of transparency while still improving issue reports and long-session trust.