Codexometer is a small, retro terminal dashboard for your current Codex quota. Leave it open in a second terminal window or pane to see every active usage window, its remaining capacity, and its reset time—without repeatedly opening /status in the Codex session where you are working.
Why use it?
/status is useful, but it lives inside your active session. Codexometer turns the same quota information into an always-visible companion display that refreshes automatically and uses your prevailing Codex login.
You can choose from five colour themes and several responsive displays, including a consumption-pace meter that shows whether you are using quota faster or slower than the current window is elapsing. There is also a local token-activity monitor and an opt-in deterministic model benchmark.
It works particularly well in:
- another Windows Terminal tab or split pane;
- a second Terminal or iTerm window on macOS;
- a tmux, Zellij, or other terminal-multiplexer pane;
- an Ubuntu terminal beside the Codex CLI.
Codexometer is written in Go and builds as a standalone binary for macOS, Windows, and Linux.
If you enjoy it, please give the project a 
on GitHub!
I solved the same problem directly in my Linux Codex client.
Codex Tray now shows the current weekly usage and the exact reset time directly in the UI, so there is no need to run /status or use a separate monitoring tool.
The client is written in PyQt6 and communicates directly with codex app-server over JSON/stdio — no Electron and no terminal output parsing.
Screenshot below shows the current implementation: Weekly limit: 7% (resets 08:56 Aug 18).
GitHub: https://github.com/bezoar74-hash/codex-tray-linux
Feedback is welcome, especially if anyone wants to test it on other Linux distributions.
I think “need” is only part of the point here 
Codexometer is deliberately a practical toy 
On top of that a lot of serious devs use Codex CLI, and with that there is significantly more need …
Thanks for sharing this!
Idea: Can we create a few standard tasks and compare token usage across different runs?
I’m asking because we regularly see user reports stating that token consumption has suddenly changed and rate limits are reached faster.
If we can establish a community baseline for different use cases, this should help bring some objectivity to these reports.
What do you think? Is that a good use case for your tool?
That’s a really interesting feature request. Like a usage “stop watch”? I love it!
I stand ready to help with the concept if needed. 
OK so task benchmarking is more challenging as we’d have to determine what constitutes as done and signal that in some way.
Nevertheless I’ve made a start on the stopwatch it self:
this is now merged as another style you can cycle to 
Oh and now all the buttons are both hotkey and mouse clickable 
And I’ve cleaned up the interface and added tabs (use tab to switch or click them with mouse):
which I think are a lot more logical.
That releases the S hotkey for our stopwatch.
Regarding the stopwatch feature, let’s take another look at what we want to achieve.
A) Whether the same task uses the same amount of tokens at two different points in time, ceteris paribus.
B) How much usage is deducted from the rate limits when consuming the same amount of tokens at different points in time.
Looking at it this way, I believe B is an objective measure.
A can potentially cause more confusion because of the randomness introduced by the models.
But what if Codex is having a high demand day and it gets through less tokens as service is slower?
I think it would be great if we could measure against actual task completion (which is surely what matters ultimately?)
That is quite a fun project.
Ah, you mean a stopwatch for latency, time to first token, and time to completion?
Here’s an older implementation as a reference for what to expect: https://openai-status.llm-utils.org/
Or do you mean token usage per task?
My initial concern is that there will be some randomness in the results because of the models.
But, thinking about it, many reports claim a massive difference in rate limit consumption compared to another day. If we can define a standard task with a standard harness and instructions, then we can run it often enough to determine an interval where token consumption is likely to land.
We can then answer the question of whether usage is being consumed a lot faster with some degree of confidence.
Ideally we re-use the codex harness, we just change models and reasoning levels and send the same task independently, without memory, to each combination. then we can summarise the amount of time it took, the number of tokens and the api equivalent cost. the hard part is working out a sufficiently complex task which has a very simple answer that can ideally be judged by deterministic code
Yes, this could include a standard set of config files like config.toml, but also the model catalog and maybe others.
Regarding the task’s result, couldn’t that simply be a Boolean produced by the model’s reasoning? Something along the lines of: “Create solution.txt with only 1 or 0 as the answer.”
I was also thinking about whether users could use their own reference task, which would require a project and Codex snapshot. But that’s maybe something for later.
ok @VeitB that’s merged and deployed - consider it Beta for time being.
details of the benchmark tasks here:
A terminal widget that allows you to keep track of Codex usage against your current quota
Given there are at least three dimensions of interesting results, this is kind of begging for a 3D output! 
A fresh, ephemeral, read-only app-server thread is used for each trial, so benchmark history does not clutter normal Codex sessions.
Clever! Looking forward to try it and even more importantly looking forward to use it as an actual tool in our daily conversations here.