Repository navigation
Codex Luna quota consumption appears ~4–5x higher than Aug 31 under the same model and max reasoning effort #45867
Description
I am seeing a very large regression/change in Codex quota consumption for GPT-5.6 Luna.
This does not appear to be explained by task complexity, a switch to Astra, or reasoning effort alone. I compared local rollout JSONL telemetry from Aug 31, Sep 15, and Sep 16.
Environment:
- Plan: Plus
- Model: gpt-5.6-luna
- Reasoning effort: max
- Codex context window: 258,400
- Workloads: repository inspection, implementation/review, documentation alignment, tool calls
- Most input tokens are cached context in both the old and new samples.
Aug 31 baseline:
I have three Luna Max rollout files from Aug 31.
Combined raw input across those three files:
- ~62.86M input tokens
- ~61.40M cached input tokens
- ~97.7% of input was cached
One relatively clean Aug 31 Luna Max sample went from:
- 5h quota used: 45% -> 77%
- raw input: ~0.024M -> 27.001M
That is approximately:
~843K raw input tokens per 1% of 5h quota
This is actually a lower bound because the quota header is account-wide and other Codex activity was also occurring during that interval.
My desktop usage counter for Aug 31 showed approximately 324M tokens for the day, and I was still able to work normally without the kind of quota exhaustion I see now.
Sep 15 / Sep 16 behavior:
With the same gpt-5.6-luna model at max reasoning effort, I am now observing roughly:
~200K–270K raw input tokens per 1% of 5h quota
On Sep 16, a Luna Max documentation/repository alignment session produced approximately:
- 24.35M total input tokens
- 23.45M cached input tokens
- 902K non-cached input tokens
- 71K output tokens
The Codex UI showed approximately 973K tokens, which corresponds almost exactly to:
non-cached input + output
The UI therefore did not expose the ~23.45M cached input being repeatedly processed.
During the relevant part of this Sep 16 session, the 5h quota moved approximately:
27% -> 82%
The effective rate was about:
~202K raw input tokens per 1% of 5h quota
Compared with the Aug 31 Luna Max sample (~843K/1%), this is at least a ~4.2x reduction in effective quota throughput for the same model and reasoning effort.
The Sep 15 Luna Max samples already showed the same ~200K–270K/1% behavior, so this does not appear to be a one-off Sep 16 anomaly.
Additional observations:
-
Cached-context replay dominates the traffic.
In the Sep 16 session, ~96–97% of the model input was cached input. Many tool-loop responses repeatedly sent ~100K+ context. -
Quota accounting appears asynchronous.
I observed cases where the 5h used percentage increased even though the recorded total token count had not increased between adjacent telemetry records.I also saw a jump from 5% to 27% after an idle period, on a response containing only ~30K input tokens, which strongly suggests delayed quota posting/accounting.
-
This was not caused by an Astra worker.
The Sep 16 main thread remained gpt-5.6-luna at max reasoning effort. There was an automatic guardian/review thread, but its traffic was far too small to explain the observed quota change. -
Reasoning effort does affect cost, but does not explain the longitudinal regression.
On Sep 15, Luna Medium subagents appeared substantially cheaper (~0.8M–1.2M raw input/1%), while Luna Max was ~0.2M–0.27M/1%.
However, Aug 31 Luna Max itself was already capable of ~0.84M raw input/1% or better. Therefore the Aug -> Sep change cannot be explained simply by Max reasoning being expensive.
Please investigate whether there has been a change or regression in:
- subscription quota weighting for cached input;
- Luna Max quota multipliers;
- server-side rate-limit/accounting logic;
- delayed quota reconciliation;
- cached-context replay accounting;
- or the relationship between the UI token counter and actual quota consumption.
If the quota weighting was intentionally changed, please document it clearly. The practical difference is large enough to change whether a Plus/Pro subscription is viable for sustained Codex development work.
A sanitized JSONL log information in CSV format is attached for evidence review.
codex-quota-telemetry-summary.csv
Possibly related: #43811
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
solo-race commentedon Sep 16, 2026
The use was primarily in the Codex CLI, with only sparse usage in Windows Desktop. I'm keeping the issue since it directly compares normal behavior ~2 weeks ago to the abnormal consumption yesterday/today, backed by sanitized local telemetry data to demonstrate the point.
It has become practically impossible to plan for weekly usage and development work/whether renewing subscription is viable or not, especially considering that nowhere in the product UI or in OpenAI announcements do I see any mention of the abnormal quota consumption rate. This could simply mean I will no longer consider resubscribing after my current subscription expires if this abnormal behavior persists, and the situation remains entirely opaque from official announcements or fix.
solo-race commentedon Sep 16, 2026
After the abovementioned telemetry collection, no codex session was activated while the 5-hr quota has not yet been consumed fully. However, the 5-hr quota dropped directly to zero after I try to initiate another session. This goes to prove my point in the issue and goes to show that quota counting is clearly abnormal at the moment.
IRaccoonI commentedon Sep 17, 2026
same, 5.6-sol
AlexSAsin commentedon Sep 17, 2026
Same here. I hit my limits in just two days on the 5.6-sol, whereas it usually took a week.
dmitrymakhonin commentedon Sep 17, 2026
The same, so sad(
pfujezd-hue commentedon Sep 20, 2026
Same here, 5hour drained in 20 minutes by 5 messages long microsite task, week limits drained in two days without using Astra. Both plus (personal) and business (company) accounts. Unusable
Kahore commentedon Sep 22, 2026
Same here, but for gpt-6.
51 seconds of work in medium effort drained 17% of 5h quota