Codex usage limits desync between web Analytics and macOS app #23192

Summary

Codex is showing mutually incompatible usage-limit state for the same signed-in Plus account across the Codex web Analytics page and the Codex desktop/macOS app.

This is not just "the numbers look different." The two surfaces disagree simultaneously on:

• 5-hour remaining percentage
• 5-hour reset time
• weekly remaining percentage
• weekly reset date

The web Analytics page explicitly says Codex usage draws from the shared agentic usage limit, but the desktop app is presenting a different quota state for that same shared limit. Restarting the app, reinstalling, cache clearing, local cleanup, and an Onyx cache-cleaning attempt did not resolve the inconsistency.

This should be treated as a quota-state authority conflict / synchronization defect / stale-state propagation issue unless backend evidence proves otherwise.

Environment

• Account/plan shown in UI: Plus
• Web surface: ChatGPT/Codex Analytics page on chatgpt.com, Analytics -> Usage
• Desktop surface: Codex desktop/macOS app, Usage & billing
• Desktop app installed locally: 26.513.31313 (2867)
• macOS: 26.5 (25F71), Apple Silicon
• Observation time: May 17, 2026, approximately 21:28-21:36 WEST (Europe/Lisbon)
• Screenshot evidence captured from the affected account:
  • Desktop Usage & billing screenshot: CleanShot 2026-05-17 at 21.28.58@2x.png
  • Web Analytics screenshot: CleanShot 2026-05-17 at 21.29.56@2x.png
  • Desktop compact usage menu screenshot: CleanShot 2026-05-17 at 21.36.30@2x.png
  • Later Web Analytics screenshot after the dashboard state changed: CleanShot 2026-05-17 at 22.41.05@2x.png

Screenshot evidence

Desktop Usage & billing shows 5 hour usage limit = 100% left, reset 2:28 AM, and Weekly usage limit = 62% left, reset May 19:

Web Analytics shows 5 hour usage limit = 87% remaining, reset May 18, 2026 12:54 AM, and Weekly usage limit = 85% remaining, reset May 24, 2026 1:16 AM:

Desktop compact usage menu later still shows the desktop-side state: 5h 100% with reset 2:36 AM, and weekly 62% with reset May 19:

Later the same web Analytics dashboard changed again. It now shows 5 hour usage limit = 100% remaining with no reset timestamp visible, and Weekly usage limit = 62% remaining, reset May 19, 2026 6:12 PM:

Authoritative failing behavior

Both surfaces are presenting the same product concept: included Codex usage limits for the same account. They should reconcile to one authoritative quota state, or the UI should clearly identify which surface is authoritative and why the other surface is stale or pending refresh.

Instead, the surfaces disagree on both quota windows at the same time:

Additional desktop evidence: the compact "Usage remaining" menu later showed 5h 100% with reset 2:36 AM, and weekly 62% with reset May 19, so the desktop surface remained on the conflicting 100% / 62% / May 19 state while the 5-hour reset display moved again.

Follow-up web evidence: after the original contradiction was captured, the web Analytics page itself changed from its earlier web state (87% 5-hour remaining / 85% weekly remaining / weekly reset May 24, 2026 1:16 AM) to a different state (100% 5-hour remaining / 62% weekly remaining / weekly reset May 19, 2026 6:12 PM). That later web state aligns with the desktop percentages, but not with the earlier web Analytics evidence. This does not resolve the bug; it shows that the supposed shared source-of-truth can mutate between incompatible quota states.

Credits are not the issue here: both web and desktop showed 0 credits. The contradiction is specifically in the included shared usage-limit state.

Reproduction evidence

1. Open ChatGPT/Codex web Analytics -> Usage for the account.
2. Observe the Balance cards:
   • 5 hour usage limit: 87% remaining
   • Resets May 18, 2026 12:54 AM
   • Weekly usage limit: 85% remaining
   • Resets May 24, 2026 1:16 AM
3. Open Codex desktop/macOS app -> Usage & billing for the same account.
4. Observe General usage limits:
   • 5 hour usage limit: 100% left
   • Resets 2:28 AM
   • Weekly usage limit: 62% left
   • Resets May 19
5. Restart/reinstall/cache-clear/local-cleanup/Onyx-clean the local app environment.
6. Observe that the cross-surface contradiction persists.

Why this is not explained by display formatting

• Timezone formatting alone does not explain it: the 5-hour reset differs by about 1h34m (12:54 AM vs 2:28 AM), and the weekly reset differs by five calendar days (May 24 vs May 19).
• Rounding alone does not explain it: the remaining values differ by 13 percentage points for the 5-hour window and 23 percentage points for the weekly window.
• A purely local desktop cache explanation is incomplete because restart, reinstall, cache clearing, local cleanup, and Onyx cache cleaning did not resolve it.

Evidence-backed hypotheses that fit the observed contradictions:

• The web Analytics page and desktop app are reading from different quota-state pipelines or backend calculations.
• The desktop app is receiving or persisting stale quota state that is not invalidated by normal local cleanup.
• The backend has more than one quota authority for the same shared agentic limit and the frontends are reconciling against different authorities. The later web Analytics mutation makes this stronger than a simple desktop-only stale-cache theory, because the web dashboard itself later adopted a different quota state.
• There may be separate handling for percentage calculation versus reset timestamp calculation, because both values diverge independently.

Related reports reviewed

I searched open and closed issues before filing, including these query families: analytics mismatch, usage limit mismatch, weekly usage incorrect, desktop app usage discrepancy, codex analytics inconsistency, reset time mismatch, limit remaining incorrect, app vs analytics mismatch, quota desync, stale quota cache, shared usage counter inconsistency, usage percentage mismatch, codex desktop incorrect usage, and analytics page wrong values.

Related but not duplicate:

• Codex weekly usage dropped from ~70% to ~7% at 5-hour reset boundary #23188 reports weekly usage dropping from about 70% to about 7% at a 5-hour reset boundary and explicitly frames this as a dashboard reconciliation/accounting problem. It overlaps with the reset-boundary and weekly quota mutation behavior, but it does not include the cross-surface web Analytics vs desktop contradiction or the later web-dashboard state flip documented here.
• usage limit codex app bug #22650 reports CLI/app blocking while /status and web usage show remaining allowance. It overlaps on quota authority mismatch, but it does not cover the web Analytics vs desktop app contradiction table, weekly reset-date conflict, and simultaneous 5-hour + weekly percentage conflict.
• "You've hit your usage limit." Despite 10% Rate Limit Usage Remaining #12299 reports "usage limit hit" despite remaining quota, with comments showing web/status disagreement. It overlaps on enforcement-vs-display state, but not this desktop settings vs web Analytics reset-date/reset-time/percentage conflict.
• CLI reports usage limit reached for Business team seat while usage dashboard says no Codex rate limits #16909 reports Business/Edu CLI enforcement contradicting a dashboard that says no Codex rate limits. It is adjacent account-entitlement/enforcement mismatch, not the same Plus web Analytics vs macOS app shared-limit desync.
• Codex Desktop open → 5-hour usage decreases after reset despite no active task, no CLI, and no credit-history event. #21966 reports the desktop app appearing to consume 5-hour usage while idle and possible Analytics attribution mismatch. It overlaps on desktop/app quota reporting, but not the same same-minute web-vs-desktop contradictory source-of-truth state.
• 5h limit changed reset time during usage and pushed it back ~2h #22133 reports 5-hour reset time drifting by about two hours. It overlaps on reset-time instability, but not weekly reset date or percentage disagreement between web and desktop.
• Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens #21216 reports weekly percentage jumps tied to denominator/plan-type changes. It overlaps on percentage calculation inconsistency, but not cross-surface state authority.
• Weekly limit reset date changed from Nov 3 to Nov 7th #5999 reports weekly reset-date movement. It overlaps on reset-date instability, but not this current web Analytics vs desktop app split.
• Showing "You’re out of Codex messages" either I have credits #19417 reports desktop "out of messages" / credit handling inconsistency. It overlaps on desktop usage-state correctness, but not this four-field shared-limit contradiction.

Post-filing search note: issues created after this report at the time of re-check (#23193-#23198) were reviewed and were Windows/session/connectivity/crash reports, not additional duplicates of this quota-state defect.

I do not see an existing issue that fully covers all of these at once:

• cross-surface contradiction
• 5-hour reset-time inconsistency
• weekly reset-date inconsistency
• 5-hour remaining-percentage inconsistency
• weekly remaining-percentage inconsistency
• persistence after restart/reinstall/cache clearing/local cleanup/Onyx cleanup

Expected behavior

Codex should have one authoritative shared usage-limit state for the account.

At minimum:

• Web Analytics and desktop app should show the same remaining percentages for the same quota windows.
• Web Analytics and desktop app should show the same reset timestamps/dates for the same quota windows.
• If one surface is cached, it should show last-updated state and refresh/failure status instead of presenting stale values as authoritative.
• If Analytics and desktop intentionally use separate quota pipelines, the UI should say which one controls enforcement.
• If a hidden quota, burst limit, or model-specific limiter is involved, it should be exposed separately rather than overloading the shared 5-hour/weekly usage UI.

Please clarify:

1. Which surface is authoritative for included Codex usage limits?
2. How is quota state synchronized between web Analytics and the desktop app?
3. Do Analytics and the desktop app use separate quota services or separate backend calculations?
4. Are percentage remaining and reset timestamps computed by the same authority?
5. What local or server-side invalidation should force the desktop app to reconcile with the web Analytics state?