Which assistant should get this task?
If you pay for more than one coding assistant, the question before a long job is rarely "which is best at this". It is "which of them can afford it right now". That second question has an answer you can compute, and this is how Notchmeter computes it.
The short answer
Switch models before you switch tools: a per-model limit near its end usually sits beside another model, on the same plan, with room. If the whole plan is tight, move the work to another assistant only when that one has at least half of its own main window left. And if the tight window resets within the hour and nothing else has room, wait. Notchmeter applies those rules to every assistant's live reading and says the result as one instruction.
What a meter can and cannot know
No usage meter knows which model writes better migrations, which one your team trusts for security work, or which bill your employer pays. Those are your call. What it does know, with a source for every figure, is how much of each window each assistant has used, how fast, and when each resets. Routing on that alone already avoids the two expensive mistakes: running a long job into a wall halfway through, and paying for extra usage on one plan while another sits idle.
The rules
These are pure functions over every visible assistant's reading, each pinned by unit tests. The panel says at most three lines at once, most urgent first: a run-out before a model switch, a model switch before a note about room elsewhere.
| Line | When it appears |
|---|---|
| Run-out, with somewhere to go | A window is behind pace and has a run-out time; if another assistant on a paid plan has half its main window left, the line ends by naming it (Codex weekly is at 22%). |
| Switch models | A per-model window is at 85% or more, and another model's window, or the plan's overall window, has at least 40% left. Said once per assistant, for its fullest model; a model already at 100% puts this line ahead of every forecast, since it is the one that says what to do now. |
| Wait | A window is out or behind pace, resets within the hour, and no other assistant on a paid plan has room. |
| Room elsewhere | An assistant's main window is on track or behind, and another assistant on a paid plan has at least 50% of its own main window left. |
| Off-peak | Claude's peak hours end within the hour (see the run-out guide). |
Why models before tools
Moving a task to a different assistant costs you its context, its conventions and often its permissions. Moving it to a different model in the same assistant costs a /model. Anthropic, Google, OpenAI (for GPT-5.3-Codex-Spark) and OpenCode Go all meter some limits per model, so the cheap move is often available and easy to miss. One caveat travels with it: Anthropic's pricing page says Claude 4.7 and later count roughly 30% more tokens than 4.6 and earlier for the same text, so when the two models named sit either side of that line, the advice adds … counts about 30% more tokens for the same text. The same work will move the newer model's meter further.
What counts as "room"
An assistant's main window is its longest plan-wide one: the weekly window for Claude Code and Codex, the billing cycle for Cursor, the month for Copilot, and the longest of Kimi Code's, its 31-day window where the plan meters one. Gemini CLI publishes only per-model windows, and Antigravity only per model group, so neither has a main window and neither is ever named as the place to go. Half of a main window left is the threshold, and a tie goes to the assistant you placed first in Settings.
A free tier is never named as room, however empty it is: Codex's free plan, Copilot Free and a Claude free subscription meter so little that routing a paid tool's work there would stall it. A reading that names no plan counts as paid.
When waiting beats switching
A session window that resets in forty minutes is often the cheapest option there is. The wait line appears only when nothing else has room, and it links the vendor's status page when the vendor's own endpoint is answering server errors, because then the delay may be theirs.
Asking from a script, or from Claude
The same rules answer outside the panel. Install the command line tool from Settings › General, then:
notchmeter --json # every assistant, with the advice lines
notchmeter claude --json # one assistant
echo $? # 0 fine · 10 a window at 80% or behind pace · 11 a window at 100%While the app is running it answers from the app's own report and asks no vendor again; it reads afresh only when the app is not running, or with --force. It never prints a token. Exit code 20 means readings exist but nothing has been used, and 30 means there is no reading at all. The same object is an MCP tool, get_limits, from Notchmeter --mcp, for Cursor, Codex and Claude Desktop.
For Claude Code there is a plugin that packages a skill and that MCP server. With it, Claude checks its own windows and the advice before a long task, without being asked, and can propose doing the mechanical part on the model that has room:
/plugin marketplace add Amir-Hackett/notchmeter
/plugin install notchmeter@notchmeterWhat this will not do
- It does not move work for you. Every line is advice. Notchmeter never switches a model, claims a credit or starts a session.
- It sees each vendor's figure, not your intent. A window at 30% on a plan you are saving for Friday looks the same as one you are free to spend.
- It cannot route to what it cannot read. An assistant with no reading, switched off, or on a login it cannot see is never named.
- Its figures are this account's. The vendors' windows are account-wide already; the cost figures are this Mac's (see the cost guide).
Sources
- Sources/Notchmeter/Advisor.swift: every threshold above, as constants, with
AdvisorTestspinning them. - docs/features.md: the advice table and the main-window rule.
- plugin/skills/notchmeter/SKILL.md: what Claude reads and how it is told to act on it.
- Anthropic, Pricing, on the tokenizer change at Claude 4.7, as cited in the accuracy document.