AI tips · No. 3
2026-09-25

Meter every AI plan, and spend what's left before it resets

One meter that costs nothing to run, and a rule for the capacity you'd otherwise lose.

Using an AI agent? Don't build this by hand. Point your agent at this page; there is a section for it at the bottom.

The problem

Three AI subscriptions add up to a pile of separate limits. Claude alone has three: a five-hour session, a week across all models, and a week for its biggest model. Codex and Grok each have a week. Every one resets on its own clock, and only Codex says what percentage you've used anywhere on your own machine.

Running out in the middle of a job is the obvious cost. The quiet one is the opposite: capacity that resets unused is money spent on nothing.

One meter

My one rule for it: watching token spend must not cost tokens. So the meter never calls a model and never touches the network. Every vendor already writes its usage to disk:

  • Codex gets a rate-limit block back with every request, and its CLI writes it into the session log. That's the real percentage and reset time, exact.
  • Claude Code records every message's token usage in the session transcript, subagents included. The tokens are exact, but there's no percentage.
  • Grok: my bridge logs the dollar cost of every call. The dollars are exact, but again there's no percentage.

For the two that hide their percentage, a human reading is the ground truth. Whenever I look at /usage or an account page, I record the number:

meter.py --read claude_week 19

Each reading is stored with the consumption at that moment, and the ratio between readings becomes the estimate. Two Grok readings two days apart agreed to within a few cents a point. A timer collects every 20 minutes, and any session runs meter.py for a dozen-line summary instead of scanning transcripts itself:

codex    9% left   week  resets Sun 00:05 (33h)
claude   8% week   3.8M out since the week opened
        42% 5h     1.5M out since 13:30  resets 18:30 (3h)
grok    77% used   $30.76 over 55 consults

Claude's five-hour limit is a block, not a rolling window: the first message opens it and it resets five hours later. Modelled that way, with the start rounded down to ten minutes, the meter predicted all five real "session limit" resets on disk.

It also prices each week's tokens at API list prices. This week my Claude plan came to about 90 times the API price of the same tokens, Codex about 15 times, Grok about 7. That figure is live on moraineworks.com.

The burn-off

Unused capacity expires. A five-hour block I don't use is gone, and a weekly bucket with 30% left at the reset is 30% of the price paid for nothing. So when a window is about to reset with room in it, I spend it on purpose.

  • On the hardest problems. I keep a queue of work that beat the cheaper agents. A problem gets into it by failing, which is a fact rather than a judgement call. The end of a working session is when that queue gets the most expensive model.
  • Spend, don't hoard. One week Codex had a third of its week left and 52 hours to go. Rationing it would have wasted it, so it got every file-writing batch for two days, and the prose went to Grok.
  • Shape the job for the budget. Two problems per agent, not four, and have it write the first file early. An agent given four spent its whole budget reading and was cut off with nothing written.
  • Keep a stop line. On Grok mine is 95% of the week. It's my line, not a vendor limit, so crossing it is a decision rather than an accident. The meter shows the dollars left before it.

What bit

  • No percentage on disk for Claude or Grok. Without a human reading now and then, the token count is just a number.
  • No weekly reset time on disk either. Read it off the account page once; the meter rolls it forward a week at a time.
  • A nightly headless run writes no transcript, but still opens the day's first five-hour block. Every reset prediction was wrong until the meter read that job's log too: none of five right before, five of five after.
  • A failed worker call is billed but never logged, so right after a failure the meter reads low.
  • Don't open a CLI's interactive screen from a script to check usage. Neither has a usage command, and the tool call kills the screen mid-draw.

The result

Before any big job, one command answers "can I afford this?", and it costs nothing to ask. The capacity that used to expire now goes to the problems nothing cheaper could crack.

For your AI agent

Anyone with an AI agent will just tell it to read this and set it up, so this part is written for the agent. Paste something like this into Claude Code:

Read https://jacobkunselman.com/tips/usage-meter-and-burn-off/agent.md
and build me the same usage meter for the AI plans I have. Then add the
burn-off rules to my CLAUDE.md.

agent.md is the plain-text spec: where each vendor writes its usage, the exact fields, how calibration works, the five-hour block model, the burn-off rules, and acceptance tests. The reference files: