Expose authoritative account-specific Codex quota reset events and rollout notices in-product

Feature request

Codex users need an authoritative, account-specific in-product history and notification channel for usage resets, temporary quota changes, model-specific limits, and rollout-related usage events.

Today, the analytics surface can show a future reset timestamp, but it does not provide a durable event history explaining:

• when the last reset actually occurred;
• which usage windows or models were reset;
• whether an announced or expected reset applied to this account;
• whether a reset was delayed, cancelled, partial, or replaced by credits;
• whether a product rollout or incident changed usage accounting;
• where the authoritative announcement is located.

In practice, broader expectations about Codex resets or product changes can circulate through employee social posts, YouTube comments, and third-party forecasting sites before affected users see anything in the product. That creates avoidable information asymmetry and makes an account-specific outcome look arbitrary even when there may be a legitimate plan/window distinction.

This request does not allege selective or preferential resets. It asks OpenAI to remove the ambiguity with first-party telemetry.

Requested UI

Add an account-visible Usage events section containing:

• last successful reset timestamp;
• next scheduled reset timestamp;
• reset cadence/window identifier;
• affected products/models (Codex and Work, model-specific pools, credits, etc.);
• percentage/balance immediately before and after the event;
• event reason: scheduled, promotional, incident remediation, plan change, manual adjustment, or other documented class;
• official announcement/reference ID when applicable;
• timezone and server time used for the event;
• a clear distinction between account-specific schedule and broad platform announcements.

Notifications

When OpenAI announces a reset, temporary increase, or quota-related rollout:

• show an in-product notification to eligible accounts;
• state eligibility and affected pools explicitly;
• state when the event completed for the account;
• show a clear not applicable status rather than silence for ineligible accounts;
• preserve the notice in a durable history rather than relying on social media.

Why this matters

Without first-party event history, users cannot distinguish among:

• a normal account-specific reset schedule;
• a delayed or failed reset;
• a model-specific reset that did not affect the weekly pool;
• an incident-related adjustment;
• an inaccurate third-party forecast.

That uncertainty is especially damaging when usage is already near exhaustion or when the service is experiencing a public incident.

Environment observed

• Codex and Work analytics on ChatGPT Pro
• Windows 11
• Separate weekly and model-specific remaining balances were visible
• A precise future reset timestamp was visible, but no historical reset/announcement ledger was available

Related concerns

• #35032 — compaction/reprocessing usage waste
• #35037 — active incident not surfaced inside the running Codex session

Those are separate defects. This issue is specifically about authoritative reset and quota-event communication.