When the $20 Plan Is Not Enough and the $200 Plan Is Too Much: Why We Built show-codex-usage

There is a certain kind of developer pain that is too small to justify a large product, but too repetitive to ignore.

That is exactly the category this tool came from.

https://github.com/nick-ma/show-codex-usage

One-line install:

curl -fsSL https://raw.githubusercontent.com/nick-ma/show-codex-usage/main/install.sh | bash && export PATH="$HOME/.local/bin:$PATH" && alias scu='show-codex-usage'

As more developers start using Codex as part of their real daily workflow, the conversation usually focuses on capability: how well it writes code, how much context it can handle, how useful it is for refactoring, debugging, or pushing through tedious engineering work. But once you move beyond occasional usage and start relying on it heavily, another issue shows up very quickly. The problem is no longer only what the tool can do. The problem becomes how you keep using it smoothly.

For many people, the $20 Plus plan is not enough. Once usage becomes serious, those limits can arrive faster than expected. At the same time, the $200 Pro plan is not automatically the right answer either. For some users it is absolutely worth it. For others, it is simply more capacity than they realistically need. In practice, a middle-ground strategy emerges naturally: use a few Plus accounts and rotate between them.

On paper, that sounds simple enough.

In reality, it is annoying.

Now the developer has a different operational burden. You need to remember which account is currently active. You need to keep an eye on the 5-hour window and the weekly window. You need to know which account still has usable quota left and which one is about to hit a limit. And when it is time to switch, the process is often far more tedious than it should be. Log out. Log back in. Re-authenticate. Confirm you are on the right account. Then get back to work.

That repeated interruption is the real problem.

It is not dramatic. It does not break the product. But it introduces friction into a workflow that should feel fast and fluid. If you are coding deeply, context switching is expensive. Even a few minutes of avoidable overhead starts to feel wasteful when repeated multiple times a day.

That was the pain point behind show-codex-usage.

We did not build it because the world needed another massive AI platform. We built it because we wanted a brutally simple local tool that solves one narrow but real workflow problem well.

The idea is straightforward. Codex already stores local authentication information. If that data can be read locally, then it can also be managed locally. If usage data can be queried for each saved account, then those accounts can be displayed side by side in one terminal view. And if all the necessary auth objects are preserved in a local account pool, then switching between them no longer needs a full login cycle. It can become a local file replacement operation.

That is the core design of the tool.

The script reads the current local auth information and automatically upserts it into an auth-poll.json file. That means every time a user logs into a new account through Codex once, running the tool captures that account into the pool. From then on, the account is remembered locally. Later, when the user wants to switch, the tool does not ask them to re-authenticate. It simply replaces the current auth.json with the selected account object from the pool.

That sounds small, but in practice it changes the workflow completely.

Instead of treating each account as a separate login session that must be manually re-established, the user gets a local switching system. Instead of wondering which account has quota left, they can see all accounts in one place. Instead of checking usage in a browser, they can inspect it directly in the terminal. Instead of remembering reset times mentally, they can read both relative and absolute reset information at a glance.

We also wanted the output to be immediately useful rather than technically correct but annoying. That is why the tool shows remaining quota instead of used quota. Most people do not think in terms of “I have used 73%.” They think in terms of “How much do I still have left?” So the display focuses on remaining capacity for both the 5-hour and 1-week windows. It also uses simple color coding: red when remaining usage is critically low, yellow when it is getting tight, and green when there is enough room left.

This is not a dashboard in the enterprise sense. It is a terminal tool. But that is exactly the point. It is fast, local, and frictionless.

The switching flow follows the same philosophy. We added a simple TUI mode that lists all accounts one per line, along with email, plan, quota information, and whether the account is currently active. The user can move up and down with arrow keys and press Enter to switch. Under the hood, the “switch” is just a controlled replacement of the local auth file. No logout. No new login flow. No unnecessary ceremony.

That is the kind of design we care about: reducing operational drag without adding another layer of complexity.

There is also a broader point here.

As AI tooling matures, a lot of attention goes to frontier capabilities, model benchmarks, and large-scale agent systems. That matters, but day-to-day developer experience is often shaped by much smaller things. Tiny bits of repeated friction accumulate quickly. A tool that removes a 30-second annoyance from a repeated workflow can create more practical value than a much larger feature that is only used once a month.

In other words, not every useful AI-related tool needs to be a grand product. Sometimes it just needs to fix the part of the workflow that keeps wasting your time.

That is how we think about show-codex-usage. It is not trying to be a platform. It is not trying to wrap everything in a polished SaaS layer. It is a focused local utility for developers who already know the pain of managing multiple accounts and want a cleaner way to work.

The implementation is intentionally minimal. Bash, curl, and jq are enough. That simplicity matters. The fewer moving parts there are, the easier it is to trust, inspect, and adapt. For a tool that handles local auth data and sits inside a developer workflow, that matters far more than flashy packaging.

In the end, the motivation behind this project is simple. We wanted to make a messy but common real-world workflow feel smooth.

If you are the kind of user who has ever thought, “The Plus plan runs out too fast, the Pro plan is too much, and switching accounts is a pain,” then this tool was built for exactly that situation.

Sometimes the best developer tools are not the ones that promise everything.

They are the ones that remove one annoying problem so completely that you stop thinking about it.