Repository navigation
[Feature] Google Antigravity multi-account management, pool health and quota UX #1062
Description
Area
Authentication and account pool / Google Antigravity
Goal
Provide a first-class Google Antigravity / Gemini multi-account experience built on top of the shared OAuth account-pool runtime.
This issue tracks the Antigravity-specific account-management, quota, health, and user-interface surface.
Generic account selection and automatic failover policy is tracked separately in #695 and should be implemented once in the shared OAuth account-pool layer rather than duplicated here.
Current scope
This issue owns the provider-specific work required to make Google Antigravity accounts useful as a real multi-account pool:
- Antigravity multi-account management UX;
- Antigravity-specific account health integration;
- per-account quota/status presentation;
- pool-level Antigravity quota/status presentation;
- Antigravity management API/UI;
- wiring Antigravity accounts into the generic OAuth account pool.
It does not own the generic routing/failover algorithm.
1. Multi-account management
Users should be able to manage many Google Antigravity / Gemini accounts from one provider surface.
The UI/API should make it easy to:
- view all configured accounts;
- identify the currently assigned/active account where relevant;
- see account health;
- add or remove accounts;
- inspect quota/reset state;
- understand whether an account is ready, limited, cooling down, unavailable, or unknown.
The experience should remain practical with larger pools such as:
10–40+ accounts
Account identity and health state must remain isolated between accounts.
One account's quota, cooldown, project metadata, or failure state must never be projected onto another account.
2. Pool-level health and quota visibility
Provide an aggregate view of the Antigravity account pool.
Where the available provider evidence makes it meaningful, show information such as:
Ready accounts
Limited accounts
Cooling-down accounts
Unavailable accounts
Unknown-quota accounts
Upcoming reset windows
Aggregate values must not imply precision that the upstream data does not actually provide.
For example, an account with unavailable quota data must not silently contribute:
0% used
or be counted as healthy capacity merely because its quota could not be fetched.
Unknown must remain distinguishable from known-good.
3. Per-account quota visibility
Expose quota/limit information for each individual Antigravity account.
At minimum, the provider-specific data path should be able to represent:
- account health;
- quota usage;
- reset time;
- partial quota information;
- temporarily unavailable quota information;
- model-family-specific quota state where upstream data exposes it.
A failure to fetch one account's quota must not invalidate:
- other accounts;
- the whole pool;
- normal provider routing.
Likewise, one missing model family should not make all quota information for that account disappear.
4. Gem / Cla quota relationship
#1082 tracks the focused implementation for per-account Google Antigravity:
Gem
Cla
quota and reset-time information.
This issue should consume that data once available and integrate it into the broader Antigravity account/pool presentation.
Do not duplicate the Gem/Cla probing implementation here.
The expected composition is:
#1082
-> account-scoped Gem / Cla quota evidence
#1062
-> Antigravity account health + per-account presentation
-> pool-level health/quota summary
5. Generic failover relationship
Automatic account selection and failover belong to #695.
Antigravity should consume the shared OAuth-pool behavior defined there rather than introducing a second provider-specific routing algorithm.
Provider-specific Antigravity code should supply evidence such as:
account available
account limited
account cooling down
quota known
quota unknown
reset known
reset unknown
credential requires reauth
The generic pool can then make routing decisions according to the shared policy.
When the generic pool changes assignment because an Antigravity account is limited or unhealthy, the Antigravity UI should reflect the resulting state clearly.
6. Usage/account attribution
Per-account versus aggregate usage reporting was previously tracked in #1063 and has been consolidated into this issue.
The account-management surface should make it possible to understand which Antigravity account contributed usage where safe account attribution exists.
The presentation must not expose credential material or unsafe internal account identifiers.
Account attribution is a separate dimension from the date/model filtering tracked by #1058.
7. Large-pool usability
The UI should remain usable when dozens of accounts exist.
Avoid requiring the user to manually open every account simply to determine whether usable capacity remains.
A practical pool view should make it possible to answer questions such as:
How many accounts are ready?
Which accounts are currently limited?
Which accounts have unknown quota?
What are the next relevant reset windows?
Which account is currently assigned?
Does any healthy account remain available?
The exact layout can follow the existing provider workspace patterns.
Failure semantics
Provider-specific failures should remain localized.
Examples:
Quota endpoint unavailable
Account A -> quota unknown
Account B -> ready
Account C -> limited
Account A being unknown must not invalidate B or C.
Authentication failure
An account requiring reauthentication should be shown as unavailable/reauth-required rather than as quota exhausted.
Partial model-family response
If the upstream exposes Gemini quota but Claude quota is unavailable:
Gem -> known
Cla -> unknown
rather than treating the entire account as failed.
Missing reset time
Known usage without a reset timestamp should remain known usage with:
reset: unknown
not a fabricated reset.
Security and privacy
Normal Antigravity account-management responses must not expose:
- refresh tokens;
- access tokens;
- OAuth authorization material;
- Cloud Code Assist project IDs unless explicitly established as safe and required;
- raw provider quota payloads;
- arbitrary upstream error bodies.
Use bounded, normalized health/quota state in the management API.
Scope boundaries
This issue owns
- Antigravity multi-account management UX;
- Antigravity-specific account health integration;
- per-account health/quota/status presentation;
- pool-level Antigravity health/quota presentation;
- Antigravity management API/UI;
- integration of Antigravity accounts with the shared OAuth pool;
- consolidated per-account versus pool-level Antigravity usage/status UX.
Tracked separately
- [Feature]: Generic OAuth account-pool failover with session affinity and quota-aware selection #695 — generic OAuth account selection, session affinity, and automatic failover policy.
- [Feature]: add per-account Gem/Cla quota display for Google Antigravity #1082 — focused per-account Gem/Cla quota and reset-time implementation.
- [Feature]: safely import Cockpit Tools Google Antigravity accounts #1076 — Cockpit Tools Antigravity account import.
- [Feature] Let users define the priority order for automatic account failover in the Codex pool #821 — user-defined account priority ordering.
- [Feature]: opt-in crash-safe reset-credit auto-redemption before expiry #822 / [Research] Provider-specific post-reset activation to anchor quota windows #823 — reset-credit/reset-window lifecycle and account re-entry behavior.
- [Feature]: add single-day/custom date filtering and daily model metrics to Usage #1058 — date filtering and daily model-usage breakdown.
- [Feature]: display provider-reported subscription / plan renewal dates in Providers #1060 — subscription/plan expiration and renewal metadata.
Those issues should remain separate rather than being absorbed back into this umbrella.
Expected behavior
A user with many Google Antigravity accounts should be able to understand the state of the pool without manually opening every account.
The provider surface should clearly distinguish:
ready
limited
cooling down
unavailable
requires reauthentication
quota unknown
and should show whatever reliable quota/reset evidence exists for each account.
When generic OAuth-pool failover from #695 is available, Antigravity should plug into that shared runtime and reflect its assignment decisions without implementing competing routing policy.
Acceptance criteria
- Multiple Antigravity accounts can participate in the shared OAuth account pool.
- The Antigravity UI/API exposes each account's normalized health state.
- Per-account quota state can be represented without borrowing another account's data.
- Pool-level status summarizes ready, limited, cooling-down, unavailable, and unknown accounts.
- Missing quota data remains explicitly unknown rather than becoming zero or healthy capacity.
- Antigravity quota failures are isolated per account and, where possible, per model family.
- Missing quota/reset data does not invalidate the entire account pool.
- [Feature]: add per-account Gem/Cla quota display for Google Antigravity #1082's Gem/Cla information can be represented in the per-account view.
- Per-account versus aggregate usage/status information is understandable from the provider surface.
- The integration consumes [Feature]: Generic OAuth account-pool failover with session affinity and quota-aware selection #695 for selection/failover instead of implementing separate Antigravity routing logic.
- Account state cannot leak across account identities.
- Management responses do not expose credentials or raw sensitive provider data.
- The UI remains practical for pools with dozens of accounts.
- Focused API and GUI regression coverage exists.
- Accepted implementation is merged into
dev.
Checks
- [Feature Request] Separate Aggregated vs Per-Account Usage Statistics for Multi-Account Providers (Google Antigravity) #1063's account-statistics scope has been consolidated here.
- Generic failover ownership is assigned to [Feature]: Generic OAuth account-pool failover with session affinity and quota-aware selection #695.
- Focused Gem/Cla quota work remains in [Feature]: add per-account Gem/Cla quota display for Google Antigravity #1082.
- Cockpit Tools import remains in [Feature]: safely import Cockpit Tools Google Antigravity accounts #1076.
- Date filtering and subscription expiry remain separate concerns.
- Antigravity-specific pool health/quota integration is complete.
Activity
github-actions commentedon Aug 5, 2026
Automated translation bookkeeping — detected language: English.
github-actions commentedon Aug 5, 2026
Maintainer decision respected
A maintainer has reopened this issue. The automated closure has been deactivated.
lidge-jun commentedon Aug 6, 2026
Keeping this open — the idea is wanted. The draft PR attached to this campaign was closed with specific technical feedback (see the PR thread); the ideas stay tracked here. What gets a fast review: small, rebased, independently testable slices that wire the runtime/data path first and the UI second, one concern per PR.
agentHits commentedon Aug 6, 2026
I probably won't be able to write a PR correctly. I'd be grateful if you or other participants could take care of this. Let me be the one pitching the ideas, and you, as a professional, implement them.
lidge-jun commentedon Aug 6, 2026
Consolidation note: #1063 (per-account vs aggregated Usage statistics) is now closed into this issue. It restated the "Per-Account Level" half of point 2 above from the Usage tab, and its screenshots — 440 → 563 → 656 requests accumulating across two accounts with no breakdown — are the clearest statement of that problem, so treat them as the acceptance evidence for that part.
Still tracked separately, deliberately: #1058 (date filter and daily per-model breakdown — a time dimension, not an account one), #1060 (subscription plan expiry), #1082 (Gem/Cla quota in the status check), and #1076 (Cockpit account import). #695 also stays open for the generic failover policy, which now has concrete trigger, affinity, and unknown-quota rules from its reporter that this issue should reuse rather than redefine.
Scope of this issue is now: account pooling with automatic failover, plus pool-level and per-account quota statistics.
agentHits commentedon Aug 7, 2026
@lidge-jun Yes, you are absolutely thinking well, I really hope that you and your team, either together or separately, will be able to write an implementation of my idea in the coming days,
[-][Feature Request] Account Pooling, Auto-Failover & Aggregated Quota Tracking for Google Antigravity / Gemini[/-][+][Feature] Google Antigravity account pool, aggregated quota tracking and management UX[/+]Wibias commentedon Aug 7, 2026
Goal
Provide a first-class Google Antigravity / Gemini multi-account experience built on top of the shared OAuth account-pool runtime.
This issue tracks the Antigravity-specific account-management, quota, health, and user-interface surface.
Generic account-selection and automatic failover policy is tracked separately in #695 and should be implemented once in the shared OAuth account-pool layer.
What OpenCodex should provide
1. Multi-account management
Allow users to manage many Google Antigravity / Gemini accounts from one provider surface.
The UI/API should make it easy to:
This should remain usable with larger pools such as 10–40+ accounts.
2. Pool-level quota visibility
Provide an aggregate view of the Antigravity account pool.
Where upstream data makes it possible, show:
Aggregated values must not imply precision that the upstream quota data does not actually provide.
3. Per-account quota visibility
Expose quota/limit information for each account, including model-family-specific state where available.
At minimum, the Antigravity integration should be able to represent:
#1082 tracks the focused Gemini/Claude quota and reset-time display work.
4. Integration with generic failover
Antigravity should consume the shared failover/runtime behavior defined in #695 rather than creating a second Antigravity-specific routing implementation.
Provider-specific code should supply Antigravity account health/quota evidence to the generic pool and render the resulting state in the Antigravity UI.
Scope boundaries
This issue owns
This issue does not own
Expected behavior
A user with many Antigravity accounts should be able to understand the state of the pool without manually opening each account.
When the generic pool changes account assignment because an account is limited or unhealthy, the Antigravity UI should reflect that state clearly.
Unknown or partially available quota information should be shown as unknown/partial rather than silently converted into zero usage or healthy capacity.
Acceptance criteria
Related issues
[-][Feature] Google Antigravity account pool, aggregated quota tracking and management UX[/-][+][Feature] Google Antigravity multi-account management, pool health and quota UX[/+]Wibias commentedon Aug 16, 2026
Triage hierarchy
Treat this issue as the parent umbrella for Antigravity multi-account support.
#1082 should remain separately actionable because quota visibility can ship independently of the rest of the multi-account program.
lidge-jun commentedon Aug 19, 2026
리뷰 · 우선순위 56 / 80
현재
dev에서 Google Antigravity는 OAuth 프로바이더로 등록되어 있고, 계정 저장·전환·Cockpit Tools 가져오기(src/oauth/account-import/google-antigravity-adapter.ts)와 활성 자격 증명의 프로바이더 단위 Gem/Cla 프로브가 있습니다. 이 이슈는 그 조각 위의 우산입니다. 다중 계정을 풀처럼 보이게 하는 관리 UX, 건강 상태, 계정별/풀 쿼터 제시, 공유 OAuth 풀 연결을 모읍니다.이슈가 원하지 않는 것도 분명합니다. 일반 선택/페일오버 알고리즘은 #695이고, 계정별 Gem/Cla 가시성은 #1082입니다. 여기서 라우팅 정책을 다시 설계하거나 쿼터 자식을 닫으면 안 됩니다. 메인테이너 코멘트도 런타임/데이터 경로를 먼저, UI를 나중에, PR당 한 관심사로 하라고 했습니다.
코드 기준으로 지금 풀 경험은 불완전합니다. 계정 목록과 가져오기는 있으나, 계정별 쿼터 허용 목록은 anthropic뿐이고, 알 수 없는 쿼터를 준비된 용량으로 집계하는 풀 뷰는 확인되지 않았습니다. Usage 탭의 계정 간 요청 누적(#1063이 여기로 합쳐짐)도 같은 귀속 공백입니다. 한 계정의 쿨다운/프로젝트/실패가 다른 계정에 투영되면 네이티브 신뢰성이 깨집니다.
Windows/서비스보다 프로바이더 호환과 위생이 점수입니다. 10–40개 계정 UI는 있지만, 우산 이슈를 한 번에 구현하면 실패한 캠페인 PR과 같은 거대한 초안이 됩니다. 자식이 독립적으로 머지 가능해야 이 이슈가 줄어듭니다.
해결방안은 #1082 데이터 경로, 계정 건강 분류, 풀 집계(unknown ≠ 0%), Usage 계정 귀속을 따로 올리는 것입니다. 일반 페일오버는 #695가 끝날 때까지 복제하지 않습니다. 패치는 추측하지 않으며, 현재 트리를 Antigravity 풀 UX 완료로 보지 않습니다.
이 댓글은 grok-bot이 작성했습니다
fix(cursor): close HTTP/2 after turnEnded so a held-open response can…
fix(cursor): close HTTP/2 after turnEnded so a held-open response can…
fix(cursor): close HTTP/2 after turnEnded so a held-open response can…
fix(cursor): fail silent and heartbeat-only streams at the transport …
agentHits commentedon Aug 31, 2026
@lidge-jun Hello can you write code this PR ?
lidge-jun commentedon Sep 3, 2026
Closing in favor of #3375, which carries the remaining scope forward.
Thank you @agentHits — this report on Google Antigravity multi-account management, pool health and quota UX was accurate, and part of it shipped.
What landed. Multi-account listing/import and per-account quota shipped (
src/providers/quota.ts,gui/src/components/provider-workspace/ProviderAuthPanel.tsx).What is still missing. aggregate pool health and capacity UX, account-attributed usage, and complete shared-pool integration.
Rather than leave four issues open each describing one facet of the same unfinished lifecycle, the surviving scope is consolidated in #3375, which names this issue and credits you for the original analysis. Please follow and comment there; if you think the consolidation dropped something you asked for, say so on #3375 and it will be added.
fix(cursor): close HTTP/2 after turnEnded so a held-open response can…
fix(cursor): fail silent and heartbeat-only streams at the transport …