›_ Codex Issues
Codex Issues / #32827

Codex Desktop misattributes GPT-5.6 usage to GPT-5.4 and updates weekly quota with large delays

Open 💬 3 comments Opened Jul 13, 2026 by NathanDrake2406
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop appears to have two related usage-accounting problems:

  1. The usage dashboard attributes substantial activity to gpt-5.4, while the corresponding local rollout metadata identifies the sessions as GPT-5.6 models.
  2. The seven-day usage meter updates with large delays after heavy work, making it impossible to determine which thread or model consumed the allowance.

This creates the appearance of unauthorized account activity and makes the usage dashboard difficult to trust.

Environment

  • macOS 26.5.2
  • Codex Desktop
  • Codex runtime version: 0.144.2
  • ChatGPT-authenticated paid plan
  • Local rate-limit telemetry reports plan_type: prolite
  • Seven-day window: 10080 minutes

Incorrect model attribution

On July 12, 2026, the Codex usage dashboard tooltip reported:

| Dashboard model | Reported usage |
|---|---:|
| gpt-5.4 | 2,004 |
| gpt-5.6-sol | 52 |
| gpt-5.4-mini | 17 |
| gpt-5.6-luna | 1 |

update: over 4000 turns of GPT 5.4 yesterday which I haven't touched since April.

<img width="578" height="344" alt="Image" src="https://github.com/user-attachments/assets/d22de215-4dbc-4002-9239-062e5eb29dd5" />

A read-only scan of the corresponding local rollout files found:

  • 39 local Codex session files for July 12
  • 33 were subagent sessions
  • all local turn_context.model values for that date were gpt-5.6-sol
  • no local session with "model":"gpt-5.4" existed after June 16

If GPT-5.6/Ultra internally routes worker activity through GPT-5.4, the UI should distinguish the user-selected model from the internally billed model. If it does not, the dashboard attribution appears incorrect.

Delayed seven-day quota updates

Local rate_limits.primary.used_percent telemetry showed the seven-day meter changing as follows (Australia/Sydney):

| Time | Used |
|---|---:|
| Jul 13, 2:34 pm | 9% |
| Jul 13, 7:11 pm | 30% |
| Jul 13, 8:42 pm | 43% |
| Jul 13, 9:19 pm | 47% |
| Jul 13, 11:42 pm | 57% |
| Jul 14, 12:18 am | 59% |
| Jul 14, 1:05 am | 62% |
| Jul 14, 1:49 am | 65% |

One major GPT-5.6 Luna/XHigh thread ran from approximately 7:11 pm to 8:48 pm. Its final local token totals were:

  • total tokens: 52,312,407
  • cached input tokens: 50,675,456
  • output tokens: 129,833
  • reasoning output tokens: 47,241

At completion, the account meter reported approximately 43% used. The account-level meter subsequently continued climbing to 65%.

The delayed movement makes per-thread attribution impossible: the value returned during task completion is not apparently final, and later requests surface large increases that may belong to earlier work.

Overnight 76% → 100% quota jump

I do not see evidence that the Mac was compromised, but I cannot rule out another signed-in OpenAI session.

The evidence is stark:

  • Last local Codex activity before sleep: approximately 4:25 am Sydney, with 76% used.
  • No local sessions or model activity for roughly 9½ hours.
  • No active remote tasks detected.
  • The only configured automation was paused.
  • When activity resumed at approximately 1:49 pm, the first refreshed quota response reported 100% used.

This strongly supports delayed server-side accounting—the same behaviour observed earlier—rather than the Mac secretly running overnight. Usage from another device or account session would also be absent from local records.

As a precaution, the account was secured by logging out all devices, changing the relevant password or SSO credentials, enabling MFA/passkey protection, reviewing API keys, reviewing organisation members/projects/service accounts, and re-authenticating Codex locally.

Current assessment:

  • Mac compromise: no supporting evidence.
  • Account-session compromise: possible, not demonstrated.
  • Delayed/incorrect quota accounting: currently the strongest explanation.

Steps to reproduce / inspect

  1. Use Codex Desktop with ChatGPT authentication.
  2. Select a GPT-5.6 model and run a long or multi-agent task.
  3. Inspect local rollout JSONL records:
  • session_meta
  • turn_context.model
  • event_msg.payload.info.total_token_usage
  • event_msg.payload.rate_limits.primary.used_percent
  1. Compare the local model identifiers and timestamps against the Codex usage dashboard model breakdown.
  2. Continue checking the seven-day meter after the major task completes.
  3. Observe that the dashboard model attribution may not match local turn_context.model, and that quota percentages can rise substantially later—even after many hours with no local activity.

Expected behavior

  • The dashboard should accurately identify the model whose usage is being reported.
  • If an internally routed worker model differs from the user-selected model, both should be shown explicitly.
  • Usage/quota telemetry should settle promptly after a task completes, or the UI should clearly label values as delayed/provisional.
  • Users should be able to determine which model, thread, and time interval consumed their allowance.
  • Cached-input and subagent weighting should be documented or exposed sufficiently to explain quota movement.

Impact

Users cannot reliably distinguish legitimate activity from unauthorized usage, cannot identify the task responsible for allowance depletion, and may make incorrect security decisions based on misleading model labels and delayed quota updates.

Related issues

  • #28908 — usage limit decreases without corresponding user activity
  • #28823 — usage meter consumes faster than comparable historical usage
  • #32503 — GPT-5.6 tool orchestration multiplying model turns and quota usage

Privacy note

Thread IDs, prompts, repository names, account identifiers, and local paths are intentionally omitted. The figures above come from read-only aggregation of local Codex rollout telemetry.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #31784
  • #31812

Powered by Codex Action

Mahkhmood9 · 1 month ago

Its not about 2x ratelimits, its about 4x times more users, and a lot of users --- far as I concern , I dont think openai can even train a new model as things stand now with the amount of usage

I personally can get anything I want to be done with older models

I honestly think , you should have a feature , to be prompted a cooldown --- like a popup after 60% of weekly limit -- to cooldown the model of the whole week - to reset your weekly limit but be limited to Terra or Luna --- clearly something with sol eating all of the compute --- removing the 5 hours limits is great , because people should get a truama from having it suddenly burn their weekly limit casuing them to be more vise with their tokens..... with the release of 5.6/sol I think OPENAI should have expected server usage to be decreased- but it hasnt decreased it increased (and not due to the fact its 3x as many users ) --- the biggest issue in data science in the world I think in the realm of LLMs , is to strifle and merging few Chats -- what if a user opened few chats on the topic?

but with the counter argument you dont see it anywhere on arena leaderleaders board --- so I have no data to back my claims ---
I think we should strifle for good enough for most caes --- without weaking the parts that makes us humans a bit better still -- not that its not a skill a human should learn, like to use AI or whatever

My excpecting were very high to 5.6 , and I was not disapointed at all , I think it would have been more healthy - to not announce it two weeks before the release..... But personally it certainlly different, its like talking to a different person , I like 5.6 a lot --- and I bet on the idea - that anything 5.5 has failed is 40% better at tasks it couldnt do, not 2x times as efficent ---

but I think the best way to do things is with joy of learning along the way -- while a lot of things not going to be precious it is importent -- that different products have their own touch and randomization --- and different strengths and features that got developed and refined , because building takes time (in the past) a lot of feature just happen to developed because you stuck with a computer screen

next I want to counter argue, I think the other case is the people are easily going to argue aginst the software being made---- because most developer they make something and they are so proud of what they made--- when 3 months later you understand how badly design what you did was , I call it "developer over pride syndrom"

I am not jealous of people who get to make the magic done, you need to make the unknown, using whats barely known today - even if you argue "we keep hitting the limits" with the limitation of hardware, and no as good 2x as efficent the Blackwell gpus are, it doesnt make a difference

small prompt I had 

I asked "how much better h200 between a100 is?"
ANSWER: Depending on your specific workload, the H200 delivers anywhere from 4× to over 9× the performance of an A100. For specific LLM inference tasks using advanced optimizations, it can reach up to 30× the throughput.

following prompt
i asked "how efficent your typical servers without a gpu are?"
ASNWER :Raw Power Consumption: The NumbersTo put it in perspective, a single top-tier NVIDIA H200 GPU server node can easily pull 5,000W to 6,000W+. A standard CPU-only server draws a fraction of that:  At Idle: A modern non-GPU server typically draws between 80W and 150W. It sits in a low-power state, waiting for API requests or user traffic.

so clearly you can pick most second hand servers of the last 10 years and not be too concern of being outdated

I think I like to end it with the idea of , a lot of talented developers understand compilers or what not, but very few people actually design CPUs and GPUs and the things that are between, and the way you compact things, but they actually understand how cpus work and its flaws, and can make amazing software to how they are being made

as things stands now, infrence has to improve 30x and not be too off, from what you would have used the gpus for infrence , tokens shall be of the same quality, so 5-35x improvement , on what a Blackwell server stack/rack give -- and models must get 4x cheaper --- I personally dont think good people with great talent use their talents if there is no limitation ,,, and its not an engine factory saving an nickle on a screw, other wise there is no mission driven ideas that come with nature of things
<img width="1240" height="620" alt="Image" src="https://github.com/user-attachments/assets/20f34fe2-a2e1-463d-93bc-17e2b14c9cc3" />

quantuan125 · 1 month ago

Additional Windows evidence captured on 2026-07-25 supports the delayed-reconciliation pattern described here. I opened #35294 with the full sanitized packet.

Environment:

  • Windows 11 Pro 64-bit, build 26200
  • Codex Desktop 26.721.4979.0
  • runtime 0.146.0-alpha.3.1
  • seven-day window: 10,080 minutes

Observed server snapshots (Asia/Bangkok, UTC+7):

| Event | Time | Used | Remaining |
|---|---|---:|---:|
| Last snapshot before inactivity | Jul 24 23:12:37 | 84% | 16% |
| User returned | Jul 25 11:29:32 | — | — |
| First refreshed snapshot | Jul 25 11:29:49 | 97% | 3% |

For the 12h17m gap, a read-only scan across all local rollouts found:

local token_count events: 0
new local session_meta events: 0
active automations: 0
local memories feature: false

Only after the user returned did the diagnostic session's cumulative total increase from 4,622,593 to 4,804,948 tokens (+182,355). Cached-input tokens remained unchanged at 4,403,456, while the first refreshed server response arrived 13 percentage points higher.

The desktop package had updated from 26.721.3996.0 to 26.721.4979.0, was installed around 10:57, and launched around 11:26. The 3%-remaining snapshot followed at 11:29. This is consistent with a restart exposing an account ledger that reconciled while the local runtime was inactive; it does not show that the update caused the charge.

Caveat: unified desktop history records three completed kind=chatgpt conversations during the interval, but local metadata does not identify ordinary Chat versus ChatGPT Work. Another device is also not visible locally. Those remain possible account-level sources.

The distinguishing evidence from #35259 is that this overnight interval contains no local model turns at all, rather than model re-entry during wait/status polling. Full report: #35294.