Cursor, Copilot and Antigravity limits in one place

No token is refreshed, stored or sent anywhere but to the vendor that issued it, and nothing signs in.

Cursor

The included ring comes from the same usage summary cursor.com's dashboard reads, and on-demand spend is shown in dollars, filling against its cap where the plan sets one. Three things about Cursor's figures are worth knowing before you trust any meter of them.

When Cursor gives two answers, the further one wins

Cursor's summary states a plan window twice: as a percentage, and as dollars used against a limit. On most plans they agree. On one Enterprise account they read 55% and $20 of $20, and the account's own billing export settled it: Cursor had been marking requests On-Demand, which it does only once the included allowance is spent. So Notchmeter shows a window as spent as its furthest-along figure says, and prints the dollars under the bar as Cursor gave them, so the disagreement stays visible. Under-reporting a spent window would hide exactly the thing a meter exists to catch.

The model meters are not shares

Cursor's "Cursor models" and "Other models" percentages are metered apart from the included total. The same account read 47% and 100%, which add to 147% and so cannot be two slices of one allowance. The caption says Metered apart from the included total and nothing more, because what each is a percentage of is not established.

A seat billed on-demand

On a seat Cursor meters nothing for, its model meters read 0% however much is spent: on 2026-09-20 one read "Cursor models 0%" against $8.76 of spend that day. A zero that money is flowing past is not a figure, so it is not drawn as one. Notchmeter asks for the dashboard's own cycle figures first and fills the included ring from them where the seat has a limit; with none, Today's spend compares today's dollars from the export with your average day of the thirty before. That is a comparison, not a limit: it paces, but it never runs out, warns or notifies.

Cursor's usage export is day resolution and reaches back 30 days, so Cursor takes no part in last-hour burn figures, and older days are what Notchmeter has kept since it was installed. Its Terms of Service (effective 2026-09-03) list among things a user may not do: "harvest, scrape, or extract data from the Service". These are the dashboard's own reads of your own usage, made by a program instead of a browser; whether the clause reaches them is Cursor's to say, and if Cursor asks, the meter goes in the next release.

GitHub Copilot

Since 2026-06-01 GitHub bills Copilot by usage in AI credits, "1 AI credit = $0.01 USD", with a monthly allowance per plan that resets on the first and does not roll over. The endpoint Copilot's editor plugin reads carries the month's running count, and that count times a cent is the one Copilot figure that is money.

• Allowances are not assumed. GitHub publishes them per plan (Pro 1,500, Pro+ 7,000, Max 20,000, Business 1,900 and Enterprise 3,900 credits a month), but no endpoint states a seat's own ceiling, so a bar appears only where GitHub's reading carries one.
• The day is this Mac's. GitHub reports one month-to-date total, not when each credit was spent. Each rise is laid on the day Notchmeter saw it; the first read of a month sets a baseline instead of charging the whole count to that day. The row is marked as an estimate for that reason, though nothing in it is priced here.
• A legacy seat stays in requests. Premium requests are shown as counts and never multiplied by an overage rate, which would invent a bill for requests inside the allowance.
• Organisation billing is opt-in, for owners and billing managers, and stays off the Cost card because it is the whole organisation's month rather than this seat's.

One honest note: the quota endpoint answers only Copilot's own client, so that single request carries the Copilot Chat extension's identifiers instead of Notchmeter's. It is the one borrowed identity in the app besides Antigravity's, and both are stated in the accuracy document rather than left in the code.

Antigravity and Gemini CLI

They are two rows since 0.9.0, because Google's backend picks the licence it checks from the caller's identity, so the two products can hold different quotas on one Google account. Both meter against the same Google backend, and the only Google login on disk is the one Gemini CLI caches: the Antigravity app keeps its own in the Keychain and serves its quota only through a local server inside the running app, which Notchmeter does not attach to. So the meter needs one sign-in through Gemini CLI: run gemini and choose Login with Google. An API-key or Vertex AI setup has no quota to read.

• Personal accounts. Since June 2026 Google serves Gemini CLI's quota only to Code Assist Standard and Enterprise accounts. A personal account gets a sentence saying so, not an error code.
• The Antigravity row, shown when the app or its CLI is installed, asks under Antigravity's own client identity. The answer is the summary Antigravity's own panel shows: a session and a weekly window for each model group. The Gemini CLI row asks under Gemini CLI's.
• Two deployments. Google meters the quota on one of two hosts, and the other answers every window untouched with a reset five hours out. The Antigravity row prefers the host Antigravity's CLI last logged; the Gemini CLI row asks both. A placeholder answer is shown with no figure and a caption, not as an unused quota.
• No declared length, no pace. Gemini CLI's per-model buckets declare no window length, so they carry no pace tick until Google declares one.

There is no dollar figure because there is nothing to derive one from: the endpoints return fractions, no price and no token count, and a seat is not billed at Gemini's API rates.

Side by side

Each assistant gets a ring beside the notch, showing up to three of its windows, chosen under Rings and windows on its page in Settings. The panel gives each a row with its most urgent window; the Usage Dashboard (⌘U) lays every limit out with its pace tick and how much a day lasts until it resets; and notchmeter --json carries each window with a source: vendorEndpoint for the vendor's own figure, localSnapshot for the newest figure a tool wrote to disk, localEstimate for Notchmeter's own arithmetic.

Where a vendor splits a plan by model, an All models window can combine them, and it is the one window no vendor published, so it is labelled as derived. It adopts the vendor's own plan total exactly where there is one, takes the highest of the model windows rather than their average otherwise, uses the soonest reset, and adds up no money. The routing advice then compares the three with Claude Code and Codex on the same terms (see which assistant should get this task).