/status shows stale cached token usage on first run after usage for ChatGPT Plus users
Open 💬 2 comments Opened May 24, 2026 by khodges42
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
codex-cli 0.133.0
What subscription do you have?
ChatGPT Plus
Which model were you using?
gpt-5.5
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What terminal emulator and version are you using (if applicable)?
VS Code
Codex doctor report
What issue are you seeing?
The first time /status is run, it reports an inaccurate 5h duration/percentage. When it is run again, it becomes more accurate.
What steps can reproduce the bug?
Check status, use codex, check status again, and once more. Compare the last two.
What is the expected behavior?
Expected to be accurate the first check.
Additional information
I would like to push a PR for this. I have a fix that works for me locally.
2 Comments
Having looked into this a bit, I think this is the solution:
chatwidget/slash_dispatch.rscallsadd_status_outputbefore sendingRefreshRateLimits, this causes /status rendered fromrate_limit_snapshots_by_limit_idbefore the async refresh is completed.The stale read happens because /status builds and inserts the status card before the async rate-limit/status refresh has completed. First time it render it uses whatever is cached in
rate_limit_snapshots_by_limit_id, applying the refresh result afterward so the second /status seed the new cached seed and looks correct.I'd change the /status flow so that for chatgpt sessions where the rate limit data needs to be refreshed, the command first request the refresh and delays rendering the status until the refresh result is handled. When it succeeds we then apply it and render the /status from that state. If it fails we can still render but show a warning (maybe?)
For sessions without the async refresh /status just renders immediately.
I'd really appreciate the opportunity to put together a PR if you'd be open to external contributions for this issue.
@khodges42, I don't think your analysis is correct — or is incomplete.
I will need more information to diagnose. Can you provide a screen shot of what you see on first run and after the value is displayed correctly?
We don't accept code contributions. It's almost always faster for us to have Codex write the fix rather than trying to reverse-engineer the intent of an external contributor. However, if you'd like to give me a link to a commit in your fork, that might be helpful.