Hi, everyone.
Evidence is increasingly pointing to the fact that the Codex Pro x5 (and possibly x20) weekly allowance has dropped by ~30–33% in recent weeks — measured from local rollout logs, not vibes. I encourage you to check out the analysis below.
I initially thought I was imagining this. However, after finding more than a few similar opinions on this topic (including within this Community):
For previous months, I could use Codex noticeably more on a Prolite (x5) plan account, and the weekly allowance behaved reasonably and consistently. Recently, however, (roughly since the beginning of August), my weekly limit started disappearing dramatically faster - even though I deliberately moved most of the workload to GPT-5.6 Terra, which is substantially cheaper than Sol - as much as 60% less per token! So instead of guessing, I audited my local Codex rollout history, and the result is concerning…
I reconstructed several historical Codex weekly windows from local rollout-*.jsonl files and compared the amount of locally recorded model workload required for the backend to report 100% weekly usage. The comparison uses the exact same normalization function and the same published Codex rate card for every historical window. I am NOT comparing raw token counts between models.
I normalize:
- uncached input
- cached input
- output
using the same model-specific rates for every period. I also use cumulative ‘total_token_usage’ deltas instead of summing ‘last_token_usage’, so duplicated ‘token_count’ snapshots are not counted repeatedly.
Historical weekly windows may appear under “secondary”, while newer weekly windows appear under “primary”; both are identified by the 10080-minute weekly window.
For 100% windows, accounting stops at the first observed used_percent = 100.
Here are the clean results:
| Period | Account | Backend usage | Normalized workload at limit |
|---|---|---|---|
| Jun 11–16 | Pro x5 account A | 100% | 14,381 |
| Jun 30 – Jul 5 | Pro x5 account B | 99% | ~15,024 implied |
| Jul 12–14 | Pro x5 account B | 100% | 14,202 |
| Aug 13–17 | Pro x5 account B | 100% | 13,514 |
| Aug 20–22 | Pro x5 account B | 100% | 9,613 |
All of these sessions report the same Codex plan type: Prolite the older clean Pro x5 windows cluster around roughly 14–15k normalized credit-equivalent workload. The current weekly window reached 100% at only: 9,613 (!). Compared with the historical clean median of approximately: 14,381, that is about a 33% reduction in effective observed weekly capacity. Even compared only with the immediately previous weekly window on the SAME account: 13,514 → 9,613
that is approximately 28.9% less normalized workload before reaching 100%.
The model mix does not explain this. The current weekly workload was:
- GPT-5.6 Terra: 87.4% of tokens
- GPT-5.6 Sol: 12.5%
- GPT-5.6 Luna: 0.08%
After normalization:
- Terra accounted for ~69.8% of the weighted workload
- Sol accounted for ~30.2%
So yes, Sol requests were relatively expensive, but that cost is already included in the comparison. The entire point of the normalization is that an August week with a high Terra volume can be compared against an older Sol-heavy week using the same cost function. For example:
- Jul 12–14 was essentially 100% GPT-5.6 Sol and reached 100% around 14,202 normalized units.
- Aug 20–22 was overwhelmingly GPT-5.6 Terra and reached 100% around 9,613 normalized units.
This is not simply “Terra used more tokens”. The current week actually processed approximately 1.19 billion aggregate token traffic before reaching 100%, because most input was cached and Terra is cheaper.
So the question is: Why did the backend weekly percentage reach 100% after dramatically less normalized workload?
I am NOT claiming that this proves OpenAI secretly reduced Pro x5 limits by exactly 33%, although it is tempting…
There are several possible explanations:
- the underlying weekly allowance was reduced
- model-specific weekly metering multipliers changed
- the backend is charging additional activity that is not represented in local ‘total_token_usage’
- there is a quota/accounting bug
- some other Codex metering rule changed
However, something measurable changed. The strongest evidence is that multiple earlier weekly windows, across two separate Pro x5 accounts, cluster around the same ~14–15k normalized threshold, while the newest window stops at ~9.6k. This is not based on how the progress bar “felt”. It is reconstructed from thousands of local Codex ‘token_count’ records and backend-reported weekly ‘used_percent’
My current weekly window:
- started: Aug 20, ~08:30 CEST
- reached 100%: Aug 22, ~17:12 CEST
- normalized workload before 100%: ~9,613
I would really like OpenAI to clarify:
- Did the effective Codex weekly allowance for Pro x5 / prolite change in August?
- If not, what changed in the metering formula that causes ‘used_percent’ to reach 100% after ~30–33% less normalized workload than historical windows?
If other Pro users have local Codex rollout history (and you definitely do), especially from June/July and August, I strongly encourage you to compare your own 10080-minute weekly windows. This should be reproducible. If you don’t know how to do this, please let me know in this thread. I’ll explain how it’s done. Best regards.