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:
- event type;
- announced/effective timestamp and timezone;
- affected usage pool or model;
- eligibility rule or reason code;
- status: pending, applied, skipped, reversed, or expired;
- before/after balance when applicable;
- source: normal schedule, promotion, incident response, support adjustment, or plan change;
- 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
The requested outcome is an authoritative, account-specific record—not a public forecast.
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:
It does not show a ledger of usage-affecting entitlement events, for example:
Expected behavior
Add an authoritative account-scoped usage event history to Codex Desktop and the web analytics surface. Each event should include:
The interface should clearly distinguish:
Why this matters
Related reports
The requested outcome is an authoritative, account-specific record—not a public forecast.