Codex usage panel needs an authoritative reset and entitlement event history

Feature request / transparency gap

Codex users currently see the account-specific scheduled reset timestamp in the Usage/Analytics panel, but there is no authoritative in-product history or event feed for other usage-affecting changes such as promotional resets, incident-related restoration, temporary multipliers, plan entitlement changes, or a reset that was announced but has not yet been applied.

As a result, users may learn about possible reset events through social posts, video comments, community threads, or third-party forecasting sites. That creates avoidable confusion about whether an account was eligible, whether a reset actually occurred, and whether the displayed balance is current.

This request does not allege selective or manually targeted resets. It asks Codex to make its own account-level usage events authoritative and inspectable.

Current behavior

The Usage panel can show values such as:

• weekly usage remaining;
• a scheduled weekly reset date/time;
• model-specific remaining usage;
• purchased credits.

It does not show a ledger of usage-affecting entitlement events, for example:

• scheduled reset due;
• special reset announced;
• eligibility evaluated;
• reset applied or skipped;
• allowance multiplier changed;
• model-specific pool changed;
• incident-related credit/restoration decision;
• plan or account entitlement changed;
• timestamp and source for each event.

Expected behavior

Add an authoritative account-scoped usage event history to Codex Desktop and the web analytics surface. Each event should include:

1. event type;
2. announced/effective timestamp and timezone;
3. affected usage pool or model;
4. eligibility rule or reason code;
5. status: pending, applied, skipped, reversed, or expired;
6. before/after balance when applicable;
7. source: normal schedule, promotion, incident response, support adjustment, or plan change;
8. a stable event identifier that support can reference.

The interface should clearly distinguish:

• the normal recurring reset;
• a possible or announced special reset;
• a reset actually applied to this account;
• purchased credits;
• model-specific pools;
• forecast/community speculation, which should never be needed to interpret the account state.

Why this matters

• Users should not have to monitor individual employees' social accounts or third-party forecast sites for usage-critical information.
• A visible event history makes support and usage disputes much easier to diagnose.
• It prevents normal account differences from looking like favoritism or silent entitlement changes.
• It gives users a reliable answer when an expected reset does not appear.

Related reports

• #27435 — reset date/time display can become ambiguous
• #32791 — expected usage pools disappeared or changed
• #28908 — usage changed without corresponding activity
• #35038 — active incidents are not surfaced inside the running Codex work session

The requested outcome is an authoritative, account-specific record—not a public forecast.