Repository navigation
Check quota now records the Gemini 4 Argon pool as the Gemini pool on paid Pro accounts (100% left while Gemini is exhausted) #43
Description
Plugin version: 3.0.9 (OpenCode 1, vault mode). The same code is on main (d28fca6).
Accounts: 5 (one paid Pro plan, four free).
Model: none involved. This is the quota check, not a request.
Reproducibility: every time on the paid account. Never on the free ones.
Bug description
On a paid Pro-plan account, /antigravity → Quota → Check quota now records the Gemini pool as 100% remaining, with a reset exactly 7 days after the check. At the same moment the Gemini weekly limit is used up:
- The official Antigravity CLI (1.2.11), same account, two minutes after the check: Gemini Models (Gemini Flash, Gemini Pro), Weekly Limit Remaining 0.00%, refreshes in 28h 54m.
- 56 minutes before the check, a real
antigravity-gemini-3.8-flashrequest on that account returned429 QUOTA_EXHAUSTED. The plugin then held the account until2026-10-23T22:30:53Z, the same instant the CLI shows.
The background quota refresh writes the correct figure again within about 4 minutes, so the account's Gemini value alternates between 0 and 100% each time the check runs.
The CLI also shows a third group on this plan, Gemini 4 Argon ("For paid Pro plans, Argon quota is separate"), with Weekly Limit 100.00%. That is the only Gemini-family limit at 100% on this account, and a 100% figure with a reset of check time + 7 days is how an unspent window looks.
Likely cause
aggregateQuotaSummary (packages/core/src/quota-manager.ts) maps each retrieveUserQuotaSummary group to a pool by the first bucket id prefix it recognises, and then assigns groups[pool] = … with no merge. If the Argon group's bucket id starts with gemini-, the Argon group replaces the Gemini Models group, whichever comes later in the response. The model-list path already excludes Argon (classifyQuotaGroup returns null for isGeminiArgonModel), but the summary path has no such check. I have not seen the raw bucket ids, so the prefix is an inference.
Evidence
The plugin's vault-mode state file, captured once a second (Gemini remaining fraction / reset / update time):
| UTC | Paid account | Free account (control) |
|---|---|---|
| 17:34:05 | 0 / 10-23T22:30 / 17:29:50 |
0.5324 / 10-28T22:43 / 17:30:06 |
| 17:34:06 (after Check quota now) | 1 / 10-29T17:34 / 17:34:06 |
0.4576 / 10-28T22:43 / 17:34:06 |
| 17:38:13 (background refresh) | 0 / 10-23T22:30 / 17:37:57 |
0.3635 / 10-28T22:43 / 17:38:13 |
All four free accounts kept their fixed resets through the check. Only the paid account received the "now + 7 days" reset.
Steps to reproduce
- On a paid Pro-plan account whose Gemini weekly limit is used up, open the Antigravity CLI quota screen. It shows Gemini Models 0% and Gemini 4 Argon 100%.
- In OpenCode, run /antigravity → Quota → Check quota now.
- The plugin records the account's Gemini pool as 100% remaining, with a reset of check time + 7 days.
Did this ever work?
Unknown. The Argon group is new on this plan.
Activity
iceteaSA commentedon Oct 22, 2026
The insula side is issue #39 in the insula repository: insula never publishes the Argon limit for this account. Its cache lane also carried this plugin's wrong figure for 25 s after the check, so the fault reaches insula's consumers too.
iceteaSA commentedon Oct 22, 2026
Narrowed down further, without reading a credential. The figure comes from the summary path, and it comes from a bucket that is not the Gemini Models weekly bucket.
Capture. I read the plugin's vault-mode state file straight after a manual Check quota now (19:26:36Z). This is the paid account's stored pools:
gemini(after Check quota now)0.998173062026-10-29T17:38:14Z[weekly]gemini(background refresh, 19:08:36Z)02026-10-23T22:30:53Z[weekly]non-gemini(after the check)1[5h, weekly]The four free accounts went through the same check with their fixed resets unchanged.
What this establishes
fetchAvailableModelswhen the summary call fails, and after a 403 it retries with no project (packages/opencode/src/plugin/quota.ts:848-860). A pool built from a model list has nowindows. The stored pool has awindowsentry, so it came fromaggregateQuotaSummary.gemini-. OnlypoolForBucketIdputs a bucket in thegeminipool, and it maps only that prefix (packages/core/src/quota-manager.ts:653). The windows loop drops every bucket it can't map (:711-712).2026-10-23T22:30:53Z. The official CLI and the background refresh agree on this, and the account's 429 hold ends at the same instant. The stored bucket resets at2026-10-29T17:38:14Zwith 99.8% left. So a second group in the response carries agemini-bucket, andgroups[pool] = …(:747) let it replace the Gemini Models group.One open point. A separate client calling the same account's summary on the daily endpoint, with its own User-Agent, gets no Argon group back (cortexkit/insula#39, comment 6348630463). So the extra group depends on the request: this plugin's harness User-Agent, the project it sends, or both. The exact bucket id is still not captured. A fix should not depend on it:
aggregateQuotaSummarymust not let a second group replace a pool it has already filled.classifyQuotaGroupalready applies on the model-list path (:471). The group's own description or display name identifies it more reliably than a guessed bucket id.Observed on 3.0.9. The cited lines are unchanged on
mainatd28fca6.iceteaSA commentedon Oct 22, 2026
The bucket is now identified directly as Argon's, not only by ruling out the others. The official CLI's log records its first Argon request on this account,
Resolving model Gemini 4 Argon (Low), at 17:38:11.55Z. The stored bucket's reset is 2026-10-29T17:38:14Z, which is that request plus 7 days. The 0.18% used is that one request.This also accounts for the reset in the original report. Before Argon was first used, the window had not started, so each check reported its reset as check time + 7 days. The window started with the 17:38 request, and since then the reset has stayed fixed.
The account's Gemini Flash/Pro weekly bucket still reads 0 with its reset at 2026-10-23T22:30:53Z, so the Argon bucket is still covering an exhausted Gemini pool.
agauth-alfonso commentedon Oct 23, 2026
Thanks for the detailed report and the timeline. It made this easy to confirm.
You're right about the cause. When the manual quota check reads Google's quota summary, the plugin assigns each group to a pool by bucket-id prefix, and a later group overwrites an earlier one. On your plan the separate Gemini 4 Argon group is read as Gemini, so it replaces the Gemini Models figure until the next background check corrects it.
The fix is in progress for the next release. The quota summary will use only the exact Gemini and Claude/GPT bucket ids, any other group (including Argon) will no longer change those figures, and two groups for the same pool will be merged rather than overwritten. The background check already reads by exact id, which is why it kept writing the right value.
This fix doesn't add a separate Argon quota figure yet. Today the plugin doesn't use a quota figure for Argon at all: if the Argon limit runs out, Google's
429marks that account for that model and the plugin moves on to the next account. Showing Argon as its own group is a follow-up.We'll keep this issue open until the fix is released, and link the release here.
agauth-alfonso commentedon Oct 23, 2026
Fixed in 3.0.11. On paid Pro plans, "Check quota now" no longer lets the separate Gemini 4 Argon allowance replace the Gemini figure. The Gemini and Claude/GPT figures now come only from their own quota entries, and a five-hour limit that Google has suspended because the weekly limit is spent no longer shows as a stale reading. Argon doesn't get its own quota figure yet. If the Argon limit runs out, Google refuses the request and the plugin moves on to your next account. Please upgrade.