Skip to content

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

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

Description

@GameRipper665
GameRipper665
opened on Oct 21, 2026

Version: 0.1.2-nightly.20261021.3473, Windows 11, Google AI Pro account

Expected (Antigravity app): "Gemini Models": weekly 85% (resets 4d 20h) and 5-hour 100%; "Claude and GPT models": weekly 100% and 5-hour 100%.
Actual (T3): only "Claude & GPT (shared)", 5-hour and weekly, permanently at "100%, resets in 5h 0m / 7d 0h".

Cause:

  1. antigravityUsageLimits.ts calls v1internal:retrieveUserQuotaSummary with the ACP CLI OAuth credential from antigravity-acp/acp_token.json. For this account the response only contains the 3p-weekly and 3p-5h buckets ("Claude and GPT models"). The Gemini group isn't returned, whether or not the body includes project and whatever user-agent is sent. The same Google account in the Antigravity app does get the Gemini group, so the summary seems to depend on the calling client or credential.
  2. fetchAvailableModels is only consulted when the summary is entirely empty, so the Gemini models are never merged in. The per-model quotaInfo it returns (and retrieveUserQuota) also reports remainingFraction: 1 for every Gemini model, so it isn't a reliable substitute.
  3. For a bucket with no usage, the API returns resetTime = now + window. T3 renders that, so every refresh shows "5h 0m" or "7d 0h" again.

Proposed fix:

  1. Get quotas from the running Antigravity agent instead of calling Google directly with the CLI token. The language server already exposes RetrieveUserQuotaSummary and has a cache for it, and it returns the same groups the app shows. If that isn't possible, call the summary with the same client identity the app uses.
  2. Keep the group's displayName and show every group the API returns. Don't hard-code only the gemini-* and 3p-* families.
  3. When remainingFraction === 1, hide the reset countdown the way Antigravity does, or show "not started".
  4. Don't silently drop a whole provider group. If a group that was present before disappears, show it as "unavailable".

Activity

  1. alfredolopez80 commented on Oct 30, 2026

    @alfredolopez80
    alfredolopez80
    on Oct 30, 2026

    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:

    Group Bucket remainingFraction resetTime
    Gemini Models gemini-weekly 1 2026-11-06T10:05:33Z
    Gemini Models gemini-5h 1 2026-10-30T15:05:33Z
    Claude and GPT models 3p-weekly 0.49494 2026-11-05T13:10:02Z
    Claude and GPT models 3p-5h 1 2026-10-30T15:05:33Z
    Gemini 4 Argon gemini-argon-wtu-weekly 0 2026-11-05T18:33:13Z

    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):

    Request daily-cloudcode-pa cloudcode-pa (prod)
    T3's current UA antigravity/hub/1.0.0 (aidev_client; …; cl=963137146) HTTP 200, num_groups=1 (3p only) HTTP 200, num_groups=1 (3p only)
    ACP client identity HTTP 200, num_groups=3 HTTP 200, num_groups=3

    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 [Bug]: Antigravity Gemini quota reads 100% with the legacy User-Agent (follow-up to #21115) #22876).
    2. This is stronger than [Bug]: Antigravity Gemini quota reads 100% with the legacy User-Agent (follow-up to #21115) #22876's table: here the production host also omits both Gemini groups under hub/1.0.0. So the already-merged fix(usage): show Antigravity Gemini limits when one quota endpoint omits them #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: 
      const windows = summary.length
  ? summary
  : 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 (Show Antigravity Gemini quota when the summary omits it #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 fix(server): Antigravity Gemini limits show consumed quota instead of 100% left #23011 / fix(antigravity): separate Argon model fallback quotas #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 fix(antigravity): separate Argon model fallback quotas #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

    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.

  2. AFG473319
    marked [Bug]: Antigravity usage limits omit Gemini quotas when retrieveUserQuotaSummary returns only 3p buckets #27473 as a duplicate of this issue on Oct 31, 2026

  3. 1DogeGamer commented on Oct 31, 2026

    @1DogeGamer
    1DogeGamer
    on Oct 31, 2026 – with ChatGPT Codex Connector

    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.

  4. GameRipper665 commented on Nov 2, 2026

    @GameRipper665
    GameRipper665
    on Nov 2, 2026
    Author

    Seems to be fixed now, closing!

  5. GameRipper665
    closed this as completedon Nov 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions