Repository navigation
Codex Desktop usage accounting mismatch: 36,318-token Luna request followed by ~6% 5-hour depletion and ~2.95M daily tokens #48919
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.909.12148
What subscription do you have?
ChatGPT Plus
What platform is your computer?
"$([Environment]::OSVersion.VersionString) $(if ([Environment]::Is64BitOperatingSystem) { 'x64' } else { 'x86' })"
What issue are you seeing?
Summary
Codex Desktop appears to have a serious discrepancy between locally recorded provider token usage and the Work/Codex usage reported by the backend/UI.
I reproduced this in a fresh, controlled Codex session immediately after my 5-hour allowance had reset.
A single GPT-6 Luna Medium request containing only ok produced exactly 36,318 total tokens according to the local rollout (36,303 input + 15 output), with no tools, sub-agents, compaction, or cached input.
Immediately after the request completed, the rollout's server-provided rate-limit snapshot still reported 0.0% used for the 5-hour limit.
Several minutes later, however, the Codex Usage UI showed approximately 6% of the 5-hour allowance consumed, and the Usage page reported approximately 2.95M Work/Codex tokens used today.
I did not make any additional Work/Codex requests during the interval in which the usage continued to decrease. I only used regular Chat.
The magnitude of the backend-reported usage cannot be reconciled with the provider usage visible in the local rollout.
Environment
Codex Desktop on Windows
Codex App version:
26.909.12148
Codex runtime / CLI version recorded in rollout:
0.158.0-alpha.2.1
Subscription:
ChatGPT Plus
Model used for the controlled reproduction:
GPT-6 Luna
Reasoning effort:
Medium
Thread ID:
01a0e6cd-3705-7da3-b879-878b97bc0473
Turn ID:
01a0e6cd-4bdd-7dd2-a3ff-7303135a8347
Response ID:
resp_0dba845ce246abf5016aba0fba639087d2af72c99a2c962e2b
Controlled reproduction
-
Waited for the 5-hour Work/Codex allowance to reset to 100% remaining.
-
Created a brand-new Codex Desktop session in a new empty test directory.
-
Used GPT-6 Luna with Medium reasoning.
-
Sent only:
ok -
Codex replied:
好的，我在。你想接着处理什么？ -
The turn completed normally.
-
No tool calls, shell commands, sub-agents, Guardian/auto-review calls, or compaction occurred.
-
I then observed the Work/Codex usage page without sending another Work/Codex request.
Exact local provider usage
The rollout contains one token_usage_record for this turn:
{
"input_tokens": 36303,
"cached_input_tokens": 0,
"cache_write_input_tokens": 0,
"output_tokens": 15,
"reasoning_output_tokens": 0,
"total_tokens": 36318
}
### What steps can reproduce the bug?
Feedback ID: 01a0e6cd-3705-7da3-b879-878b97bc0473
### What is the expected behavior?
For a fresh session with one GPT-6 Luna Medium provider request, I expect the Work/Codex usage history and 5-hour quota consumption to be reasonably reconcilable with the provider usage recorded for that session, or for any additional billable/background activity to be identifiable.
### Additional information
Request for investigation
Could you please inspect the server-side usage ledger and request history associated with the Thread ID, Turn ID, and Response ID above?
In particular, please check whether:
- additional hidden/background model requests were generated but not written to the local rollout;
- an interrupted turn was retried or continued server-side;
- usage was counted more than once;
- cached/context tokens or system-generated activity were attributed incorrectly;
- the 5-hour and weekly quota aggregation was delayed or incorrectly reconciled;
- or the Usage UI is attributing tokens from another source to this Work/Codex account.
I am specifically trying to understand where the approximately 2.95M reported tokens came from.
If the backend usage is correct, it would be very useful to identify the corresponding requests because they are not visible in the local provider-level telemetry I can inspect.
I can provide the relevant sanitized rollout JSONL files and Usage screenshots if needed.
Activity
github-actions commentedon Sep 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Charonlzw commentedon Sep 28, 2026
Thanks for the duplicate suggestion. I reviewed #48595, but I don't believe this is the same issue.
#48595 reports approximately 2–4% usage per short message while using GPT-6 Astra X-High.
My reproduction is specifically with GPT-6 Luna / Medium, and I had explicitly selected Luna for the controlled tests.
The clean reproduction in this issue was:
okImmediately after that request completed, the local rollout's server-provided rate-limit snapshot still showed:
However, several minutes later, the 5-hour allowance had decreased by approximately 6%, while I had made no additional Work/Codex requests.
There was also an earlier, separate GPT-6 Luna / Medium session on the same day where I sent only
1and stopped the response after about 8 seconds. That Luna-only interaction was followed by approximately 9–10% 5-hour allowance consumption.Most importantly, the Work/Codex Usage page later reported approximately 2.95M tokens used for the day, while the controlled Luna session above has only 36,318 locally recorded provider tokens, and I cannot reconcile the backend-reported token total with the locally visible activity.
So the key issue here is not simply that a short message consumes some quota. The issue is the apparent server/client usage-accounting discrepancy for GPT-6 Luna, including a much larger backend token count than the provider usage recorded in the local rollout.
I did later use GPT-6 Astra for a separate Computer Use request, but that occurred after the Luna reproduction described in this issue and is intentionally excluded from the reported measurements.
For that reason, I believe #48919 should remain separate from #48595 unless both are confirmed to have the same underlying accounting bug.
roy-tong commentedon Oct 5, 2026
The controlled reproduction here is the right shape, and the rollout file you kept is the evidence that matters. One thing worth making explicit: the rollout and the Usage page are two different meters. The rollout records provider-side token accounting per request; the Usage page aggregates server-side under "Work/Codex" with an undocumented basis and window. Your numbers show they disagree by two orders of magnitude, which means at least one of them is counting something the other does not see.
Two checks that would localize it:
For what it is worth from our side: in 53 public Codex rollout sessions (1,313 token_count events) we have never seen the provider-side usage disagree with the rollout records themselves. The opaque part is exactly the backend aggregation this issue is about. The snapshot field's window and basis are undocumented in the rollout format; documenting them would make issues like this checkable instead of anecdotal.
We keep a public analyzer for rollout topology (re-emission, dedup, cumulative semantics) at github.com/roy-tong/AgentMeasure if useful for cross-checking the local side.
D4ttara commentedon Oct 7, 2026
Related product-level concern from #51805: when a previously working Chat execution workflow is forcibly routed into Work, usage accounting becomes part of the migration contract, not a secondary UI detail.
OpenAI's current docs state that Work/Codex share a metered allowance and may continue via credits/resets after limits. If the reported backend usage cannot be reconciled with visible provider activity, users cannot make an informed decision about whether to accept a forced Work migration.
Docs:
https://help.openai.com/en/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex
https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usage-in-chatgpt-personal-plans
Cross-link: #51805
D4ttara commentedon Oct 8, 2026
Follow-up to my earlier cross-link: our Oct 8 control tests accessed a local MCP tool directly from ordinary Chat without any Work/Codex handoff, unlike the Oct 7 failure. This is a routing observation only, not a new usage-accounting measurement. It matters because an unpredictable move to a separately metered surface makes reliable usage information even more important. Details: #51805 (comment)