[Bug] Orca Codex is not showing the reset time for the limits correctly.

[orca-discord-issues]

yorgun via Discord

I have experienced this issue many times. It may show that there are 6 days remaining until the limits reset, but sometimes they reset after 2 days, and other times they reset the very next day. Because of this, I cannot accurately determine when my limits will actually reset. Please fix this issue so that the correct limit reset time is displayed.

[orca-discord-issues]

yorgun via Discord

<@1230924083454152794>

[orca-discord-issues]

Jinjing via Discord

checking it out

[orca-discord-issues]

Jinjing via Discord

<@587321027986456589> it might also be OpenAI sometimes gives additional resets in celerbation of their milestones, e.g. yesterday they just did a reset for everyone for their 10M users

[orca-discord-issues]

yorgun via Discord

hmm do you know if gpt removed the 5 hour reset limit and switched to only a weekly limit?

[orca-discord-issues]

Hadelich via Discord

they temporarily removed the 5h limit

[innocarpe]

Quick triage (2026-07-23)

I dug into this before picking it up as a community fix. Current picture:

Symptoms vs likely cause

The report (“UI says ~6 days, but limits sometimes come back in 2 days / next day”) matches upstream Codex/OpenAI changing or accelerating resets more than a pure clock-formatting bug:

• Discord thread on this issue notes temporary 5h limit removal and one-off milestone resets that Orca cannot predict from a single cached resetsAt.
• Orca shows whatever the last usage snapshot reported (resetsAt / resetDescription from backend, app-server RPC, or Codex /status PTY parse). If OpenAI resets early, the stored timestamp can look “wrong” until the next refresh.

Related open work (not this issue)

• fix(rate-limits): keep Codex PTY reset text for weekly-only plans #8643 — keep Codex PTY reset text when only a weekly window exists (weekly-only plans dropping Resets in …). Different symptom (missing text), same area.
• fix(status-bar): show live session reset countdown in collapsed usage bar (#5399) #9374 (merged) — live session reset countdown in collapsed usage bar.

Suggested product fixes (if maintainers want a code change)

1. Always refresh usage when the countdown hits 0 / when a rate-limit error returns earlier than resetsAt.
2. Surface “as of <fetch time>” or re-fetch affordance so early OpenAI resets don’t look like a stuck clock.
3. Prefer absolute resetsAt over free-text resetDescription when both exist and diverge.

I am not opening a fix PR from this alone — without a reproducible parse mismatch (screenshot of Orca UI vs Codex /status / ChatGPT settings at the same moment) it’s hard to prove an Orca bug vs upstream schedule changes. Happy to implement (1)/(2) if that’s the desired product direction.

[orca-discord-issues]

yorgun via Discord

sometimes this happens it shows that I still have some usage limit remaining even though I've actually used up all of it for ex when my remaining limit is at 0% it suddenly jumps to 15% then goes back to 0% and later shows 15% again It seems to be a visual ui bug with the usage limit tracker

[nwparker]

Reproduction status: cannot_repro (code path looks correct; no wrong-timestamp evidence on this machine)

What we checked

• UI countdown uses formatResetDuration / formatResetCountdown from src/shared/rate-limit-reset-format.ts (floor to whole minutes/hours/days from resetsAt - now).
• Codex backend mapper converts Unix seconds → ms (raw.resetsAt * 1000) in src/main/rate-limits/codex-fetcher.ts.
• Status-bar chip prefers remaining time when resetsAt is known (formatRateLimitWindowChipLabel).

No local Codex account / live rate-limit payload was available to show a mismatched “6 days remaining” vs actual next-day reset. Without a captured API sample (resetsAt, windowMinutes, resetDescription) at the moment the UI looks wrong, we cannot prove a display bug vs upstream limit metadata changing.

Need for next attempt

1. Screenshot of UI claiming N days remaining.
2. Same-moment resetsAt (epoch ms) from status bar IPC / logs.
3. Whether the window is session vs weekly vs credits.

If resetsAt from API already encodes the wrong day, fix is upstream/parser; if resetsAt is right and UI string wrong, fix is formatter.