Antigravity usage: Gemini quota group missing, and full buckets show a reset time that never counts down#23080

Additional confirmed reproduction (macOS, 2026-10-30) — root cause isolated to the legacy User-Agent + exclusive fallback

Adding a fully instrumented reproduction of this issue on a second account/platform, because it decides between the two candidate mechanisms discussed here and in #22876, and it constrains which of the open fix PRs can actually work.

Environment: macOS (arm64), T3 Code (Nightly) 0.1.6-nightly.20261030.3917 (published 2026-10-30, commit 97e35bcf23e4). apps/server/src/provider/antigravityUsageLimits.ts has the identical git blob (75333ae8…) on that nightly and on main HEAD 32ecd717 (2026-10-30), so this is current, not a stale build. Auth: oauth-personal, single Antigravity instance.

What T3 shows vs. what the backend actually returns for this account

Direct POST https://cloudcode-pa.googleapis.com/v1internal:retrieveUserQuotaSummary with the ACP client identity (same acp_token.json credential T3 reads, body {"project":"aicode-consumers"}, token refreshed in memory, nothing written to disk) at 2026-10-30T10:05:32Z → HTTP 200, 3 groups / 5 buckets:

The Argon bucket's own description reads: "You have hit your weekly limit, it refreshes in 6 days, 8 hours…"

T3's Usage → Limits shows only the two 3p rows (5-hour 100% left, Weekly 49% left ↻6d 3h). This is not a rendering/scroll issue: the on-disk payload the UI renders (~/.t3/caches/antigravity.json, checkedAt: 2026-10-30T10:11:46.068Z) contains exactly 2 windows — 3p-5h usedPercent 0, 3p-weekly usedPercent 50.506… — and packages/shared/src/usageLimits.ts sorts gemini- windows first, so Gemini rows could never hide below the visible 3p rows. Net user impact: the model family this account actually uses (Gemini 4 Argon) is exhausted (0% weekly left) and completely invisible in T3, while the panel suggests only a half-used Claude/GPT pool — a family this account barely touches (9 of the 10 local ACP conversation DBs are dominated by gemini-4-argon-high).

Decisive experiment: 2×2 User-Agent × host matrix

Same credential, same body, seconds apart, only the User-Agent changes (2026-10-30T10:10:30Z, repeated 10:11:19Z, identical result):

with identical 3p values in all four responses. Two consequences:

1. For this account the UA is the deciding variable (contra the "whatever user-agent" observation in the original report — the gating appears to be account/credential-dependent, which presumably explains the divergent reports between here and #22876).
2. This is stronger than #22876's table: here the production host also omits both Gemini groups under hub/1.0.0. So the already-merged #20081 both-hosts merge cannot recover the buckets — they never arrive on either host with the identity T3 currently sends.

Mechanism (source, current main)

1. antigravityUsageLimits.ts:260 still sends antigravity/hub/1.0.0 … → Google returns only the 3p group.
2. antigravityUsageLimits.ts:282-286:
   ts

   1	const windows = summary.length
   2	? summary
   3	: yield* fetchWindows("fetchAvailableModels", …)

   summary.length === 2 is truthy, so the model fallback never executes. Corroborated locally twice: server trace logs show 10 retrieveUserQuotaSummary lines and 0 fetchAvailableModels lines across 5 probes; and a mocked-HttpClient run of the real module (both hosts returning 3p-only summaries, models containing Gemini) outputs the two 3p windows with FETCHMODELS_CALLS: 0. No existing test covers "both summaries non-empty but 3p-only while models hold Gemini" — the suite passes without exercising this case.
3. A fallback-merge alone (#26582) cannot fix the Argon half. Under the hub/1.0.0 UA, fetchAvailableModels returns 20 models with no gemini-4-argon-* and no gemini-3.8-flash-{low,medium,high} (vs 26 models incl. Argon under the ACP identity). And when Argon is present, its quotaInfo omits remainingFraction (proto3 zero), which quotaWindow (:85-87) drops. The summary endpoint is the only reliable Argon source. A UA/identity fix (the #23011 / #21361 class) is therefore necessary; the fallback merge is at most a partial complement for generic Gemini rows.
4. Taxonomy: even when it arrives, gemini-argon-wtu-weekly gets the generic label Gemini · Weekly (:107-111, prefix match), indistinguishable from gemini-weekly. Argon needs its own label, as #21361 proposes, and docs/user/providers-antigravity.md:134-136 still documents only two groups.

Ruled out (each falsified with inspected evidence, not assumed)

• Below-the-fold / virtualized rows — cache windows.length === 2; gemini-first sort; Antigravity is the last section with empty space below the last card.
• Mislabeled Gemini data — window id is the upstream bucketId verbatim and 0.49494 belongs only to 3p-weekly (Gemini weekly = 1, Argon weekly = 0, distinct reset times). The 3p rows are genuine; Gemini rows are absent, not renamed.
• Stale cache — checkedAt was ~4 min old at inspection and fresh live probes with T3's exact request deterministically reproduce the 3p-only result.
• Wrong account/instance — exactly one Antigravity instance/token on this machine; my probe used the same token file T3 reads and returned bit-identical 3p values to T3's cache (usedPercent 50.50600000000001 == (1 − 0.49494) × 100, same resetsAt).
• Inverted percent — math is correct: usedPercent = (1 − remainingFraction) × 100 (:93); an inversion would show 51% left weekly, not 49%.

Minimal reproduction

1. Sign in to Antigravity in T3 with a personal Google account that has a Gemini 4 Argon weekly bucket (usage > 0 makes it obvious).
2. Open Usage → Limits → Antigravity. Observe only Claude & GPT (shared) · 5-hour and · Weekly.
3. Replay T3's request (retrieveUserQuotaSummary, both Cloud Code hosts, UA antigravity/hub/1.0.0 …) with the local ACP credential → 1 group. Change only the User-Agent to the ACP client identity → 3 groups, including gemini-argon-wtu-weekly.

Expected: 5 rows — Gemini 5h/Weekly, Claude & GPT 5h/Weekly, Gemini 4 Argon Weekly (0% left here). Actual: 2 rows, Argon exhaustion invisible.

Suggested fix direction

• Send a current client identity for quota requests (evaluate #23011's hub/2.24.0 and #21361's ACP identity; note the minimal sufficient UA is untested — I verified hub/1.0.0 fails and the full ACP identity works, but did not probe hub/2.24.0 on this account).
• Treat "summary lacks a Gemini bucket" (not only "summary empty") as a trigger to also consult fetchAvailableModels (#26582) as a safety net for the generic Gemini group.
• Give gemini-argon-* buckets their own Gemini 4 Argon label; keep upstream group displayName instead of hard-coded families where possible.
• Add a regression test: both hosts' summaries contain only 3p buckets while fetchAvailableModels contains Gemini models — currently untested, and this exact case reproduces the screenshot (FETCHMODELS_CALLS: 0).

Related: #22876 (UA tracker), #27473 and #27448 (same symptom, filed today — likely duplicates of this issue), PRs #23011, #26582, #21361, #21020. The perpetual "resets in 4h 59m" countdown on untouched buckets visible in my screenshot is the separate #22815 artifact, not part of the above root cause. No credential values are included anywhere in this comment; all probes refreshed the token in memory only.

Additional reproduction on Windows:

• T3 Code Desktop Stable 0.1.6; Windows 11 x64; server 0.1.6.
• The Antigravity provider is enabled and connected.
• At 2026-10-31 11:23 UTC, the provider cache contained only 3p-5h and 3p-weekly (“Claude & GPT (shared) · 5-hour” and “Claude & GPT (shared) · Weekly”). It contained no Gemini or Gemini Argon quota windows. The server trace confirms the Antigravity quota probe ran at that time.

This reproduces the missing Gemini/Argon limits on the latest stable Windows desktop build. The 0.1.6 release uses the hub/1.0.0 quota identity. PR #28090, which updates the identity and preserves Argon’s label, merged after that release; no release containing it was available when checked.

Seems to be fixed now, closing!