[Bug]: Antigravity usage shows a rolling reset countdown for untouched quota buckets #22815

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Sign in to Antigravity in T3 Code with a personal Google account. Leave one quota group untouched (here: no Claude/GPT use through Antigravity, so the 3p-5h and 3p-weekly buckets are full).
2. Open Usage → Limits and look at the Claude & GPT (shared) rows.
3. Check again after the next quota refresh.

Expected behavior

An untouched bucket shows 100% left without a reset countdown, as the native Antigravity app does: it shows only "100%" for these rows and shows a reset time only for buckets that have been used.

Actual behavior

T3 shows "resets in 4h 59m" and "resets in 6d 23h" next to 100% left. The countdown never runs down; every probe moves it back to a full window.

For an untouched bucket, retrieveUserQuotaSummary returns a resetTime equal to the request time plus the full window. quotaWindow passes every resetTime through as resetsAt, and the limits UI renders any resetsAt as a countdown.

Measured on daily-cloudcode-pa.googleapis.com with current main's User-Agent:

Used buckets behave differently. In the same requests, gemini-5h and gemini-weekly kept fixed reset times (13:29:53 and 2026-10-28 08:29:53) and carried a description such as "You have used some of your 5-hour limit, it will fully refresh in 3 hours, 13 minutes." Untouched buckets have no description.

This is separate from #21115 / #21361, which change which buckets the summary returns. The 3p-* buckets are already returned, and with #21361's identity they still come back with resetTime = request time + window (same values as above at 10:16 UTC).

Impact

Minor bug or occasional failure

Version or commit

v0.1.1 (fe27e8e3dc); quotaWindow is unchanged on main (e27a03e94d).

Environment

macOS arm64, T3 Code desktop v0.1.1, Antigravity ACP runtime 1.3.0, personal Google sign-in.

The T3 screenshot comes from my Simplified Chinese build of v0.1.1. That build translates display strings in apps/web and apps/desktop, and lays out Usage → Limits as one column per account, so the row layout differs from stock. The reset text still comes from upstream formatResetsIn, and apps/server/src is identical to the v0.1.1 tag. The rows read "100% left" and "resets in 4 h 59 min" / "resets in 6 d 23 h".

To rule the build out, I also ran unmodified v0.1.1 antigravityUsageLimits.ts with a stub HttpClient (same setup as antigravityUsageLimits.test.ts) returning the 10:16 UTC payload below. The probe returns 3p-5h with usedPercent: 0, resetsAt: "2026-10-21T15:16:05.000Z" and 3p-weekly with usedPercent: 0, resetsAt: "2026-10-28T10:16:05.000Z".

Logs or stack traces

# 2026-10-21T10:16:04Z, daily-cloudcode-pa, v1internal:retrieveUserQuotaSummary
# untouched buckets: no description, resetTime = request time + window
{"bucketId":"3p-5h","window":"5h","remainingFraction":1,"resetTime":"2026-10-21T15:16:05Z"}
{"bucketId":"3p-weekly","window":"weekly","remainingFraction":1,"resetTime":"2026-10-28T10:16:05Z"}
# used buckets (#21361 identity): fixed resetTime and a description
{"bucketId":"gemini-5h","window":"5h","remainingFraction":0.848104,"resetTime":"2026-10-21T13:29:53Z","description":"You have used some of your 5-hour limit, it will fully refresh in 3 hours, 13 minutes."}
{"bucketId":"gemini-weekly","window":"weekly","remainingFraction":0.9620177,"resetTime":"2026-10-28T08:29:53Z","description":"You have used some of your weekly limit, it will fully refresh in 6 days, 22 hours."}

No credentials, project IDs or account identifiers are included.

Screenshots, recordings, or supporting files

T3 Code, Usage → Limits (2026-10-21 ~08:57 UTC):

Native Antigravity app, same account (~09:00 UTC). The Claude and GPT rows show no reset time:

Workaround

None upstream. Locally I drop resetsAt only when remainingFraction is exactly 1, the bucket has no description, and resetTime is within 60 seconds of the request time plus the window. Measured resets and buckets with a description are kept. I can open a PR if this direction is acceptable, or follow a different rule you prefer.