Usage, Plan Limit, and Balance: Three Numbers People Keep Confusing

Number One: Tokens Spent, From Your Own Disk

The first number is tokens spent. Claude Code and Codex both write a transcript for every session, and both record per-turn token counts in it. Add those up over a window and you get what an agent consumed in the last 5 hours or the last 7 days. No API key, no account, no network. Token counts are read locally and not sent anywhere.

This number tells you whether Claude Code or Codex is the expensive one when you run both side by side, which you can't answer any other way while both are mid-task. It's also the only one of the three that's split by agent tool rather than lumped per account, though not per pane: two Claude Code panes share one total.

Read it with care, because most tokens in a long agent session are cache reads: context the agent already sent, served back from the provider's cache on each turn. As a single total, that looks catastrophic.

Split out, fresh input, output and cache writes together are a small slice of it. A tool that shows one big total without separating cache reads is showing you a number that will scare you for no reason.

The Money Version of Number One, and Why It Hedges

MXterm Pro's Token Meter prices each model from a table and shows the date its prices were last checked. A price table with no date silently becomes fiction.

A model with no published price is left unpriced instead of shown as $0.00, because "$0.00" reads as free and the truth is "we don't know". The total is then labeled a floor rather than a total, and it names the models that weren't priced.

The bigger qualifier is what the figure means. On a Max or Pro subscription, the dollar figure is what those tokens would have cost at pay-as-you-go rates. It is not your bill. Nothing in a transcript says which plan paid for a turn, so a tool reading only transcripts can't know what you were actually charged.

Number Two: Percentage of Your Plan

Your disk can't answer "how much have I got left?", and that is the question people actually ask. Nothing in a Claude Code transcript records where your subscription stands: when MXterm Pro's developer searched their own transcripts for rate-limit and quota fields, every match was prose inside a message, never a data field. The percentage of your plan has to come from the provider.

On macOS, MXterm Pro fetches the Claude percentage from Anthropic's own usage endpoint using Claude Code's saved sign-in. That means reading another application's credential. MXterm Pro does it through the system security tool, so macOS does not ask each time. It isn't available on Windows.

The switch is off until you turn it on, and it says exactly what it will do before you flip it. A denial stops the app asking again, rather than raising a dialog on every refresh.

Codex is the exception. Its CLI writes the plan's own rate-limit headers into its session files, so those percentages already sit on your disk and need no credential. The catch is freshness: a reading written during your last Codex turn is exactly as old as that turn.

A switch added in 1.0.22 reads Codex's own sign-in file and asks OpenAI directly for the current 5-hour and weekly windows. Use the plan percentage as the number to act on before starting something long.

Number Three: What's Left in the Account

The third number belongs to whoever you actually pay, and its shape depends on the provider. A prepaid provider like DeepSeek or Moonshot gives you a prepaid balance: money that only goes down until you top it up. A coding plan like Kimi's, MiniMax's or Z.ai's gives you remaining capacity in a window that refills.

An OpenRouter key shows the share of its spending limit used if the key has a limit, and only what the key has spent if it doesn't. MXterm Pro doesn't read an OpenRouter account balance. Each reading comes from the provider's own account endpoint, using an API key you paste. That source differs from the other two numbers, and only it knows about money you've already paid.

Before you wire any of them up, read what each provider exposes and where those keys live in full. The account readers follow each vendor's published response format; not every one has been checked against a live account yet.

A balance also resists being turned into a gauge, because it has no denominator. $37.40 of DeepSeek credit isn't a percentage of anything unless you invent what "full" means. MXterm Pro shows it as money and never turns it into a percentage. A balance never ranks against quota windows in the title bar chip, and the chip shows the lowest USD balance only when there is no quota and no Claude Code or Codex usage to show.

When Each One Actually Matters

Before a long run, look at the plan percentage. Tokens spent can't tell you whether you'll hit a wall in twenty minutes, and a healthy prepaid balance doesn't help if the constraint is a 5-hour subscription window.

While you run Claude Code and Codex side by side, watch tokens spent.

When something stops working, the three disagreeing is the diagnosis. A plan at 100% with a fat balance means you're rate-limited, not out of money. A healthy plan percentage with an empty prepaid balance means the opposite. If tokens spent looks normal and the other two look fine, the problem isn't quota at all.

At the end of the month, none of the three is your invoice. The transcript-derived cost is at API rates, plan percentages aren't money, and a balance is a snapshot. The vendor's billing page is the authority, and the only thing that should settle an argument about what you were charged.

How to Read Them Together Without Fooling Yourself

Reading Claude Code usage vs plan limit together takes three rules, and they hold in whatever tool you read the numbers in.

First, check the age of anything that isn't computed live. A provider reading that failed keeps showing its last good value. That's the right behavior, but only if the display says so.

Second, never convert between them. Tokens spent can't become a percentage of a plan, because you don't know the denominator. A percentage can't become money. A balance can't become remaining turns. Each conversion needs a number nobody published.

Third, treat a percentage as belonging to a specific window with a reset time. "90% used" means nothing until you know whether that's a 5-hour window resetting in twenty minutes or a weekly one resetting on Sunday.

In MXterm Pro each row names the window its bar belongs to and when it resets. A window that has already reset shows a dash, because a stale figure would pass for the current one. See also the Token Meter page and the Token Meter docs.