[Feature]: add per-account Gem/Cla quota display for Google Antigravity

[agentHits]

Area

Authentication and account pool / provider quota UI

Current status

This request is partially implemented.

Current dev already contains a provider-level Google Antigravity quota probe.

For the currently active Antigravity credential, OpenCodex:

• calls the authenticated Cloud Code Assist fetchAvailableModels endpoint;
• classifies returned quota information into Gemini (Gem) and Claude (Cla) families;
• calculates used percentages;
• preserves reset timestamps when the upstream provides them;
• publishes the results through the normal provider quota surface.

Conceptually, the current result can contain:

Gem
  used %
  reset time

Cla
  used %
  reset time

The remaining gap is per-account quota visibility for users with multiple Google Antigravity accounts.

What remains missing

OpenCodex has a separate per-account quota path used by the account-management UI/API.

At present that path supports:

anthropic

but not:

google-antigravity

As a result, the active Antigravity provider can have useful Gem / Cla quota data while individual accounts in the Antigravity account list still lack their own quota rows.

This issue now tracks that missing per-account integration only.

Generic account selection, routing policy, automatic failover, and aggregated account-pool architecture belong to their parent issues and should not expand this scope.

Desired behavior

For every stored Google Antigravity account, OpenCodex should be able to fetch that account's own quota using:

• that account's OAuth credential;
• that account's Cloud Code Assist project ID;
• the same quota classification semantics already used by the provider-level Antigravity probe.

The result should be projected through the existing per-account quota contract.

For example:

Google Antigravity accounts

account A
  Gem   14% used · resets 20:15
  Cla   62% used · resets 18:42

account B
  Gem   3% used · resets 20:14
  Cla   9% used · resets 18:40

The exact presentation should follow the existing account quota UI.

Implementation boundary

1. Extend per-account quota support

The per-account quota capability should recognize:

google-antigravity

in addition to the providers already supported.

2. Use the selected account's credential

Do not implement the per-account path by calling the current active-provider helper.

Each row must be probed using the credential belonging to that specific account.

Otherwise every account could incorrectly display the active account's quota.

3. Use the account's project ID

The Antigravity quota RPC requires the Cloud Code Assist project associated with the account.

The per-account probe therefore needs the same account-scoped:

access token
projectId

pair.

If an account does not have a usable project ID or valid access token, its quota should be reported as unavailable rather than borrowing another account's state.

4. Reuse the existing Gem / Cla classification

Do not create a second interpretation of Antigravity quota data.

The per-account path should use the same family classification and percentage/reset normalization as the existing provider-level probe.

Expected window labels remain:

Gem
Cla

5. Handle partial upstream data

The upstream may expose:

• both Gem and Cla;
• only Gem;
• only Cla;
• a window without a reset timestamp.

All of those must be accepted.

Missing one family must not make the entire account quota probe fail.

6. Preserve account isolation

Quota cache entries must remain account-scoped.

Switching accounts, refreshing credentials, deleting an account, or replacing its identity must not allow quota data from one Antigravity account to appear under another.

Do not expose:

• refresh tokens;
• access tokens;
• project IDs;
• raw upstream quota payloads;

through the normal Dashboard/API result.

Provider-level behavior

The existing provider-level Antigravity quota path should remain functional.

This issue does not require removing or redesigning it.

The desired end state is:

provider overview
  -> current/active Antigravity quota

account management
  -> quota for each individual Antigravity account

Both should use the same quota semantics.

Relationship to other issues

#1062

Tracks broader Google Antigravity account-pool and management UX.

This issue remains the focused quota/status-display child.

#695

Tracks generic OAuth account-pool selection/failover architecture.

Automatic account selection and generic failover policy are out of scope here.

#1076

Tracks importing Antigravity accounts.

Account import is separate from displaying quota for accounts that already exist.

Acceptance criteria

• Active/provider-level Antigravity quota probe exists.
• Provider-level probe reports Gemini (Gem) quota.
• Provider-level probe reports Claude (Cla) quota.
• Provider-level quota preserves reset timestamps when available.
• google-antigravity is supported by the per-account quota path.
• Each account is probed with its own access token.
• Each account uses its own Cloud Code Assist projectId.
• Gem and Cla percentages are visible per account.
• Gem and Cla reset times are visible per account when supplied.
• Partial Gem-only / Cla-only responses work.
• A failed account probe does not break other accounts or normal routing.
• Quota cache state cannot cross account identities.
• No credential/project identifiers are exposed in normal API/UI output.
• Focused tests cover two different Antigravity accounts returning different quota values.

Checks

• Current dev quota implementation was re-audited.
• Already-delivered provider-level Gem/Cla support is removed from remaining scope.
• The remaining per-account boundary is explicitly identified.
• Per-account Google Antigravity quota support implemented.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[lidge-jun]

Keeping this open — quota/reset-time display is a good fit once the per-account data path exists. The related campaign PRs were closed with technical feedback (see #1084/#1083 threads): the blocker is that current drafts render UI over provider-aggregated data with no per-account runtime consumer. A slice that wires the quota probe data path first, then the display, is welcome.

[agentHits]

Keeping this open — quota/reset-time display is a good fit once the per-account data path exists. The related campaign PRs were closed with technical feedback (see #1084/#1083 threads): the blocker is that current drafts render UI over provider-aggregated data with no per-account runtime consumer. A slice that wires the quota probe data path first, then the display, is welcome.

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.

[Wibias]

This is not a chatting platform but an issue for a specific problem. If you got another problem open a new Issue for it.