No transparent per-feature usage/billing breakdown — quota drains with no attributable local or server-side record

Summary

The core problem isn't just background consumption (Chronicle, desktop-app background jobs, etc.) — it's that there is no transparent, per-feature billing/usage breakdown for Codex quota at all. When quota drains unexpectedly, there is no reliable way for a user to answer "what exactly consumed this?"

What I observed

While investigating background quota drain (see #30639), I checked my local usage logs with ccusage — a tool that parses Codex's own local session logs into a usage report.

• ccusage codex showed no "Exec" entries at all for the period in question.
• Despite that, my plan limits were fully drained.

So the drain is not just poorly attributed in the product UI — it doesn't even show up as a billable/loggable local event that a usage-analysis tool can reconstruct. This is a silent billing skip: quota is consumed without a corresponding, inspectable record of what consumed it, whether client-side or in whatever server-side accounting feeds the Analytics/limits UI.

Why this matters more than any single background-job bug

Root-causing and fixing individual background features (Chronicle, desktop-app suggestions, subagent overhead, etc. — see the many linked reports below) doesn't solve the underlying issue: users have no way to independently verify or audit what their quota is being spent on. Every one of these reports required manual forensic work (grepping local memory/session files, comparing before/after screenshots of Analytics) because there is no built-in, trustworthy usage ledger.

Ask

1. A per-feature/per-surface usage breakdown (Chronicle, Exec, desktop suggestions, subagents, CLI, app-server, etc.) that reconciles with the quota meter shown to the user.
2. Every quota-consuming event — including background/passive ones — should produce a corresponding local and/or server-side record, so tools like ccusage (and the user) can audit it.
3. Ideally, a documented mapping between local session logs and the billed/limits-consuming events, so discrepancies (like the one above, where limits drained with zero matching local "Exec" activity) can actually be diagnosed instead of guessed at.

Related reports

This overlaps with the broader "abnormal quota depletion" pattern being tracked in #41220, and specifically with:

• #30639 — Chronicle background screen-recording summaries draining limits (where this transparency gap was first noticed)
• #27773, #36805, #37983, #40386, #33685 — Chronicle-specific variants
• #28985 — Account-wide Codex usage attribution by client, session, and timestamp
• #33433 — Codex Desktop: opt-in usage attribution by project and task
• #34066 — Weekly limit exhausted right after purchase; usage attribution unclear
• #29272, #28083, #29783, #27898 — requests for token usage breakdowns in various surfaces
• #35166 — Stop Hiding Weekly Usage: ChatGPT Work drains quota without warning
• #38600 — Request: transparency and investigation into rapid quota depletion

Environment

• Codex Desktop (macOS)
• Local usage inspected via ccusage codex

Start with the ccusage codex report and the Codex Desktop usage behavior described in the issue, then trace how quota-consuming events relate to the limits and Analytics meter. Done would require an agreed per-feature breakdown, auditable records for background and passive events, and documented reconciliation between local logs and billed usage.