[Bug]: Antigravity Gemini quota reads 100% with the legacy User-Agent (follow-up to #21115)#22876

opened9d agobyMmarkshan00

Opening this focused follow-up as requested in the closing comment on #21115. This report covers the remaining Antigravity Gemini quota request-identity problem. The stale-probe issue addressed by #18723 and the untouched-bucket countdown issue in #22815 are separate.

Before submitting

I searched existing issues. The matching reports #21115, #16104, #20228 and #21890 are closed; I did not find an open issue dedicated to this remaining problem.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Sign in to Antigravity through T3 with a personal Google account that has partially consumed Gemini five-hour and weekly quotas.
Open Usage → Limits and compare the Gemini rows with the native Antigravity app for the same account.
To isolate the request identity, compare POST https://daily-cloudcode-pa.googleapis.com/v1internal:retrieveUserQuotaSummary using the same OAuth credential and the same request body, changing only the User-Agent version from antigravity/hub/1.0.0 to antigravity/hub/2.24.0 and keeping the rest of the header identical.

Expected behavior

T3 shows the actual remaining Gemini five-hour and weekly quotas for this account. Changing the probe's client identity should not be necessary to retrieve the consumed quotas.

Actual behavior

On the affected v0.1.1 build, T3 showed Gemini at 100% remaining while the native app showed consumed quota.

The old User-Agent omits the Gemini group from the daily host's summary. The production host can return Gemini buckets as unused for this consumer account. Merging both hosts therefore does not recover the real Gemini reading if the daily response never contains it.

I checked upstream main at 448b8a918694e84137f850c6526d75aacfb2292d on 2026-10-21:

The probe still sends antigravity/hub/1.0.0.
It already queries both hosts and keeps the most-used value for each bucket. This report does not rely on the older first-nonempty-host behavior described in #21115.
It uses the model-quota fallback only when the combined summary is empty. The returned Claude/GPT buckets keep that summary nonempty even when the real Gemini readings are missing.
The entire antigravityUsageLimits.ts file is byte-for-byte identical between v0.1.1 and that main commit (Git blob 55ef3579942fb0b31d2f7174804b3ab78ee61b81).

Impact

Minor bug or occasional failure

The Limits panel cannot reliably indicate how much Gemini quota remains on the affected account.

Version or commit

Original reproduction: v0.1.1 (fe27e8e3dc12dcbb108e9a28fd9b8cb65f34ae92).

Current source verification: main 448b8a918694e84137f850c6526d75aacfb2292d.

Environment

macOS arm64, desktop, Antigravity ACP runtime 1.3.0 installed by T3, personal Google sign-in (oauth-personal).

The original UI observation was in my Simplified Chinese build of v0.1.1, before my local quota fix; its server source was identical to upstream v0.1.1. The HTTP comparisons below bypass the UI. I now use a locally patched build; I have not installed and tested the latest upstream nightly UI. The current-main check above is source verification, not a new end-to-end nightly test.

Logs or stack traces

Live requests captured on 2026-10-21 at 10:16 UTC, previously posted in my verification comment. They used the same credential and project body; all responses were HTTP 200. Fractions below are remaining, not used.

Host	User-Agent identity	Gemini 5h	Gemini weekly	Claude/GPT 5h / weekly
daily	`hub/1.0.0` (current upstream)	absent	absent	1 / 1
daily	`hub/2.24.0`	0.848104	0.9620177	1 / 1
daily	ACP identity from #21361, darwin/arm64	0.848104	0.9620177	1 / 1
production	ACP identity from #21361, darwin/arm64	1	1	1 / 1

Exact compared headers:

text

1	antigravity/hub/1.0.0 (aidev_client; os_type=darwin; arch=arm64; cl=963137146)
2	antigravity/hub/2.24.0 (aidev_client; os_type=darwin; arch=arm64; cl=963137146)
3	antigravity/acp/1.3.0 (aidev_client; os_type=darwin; arch=arm64; host_path=t3-code/0.1.0; proxy_client=antigravity/sdk)

The two consumed Gemini buckets also reported fixed reset times of 2026-10-21T13:29:53Z and 2026-10-28T08:29:53Z. Business/Workspace accounts and accounts with an Argon quota were not tested. No credentials or account-specific project identifiers are included.

Workaround

Changing only the hub version to 2.24.0 returns the consumed Gemini quotas on the daily host in the comparison above. The ACP identity proposed in #21361 also works for this account.

Related implementation work already exists in #21361 and #21020; both remain open and unmerged at filing. This issue is the focused tracker requested by the maintainer, with account evidence for the remaining request-identity defect.

DDavidCzartoryski9d ago

I'm seeing the same thing on the current nightly desktop build. Here the Gemini rows don't show at 100%. They're missing completely.

Environment: T3 Code (Nightly) 0.0.46-nightly.20261015.3145, macOS arm64, desktop, personal Google account. For comparison: Antigravity CLI (agy) 1.4.4, same account.

Same account, checked a few minutes apart:

Bucket	T3 Code `Usage → Limits → Antigravity`	`agy` Models & Quota
Gemini · 5-hour	not shown	65.64% remaining, refreshes in 1h 33m
Gemini · Weekly	not shown	85.23% remaining, refreshes in 154h 11m
Claude & GPT (shared) · 5-hour	100% left, resets in 4h 59m	100.00%, quota available
Claude & GPT (shared) · Weekly	100% left, resets in 6d 23h	100.00%, quota available

Every model I've used goes through the Gemini group. The panel shows only the two untouched Claude & GPT buckets, so Antigravity looks like it has its full quota.

I checked the antigravityUsageLimits code bundled in this nightly's app.asar:

It still sends antigravity/hub/1.0.0 (aidev_client; os_type=darwin; arch=arm64; cl=963137146).
fetchWindows tries daily-cloudcode-pa and then cloudcode-pa, and it returns the first host that gives any windows instead of merging the two.
The daily host's hub/1.0.0 summary leaves out the Gemini group but still returns Claude/GPT buckets (your table above). The probe stops there, so the production host's response and the fetchAvailableModels fallback are never used, and the Gemini rows never appear.

So this nightly seems older than main, where the results from both hosts are merged. It's the same User-Agent problem either way. I didn't capture the raw HTTP responses from this machine.

Ssio-funmatsu9d ago

Additional data point: the cl= value in the User-Agent also gates the Gemini group, independently of the version string.

Environment: T3 Code nightly 0.1.2-nightly.20261021.3499 (Linux x64 / WSL2). The probe UA is still antigravity/hub/1.0.0 (...; cl=963137146) in 3457, 3486 and 3499. Antigravity CLI agy 1.4.5 uses antigravity/cli/1.4.5 (aidev_client; os_type=linux; arch=amd64; cl=1004422050; auth_method=consumer).

Test: POST https://daily-cloudcode-pa.googleapis.com/v1internal:retrieveUserQuotaSummary with the same OAuth credential and the same body ({"project":"aicode-consumers"}), varying only the User-Agent:

User-Agent	Gemini buckets returned
`antigravity/hub/1.0.0 (...; cl=963137146)` (current T3)	missing (only `3p-*`)
`antigravity/hub/2.24.0 (...; cl=963137146)` (#23011)	`gemini-weekly` 0.634, `gemini-5h` 0.963
`antigravity/hub/1.0.0 (...; cl=1004422050)`	`gemini-weekly` 0.634, `gemini-5h` 0.963
`antigravity/cli/1.4.5 (...; cl=963137146; auth_method=consumer)`	`gemini-weekly` 0.634, `gemini-5h` 0.963

The values match agy's Models & Quota screen. The production endpoint (cloudcode-pa.googleapis.com) returned remainingFraction: 1 for both Gemini buckets with every UA above.

So #23011's version bump fixes it for this account. The server appears to treat a client as legacy only when both the version and cl are old, which suggests cl is part of the gate. A future cutoff could depend on either value, so it may be worth keeping both in sync with a current Antigravity build.

Ccornishandy5d ago

Still happening on T3 Code (Nightly) 0.1.3-nightly.20261025.3682, macOS arm64. The probe still sends antigravity/hub/1.0.0 (aidev_client; …; cl=963137146).

Same OAuth credential and request body, POST /v1internal:retrieveUserQuotaSummary, 25 Oct 2026, changing only the version in the User-Agent (cl= left at 963137146):

User-Agent version	`daily-cloudcode-pa`	`cloudcode-pa`
`1.0.0`	`3p-weekly`, `3p-5h` only	`3p-weekly`, `3p-5h` only
`2.24.0`	adds `gemini-weekly` (6.3% used) and `gemini-5h` (7.9% used)	adds `gemini-weekly` (5.8% used) and `gemini-5h` (7.1% used)

So on this account the version string alone is enough. The old header returned only 3p-* buckets, which T3 labels "Claude & GPT (shared)" in its code; I did not inspect the pre-patch Limits screen. Because the 3p-* buckets keep the summary non-empty, the fetchAvailableModels fallback never runs either.

Changing only antigravity/hub/1.0.0 to antigravity/hub/2.24.0 in the installed bundle and restarting T3 restored Gemini windows in T3's stored provider usage: 9.61% used for five-hour and 6.97% for weekly, with reset times matching Google's gemini-5h and gemini-weekly buckets.

Ee-kotov1d ago

Additional read-only confirmation on 2026-10-29, macOS arm64, using the personal-Google credential already stored by T3's managed ACP login (installed runtime 1.3.0). No agy CLI or ACP process is needed for the probe.

With the same OAuth credential, project body, daily quota endpoint, and fixed suffix (aidev_client; os_type=darwin; arch=arm64; cl=963137146):

antigravity/hub/1.0.0 returned only 3p-weekly and 3p-5h.
antigravity/acp/1.0.0, antigravity/acp/1.3.0, and antigravity/acp/1.4.1 each returned those buckets plus gemini-weekly, gemini-5h, and gemini-argon-wtu-weekly.
The Argon bucket arrived in a separate group named Gemini 4 Argon, with approximately 1.23% remaining. Treating every gemini- prefix as the ordinary Gemini group hides that distinction.

This shows that an ACP identity works at all three tested versions for this account today; it does not establish a universal or permanent server rule. Reading the actual selected runtime's recorded version avoids another stale literal. I also verified the proposed ACP header without the obsolete cl field returns all five buckets.

The fork fix is e-kotov/t3code#17. It resolves the runtime version using the provider's configured environment, labels Argon separately, and disables the per-model fallback in production so missing quota-summary data does not become a plausible-looking 100% reading. CI and browser evidence are pending; this comment reports the direct API observations, not a newly installed upstream UI test.