Pro weekly quota meter accelerated ~2.4x mid-window, then returned to normal (Aug 14)

Summary

On a ChatGPT Pro account, the same 7-day codex quota bucket suddenly consumed weekly allowance at roughly 2.4x the adjacent observed rate during a bounded period on 2026-08-14, without a plan, bucket, reset timestamp, or service-tier change.

The abnormal interval ended later that day, but the quota percentage was not restored.

Environment

• Plan reported by Codex: pro
• Codex CLI: 0.145.0
• Platform: Linux x86_64
• Rate-limit bucket: limit_id=codex
• Window: 10080 minutes
• resets_at=1787196676 (2026-08-20 03:31:16 UTC)
• Service tier: default; no Fast-mode traffic in the measured slices
• Reset credits available: 0
• Usage was distributed across a main Linux host and a second Linux host. A third workstation was also checked and cannot account for the discrepancy.

All figures below were reconstructed from local Codex JSONL token_count events. Prompt and response text was not used or uploaded.

Observed phases

Times are UTC. API-equivalent values use one consistent set of OpenAI's published standard text-token rates. They are a comparison metric, not a claim about the undisclosed subscription quota formula.

The account therefore moved from $19.54 of comparable API-equivalent activity per percentage point to $8.11/pp, then returned to $18–$22.55/pp. The quota bucket and reset timestamp remained the same throughout.

Model mix in the abnormal interval

The expensive-model mix explains why this interval should consume more allowance than a Luna-only interval. It does not explain the abrupt change relative to the immediately adjacent periods: at the preceding observed ratio, $186.54 corresponds to about 9.5 percentage points, not 23. Even using the lowest previously observed ratio for this account ($16.42/pp), the interval corresponds to about 11.4 points. This leaves approximately 11–14 percentage points not explained by the complete local token journals.

Ruled out

• No plan change (pro throughout).
• No bucket change (codex, 10080-minute window throughout).
• No weekly reset during the anomaly; resets_at remained effectively identical.
• No secondary quota bucket replacing the weekly bucket.
• No banked reset or reset-credit redemption.
• Activity on the second host and workstation was checked; it does not account for the gap.
• The meter returned to its previous range later without a client/config change.

Expected behavior

For the same account, rate-limit bucket, service tier, and published model price basis, weekly quota accounting should not change by roughly 2.4x for several hours without an explicit entitlement or pricing change.

Request

Please investigate this account's weekly Codex quota accounting between 2026-08-14 08:12 and 17:08 UTC.

Specifically:

1. Did the effective weekly capacity or model weighting change server-side during this interval?
2. Was any non-token usage source charged to the same bucket but omitted from Codex token_count journals?
3. If the 11–14 percentage-point gap was erroneous, can the affected allowance be restored?
4. Can the product expose the calculation inputs that advance used_percent, so users can distinguish intended model weighting from an accounting defect?

The issue names no repository file, test, or entry point; start by reviewing the local Codex JSONL token_count events and comparing them with the weekly meter for 2026-08-14 08:12–17:08 UTC. Done means determining whether server-side accounting or an omitted usage source explains the gap, and documenting whether allowance restoration or calculation visibility is possible.