Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#22,815 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
77/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend

Research direction

Start with apps/server/src/provider/antigravityUsageLimits.ts, especially quotaWindow, and compare its handling of untouched buckets with the payload’s used buckets. Read the related antigravityUsageLimits.test.ts and add coverage for the reported untouched 3p-5h and 3p-weekly responses. Done when those full buckets no longer show a misleading countdown while used buckets retain their reset times.

Written by the indexing model from the issue text.

Description

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:

Requested at (UTC, ±1 s) 3p-5h resetTime 3p-weekly resetTime
2026-10-21 09:03:08 2026-10-21 14:03:08 2026-10-28 09:03:08
2026-10-21 10:16:04 2026-10-21 15:16:05 2026-10-28 10:16:05

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

T3 Code: Claude & GPT (shared) 5-hour and weekly at 100% left with 4h 59m and 6d 23h reset countdowns

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

Antigravity app: Gemini rows show reset times, Claude and GPT rows at 100% show none

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.

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
3h 39m
Merged PRs (30d)
301

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.