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

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.