Feature: token burn-rate 'speedometer' per session and overall (rate, not just remaining quota)

What variant of Codex are you using?

Codex CLI, Codex desktop app, and the IDE extension (this applies to all of them, most useful in the app / anywhere multiple sessions are visible at once)

What feature would you like to see?

A burn-rate "speedometer" showing how fast tokens / quota are being consumed, overall and per session.

Codex shows how much of the 5-hour and weekly limit is left, which is the fuel gauge. What is missing is any indication of what is burning that quota right now, or how fast. With several sessions running in parallel, the only way to guess which one is expensive is to look for the session with the most subagents active, and that is a poor proxy: one session with a huge context and a long tool loop can out-burn three sessions with subagents.

The painful failure mode is walking away for an hour and coming back to find the weekly quota fried because one session nobody was watching was redlining the whole time. Issues like #45085, #42010 and #39699 show how fast that can happen. There is no signal that would have flagged it in progress, and afterwards there is no way to tell which session did it.

Proposal:

1. Overall gauge: current aggregate burn rate across all active sessions, next to the existing remaining-quota indicator.
2. Per-session gauge or sparkline: in the session list / sidebar / status bar, so the hottest session is visually obvious at a glance.

Design notes:

• Smooth the rate over a trailing window of roughly the last 10 minutes so the gauge does not flicker with every turn. A sparkline over the same window also shows trend.
• Show a unit that answers "should I be worried?": tokens/min is fine, but "% of 5h limit per hour" or "time to empty at current rate" is better.
• Green / amber / red thresholds relative to a sustainable rate, i.e. the rate at which quota would run out exactly at the reset boundary.
• Include subagent and background task spend in the parent session's rate, since that is where the surprise usually comes from.
• Optional: a notification when any session stays in the red band for more than N minutes, or when projected time-to-empty drops below the time to the next reset.

Additional information

The mental model is a car dashboard. Remaining quota is the fuel gauge. What is missing is the tachometer and a "miles to empty" estimate, so the driver can see they are redlining before the tank is dry. Per-session attribution is what makes it actionable: knowing the account is burning fast without knowing where still leaves the user guessing.

Concrete example: four sessions open, two doing focused edits, one running a QA loop with subagents, one forgotten browser-automation loop with a near-full context. Go to lunch. Today: come back to 4% weekly quota and no idea which session did it. With this feature: the forgotten session's gauge has been pinned in the red for 40 minutes, the overall gauge shows time-to-empty under an hour, and a notification would have prompted killing it before eating.

A lighter-weight alternative that would still help: expose per-session token counts with timestamps in a machine-readable form (status JSON, a hook event, or a local endpoint) so third-party tools can compute the rate.

The request applies across the Codex CLI, desktop app, and IDE extension, with the existing remaining-quota indicator as the starting point. First map how active sessions, subagents, background tasks, and quota data are exposed; assess the proposed status JSON, hook event, or local endpoint alternative. Done means a decided design for aggregate and per-session burn rate, smoothing, thresholds, and any notification behavior.