Feature request: clearer Codex usage and credit dashboard

Codex currently shows several separate limits: a 5-hour limit, a weekly limit, plan-included usage, and purchased credits. It is difficult to understand how these limits interact and when purchased credits begin to be used.

I suggest a clear dashboard showing:

  • included usage remaining;
  • weekly usage and exact reset time;
  • 5-hour usage and exact reset time;
  • purchased credit balance and expiration date;
  • estimated and actual cost of each task;
  • model, reasoning level, tools, context length, and Fast Mode impact.

Even if the internal algorithm cannot be disclosed, users should receive a simple explanation of which allowance is being used and why. This would make Codex usage more predictable and help users manage their credits responsibly.

It’s free, open-source, robust and easy to install it on Linux, WSL, Windows via Powershell or macOS

There’s even a web mode so it can run in your browser!

It’s pretty mature now: try it and let me know what you think and how it might be improved.

Thanks, Robert. I installed Codexometer and it is now working correctly after I explicitly provided the path to the Codex CLI.

It is very useful for making the different quota windows visible. In my case, it clearly shows:

  • the general Codex weekly quota at 100% used;

  • the GPT-5.3-Codex-Spark five-hour quota at 0% used and 100% free;

  • the GPT-5.3-Codex-Spark weekly quota at 100% used and 0% free.

This confirms the confusing situation I described: the five-hour dashboard shows full availability, while the weekly limit still prevents me from using the model.

I also tested Codexometer’s experimental read-only web interface. It confirms the same results and makes the contradiction particularly easy to see. The web view does not add much information beyond the terminal dashboard, but it provides a clearer visual representation of the three separate quota windows.

Codexometer is therefore very helpful as an observability and diagnostic tool. However, it does not solve the underlying problem. It still shows API-EQ N/A and LIMIT ATTRIBUTION UNKNOWN, so it cannot explain how my purchased credits relate to the actual model limits or restore access to the tools I need.

In other words, Codexometer makes the limitation visible, but it also reveals that the relationship between credits, quotas, model access, and effective work capacity remains unclear.

I am attaching a screenshot from the web interface for reference. It was captured locally on September 15, 2026.

Great you made the effort to try this out :+1:

Let me address a couple of things.

Firstly - we’re consuming public information in Codexometer - well information available to any similar client app like Codexometer, so we are limited by what OpenAI exposes on the codex app-server. Neither of us are privy to some internal mechanisms and data that are not exposed on that interface.

The numbers are estimates and the estimates require activity - the app takes up to 5% of consumption before it will start to quote estimates - it learns by watching activity over a period of potentially hours. Unfortunately that means that when you are at 100% there’s no capacity left to perform that analysis - you will need to wait for the next period or reset.

The rationale for its numbers is published on the README here.

This is a result of research and is a best guess.

The estimation may evolve over time if any bugs or unsafe assumptions are discovered. It’s already received one fix for miscalculating whilst in FAST mode.

Also, my “Usage and billing” tab shows a remaining credit balance of $203.67. However, Codexometer does not translate this balance into tokens, dollar consumption, remaining capacity, or a usage graph. It displays quota windows, but it does not establish a clear relationship between my financial credit balance and my actual access to Codex models. This leaves me unable to determine whether my credits are being consumed, how quickly they are being consumed, or why they do not restore access to the models I need.

Yeah, that’s presently out of scope for the time being, but an interesting enhancement roadmap item, thank you for raising.