Repository navigation
[Windows][Plus] GPT-6 Luna Max quota burn spike with unusually frequent auto-review/guardian calls #49572
Description
Activity
Update: I tested again with auto-review completely disabled.
Configuration for both new sessions:
- model:
gpt-6-luna - reasoning effort:
max approval_policy = "never"approvals_reviewer = "user"- Codex runtime:
0.159.2
No
guardianorauto_reviewactivity appears in either rollout.I then ran two GPT-6 Luna Max tasks in parallel.
Task 1:
- duration: 38.9 minutes
- 62 model calls
- 9,058,137 input tokens
- 8,780,288 cached input tokens
Task 2:
- duration: 42.0 minutes
- 105 model calls
- 14,241,603 input tokens
- 13,733,632 cached input tokens
Combined:
- 23,299,740 input tokens
- 22,513,920 cached input tokens
- 96.63% cache ratio
- 167 model calls
- ~287,736 input tokens per active task-minute
During this test, the shared 5-hour usage meter increased from 41% to 47% (+6 percentage points).
This is important because disabling
auto_reviewremoved the previously observed Guardian overhead, but the unusually high quota consumption remained.The actual Luna workload also does not appear unusually intensive compared with my Sep 29 baseline. In fact, the new runs averaged ~287.7k input tokens per active task-minute, versus ~334.5k combined input tokens per active task-minute in the Sep 29 baseline.
So the new A/B test suggests that excessive Guardian activity was a separate issue, but does not explain the main increase in quota consumption.
This makes me suspect that either:
- quota weighting/accounting for GPT-6 Luna changed,
- cached input is being accounted for differently,
- there is additional server-side usage not represented in the local rollout,
- or another metering change/regression occurred.
New session IDs:
01a0f244-63c2-7a22-bd01-c9ca9adaed2401a0f248-8910-7ce2-b564-1e557c065798
Both sessions independently report the same account-global 5-hour meter progression from 41% to 47%; this is one shared +6% increase, not 6% per session.
- model:
I can independently reproduce a closely related failure mode on Windows with ChatGPT Plus / Codex.
My observation is especially useful as an A/B comparison:
- I was using GPT-5.6 Luna normally.
- My 5-hour allowance appeared to become exhausted unusually quickly (roughly within ~20 minutes of a task in the affected period; I was not intentionally running parallel tasks).
- With "Approve for me" / auto-review enabled, Luna then reported that I had no usable allowance / could not continue.
- I changed the permission mode to a fully open configuration that no longer required the automatic reviewer path.
- After doing that, Luna could continue working again, even though I had just been told that my allowance was exhausted.
This makes me suspect that the auto-review / guardian path is incorrectly coupled to the main Codex quota state, or that reviewer activity is affecting effective quota consumption/accounting in a way that is not visible to the user.
I do not want to overstate the root cause: local reviewer token counts alone do not prove that reviewer tokens are directly billed against the 5-hour allowance. However, the A/B behavior above is reproducible enough that disabling/bypassing auto-review changes whether Luna can continue after the apparent quota exhaustion.
This also appears inconsistent with the documented expectation that automatic review safety checks should not consume the user's normal plan usage allowance.
I am now using a local token monitor to preserve and inspect the affected Codex session telemetry. I can provide sanitized per-session evidence (main-model calls, auto-review calls, input/cached/output token counts, timestamps, and quota-meter changes) if useful.
Please check whether:
- auto-review/guardian requests are accidentally charged or weighted against the shared 5-hour allowance;
- an exhausted main/reviewer quota is incorrectly blocking Luna even when Luna reserve capacity remains available;
- switching away from auto-review bypasses an incorrect quota gate.
The strongest reproducible symptom on my side is:
Auto-review enabled -> Luna says no quota / cannot continue.
Auto-review bypassed with fully open permissions -> Luna can continue.This seems highly related to the reviewer-frequency/quota anomaly described in this issue.
In-app diagnostic feedback has now been submitted for this reproduction.
Feedback ID / parent session:
01a0c771-53ab-71b1-8ee4-645b8fc891deRelated identifiers:
- Auto-review thread:
01a11f44-3766-7cb0-aaef-87091795915f - Failed turn:
01a11f53-d110-7162-be59-54fdd530646f - Failure timestamp:
2026-10-09 14:22:31 UTC+8 - ChatGPT Desktop version:
26.1002.7124.0
The in-app feedback was submitted with ChatGPT diagnostic logs attached. The affected auto-review rollout recorded
model=codex-auto-review,approvals_reviewer=auto_review,approval_policy=never, thenlimit_id=premium,credits.balance=0, followed byusage_limit_exceeded. Switching permissions manually from Approve for me to Full access immediately allowed Luna Reserve work to continue.- Auto-review thread:
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.21956
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
I am seeing a sudden increase in effective Codex quota consumption while using GPT-6 Luna at Max reasoning on ChatGPT Plus.
On September 30, I started two long-running GPT-6 Luna Max tasks in parallel at approximately 08:34 UTC. The server-reported 5-hour usage was approximately 0% shortly after they started and reached 8% at 09:31:54 UTC, roughly 57 minutes later.
The important part is that the local rollout telemetry shows a substantial change in agent/reviewer activity compared with GPT-6 Luna Max turns from the previous day.
By the 8% point on Sep 30:
Main GPT-6 Luna:
codex-auto-review / guardian:
Combined:
This does NOT look like a simple prompt-cache failure: cache hit rate remained very high.
I also compared this with seven completed Sep 29 turns in the same two parent threads where the rollout explicitly records
model: gpt-6-lunaandreasoning_effort: max.Sep 29 baseline:
Sep 30 affected window:
So the affected window processed about 1.41x more combined input per active task-minute while the frequency of guardian calls relative to main-model calls increased by about 3.76x.
The behavior became especially noticeable after the bundled runtime changed to 0.159.2.
During the first ~20.18 minutes of one resumed task on 0.159.2:
Main GPT-6 Luna:
codex-auto-review:
That is 57 separate reviewer model calls alongside only 68 main-model calls in about 20 minutes.
One individual reviewer call at the time the 5-hour meter reached 8% consumed 89,511 input tokens (87,808 cached) simply to approve a routine read-only local command.
I cannot determine from local telemetry whether:
Please correlate the session IDs below with backend quota accounting.
What steps can reproduce the bug?
I do not yet have a minimal deterministic reproduction, but I reproduced the high burn behavior across two concurrent long-running local tasks and it continued after updating/restarting Codex.
Observed setup:
.codex/sessions.Affected parent thread IDs:
Example 0.159.0 guardian session:
Example 0.159.2 guardian session:
In my case the server-reported 5-hour usage moved from approximately 0% to 8% in ~57 minutes.
During the 0.159.2 portion, I observed 57 auto-review model calls alongside 68 main Luna calls in approximately 20 minutes.
What is the expected behavior?
GPT-6 Luna Max should not unexpectedly generate a large increase in hidden quota-consuming reviewer traffic for an otherwise normal local workflow.
Routine low-risk/read-only local operations should not result in a separate large-context auto-review model call at nearly the same frequency as main-model calls unless that behavior is actually necessary.
If auto-review/guardian calls consume the user's shared 5-hour or weekly allowance, that consumption should also be visible and attributable in the UI.
At minimum, quota consumption for an unchanged model/workflow should remain reasonably explainable from locally recorded model activity rather than suddenly increasing because of opaque internal reviewer traffic.
Additional information
Runtime information recovered from local rollouts:
At 2026-09-30T09:31:54.103Z:
Example auto-review at that point:
The reviewed operation was a routine read-only inspection of local disassembly.
I am intentionally not attaching the complete rollout files publicly because they contain unrelated private project source, prompts, local paths, command output, system instructions, and account identifiers.
I attached sanitized telemetry excerpts and an aggregate comparison. I can provide complete original rollout JSONL files privately to OpenAI if required.
Related reports, but not exact duplicates:
The notable difference in this report is the quantitative increase in GPT-6 Luna Max reviewer frequency around the 0.159.x update, including 57 auto-review calls for 68 main-model calls during a ~20-minute 0.159.2 segment.
codex_luna_usage_anomaly_evidence.zip
codex_luna_usage_anomaly_evidence.zip