OAuth quota probe failures lack actionable diagnostics while account health remains healthy

Read src/oauth/health.ts, src/providers/quota.ts, src/providers/quota/anthropic-account-quota.ts, and src/server/management/oauth-account-routes.ts to trace how probe failures become account response fields. Start by comparing the Antigravity and Anthropic failure paths, then use synthetic adapter failures to check which causes are known and exposed. Done means diagnostics distinguish known failure types safely while transient quota failures leave credential health unchanged.

Client or integration

Direct HTTP/API client

Area

Provider adapter

Summary

OAuth quota probe failures lack actionable diagnostics while account health remains healthy. The API can report an unavailable quota without identifying whether the failure calls for reauthentication, verification, retry, or another action. Credential health and quota availability should remain separate; transient quota failures must not automatically mark credentials invalid.

Reproduction

Observed on an existing OAuth account pool; the original failed Antigravity account has since been removed by its owner, so this is not claimed to be a deterministic fresh-account reproduction.

1. Configure Antigravity and Anthropic OAuth accounts on an OpenCodex hub.
2. Using an authorized management API client, issue GET requests to /api/oauth/accounts?provider=google-antigravity&quota=1 and /api/oauth/accounts?provider=anthropic&quota=1.
3. In the observed failure state, HTTP 200 responses contained health.status=healthy together with quotaUnavailable=true; Antigravity additionally returned quotaFailure=account_unavailable, while Anthropic supplied no actionable reason.
4. Compare credential-health fields and quota-probe diagnostics. The response does not establish which recovery action is appropriate.

No refresh=1 was used; results may include cached measurements. No generation request or deliberate account failure was induced. Synthetic adapter failures are proposed for maintainer-side regression testing below.

Version

Live observation: 2.83.0, installed checkout 33b321853aff76045617824793cc7cbc1d4084e7. Current upstream source inspected at dd2bdd2fe3ff6fc2d75019c8b7dc201b835b4109; live reproduction on that commit has not been performed.

Operating system

Ubuntu 26.04 LTS, x86_64; OpenCodex deployed in Docker.

Provider and model

Google Antigravity and Anthropic OAuth. Per-account quota endpoints; no particular model or generation request is involved.

Logs or error output

Selected anonymized API diagnostics (not complete raw responses):

{
  "antigravity": {
    "paused": false,
    "health": {"status": "healthy"},
    "quotaMode": "probe",
    "quotaUnavailable": true,
    "quotaFailure": "account_unavailable"
  },
  "anthropic": {
    "paused": false,
    "health": {"status": "healthy"},
    "quotaMode": "probe",
    "quotaUnavailable": true
  }
}

No actionable reauthentication reason was present in the captured Anthropic response. Missing fields are not interpreted as explicit false.

Screenshots and supporting files

No raw screenshots or account dumps are attached because they contain private account identifiers. Detailed anonymized observations, source references and validation scenarios follow.

Redacted configuration

Existing hub with OAuth-authenticated google-antigravity and anthropic providers, per-account quota mode probe. No configuration-specific root cause has been established. Credentials, hostnames and account identifiers are intentionally omitted.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

---

Detailed investigation

Summary

The OAuth account API can return health.status: "healthy" together with an unavailable quota probe, without enough information to determine whether the account needs reauthentication, provider verification, a retry, or no credential action at all.

This is a request to preserve actionable quota-probe diagnostics, not to equate every quota failure with an unhealthy credential or to set needsReauth on network errors.

Environment and evidence boundaries

• Live observations: OpenCodex 2.83.0, installed checkout 33b321853aff76045617824793cc7cbc1d4084e7.
• Providers: Google Antigravity and Anthropic OAuth.
• Repeated management API reads returned HTTP 200.
• Requests used quota=1, without refresh=1. These observations are not an atomic snapshot or proof that a fresh upstream probe ran for every request.
• No inference here depends on the Android client's presentation. The contradictory/underspecified fields below were read directly from OCX.
• Current upstream source was inspected at dd2bdd2fe3ff6fc2d75019c8b7dc201b835b4109; similar diagnostic-loss paths still exist there. Live reproduction on that commit has not been performed.

Observed API responses (anonymized diagnostic excerpts)

GET /api/oauth/accounts?provider=google-antigravity&quota=1 included an account with:

{
  "id": "account-A",
  "paused": false,
  "health": { "status": "healthy" },
  "quotaMode": "probe",
  "quotaUnavailable": true,
  "quotaFailure": "account_unavailable"
}

GET /api/oauth/accounts?provider=anthropic&quota=1 included:

{
  "id": "account-B",
  "paused": false,
  "health": { "status": "healthy" },
  "quotaMode": "probe",
  "quotaUnavailable": true
}

These are selected diagnostic fields, not complete raw responses. For Anthropic, no actionable quotaFailure / reauthentication reason was returned in the captured response. Missing fields must not be interpreted as explicit false.

The operator reported both accounts as unusable, but the specific upstream causes (suspension vs expired credentials vs verification vs another failure) were not independently established. In particular, these responses do not prove that re-login would fix either account.

The operator subsequently removed account-A. Comparing exact IDs before/after confirmed that this was the account with quotaFailure: "account_unavailable"; the Antigravity pool changed from two accounts to one, and the remaining account returned quotaUnavailable: false. Anthropic remained unchanged. Deleting an account is not proposed as a reproduction step or remedy.

Relevant source

• projectOAuthAccountHealth defaults to healthy when no stored reauth/cooldown/warning state is known. That may be correct for credential/routing health, but it does not establish probe success.
• Antigravity account quota handling: the general exception handler maps failures to account_unavailable, making different exception causes indistinguishable to an API consumer.
• Anthropic account quota handling: some failure paths return unavailable/publish(null), without a comparable actionable failure code in the account response.
• OAuth account response projection exposes health and quota availability separately.

Expected behavior / suggested direction

Keep credential/routing health separate from quota-probe status, but expose enough bounded, sanitized metadata for clients to explain the situation:

1. Last probe outcome and timestamp/freshness, including whether the result is cached.
2. Distinguishable reasons where known: unauthorized/expired credential, forbidden/provider verification, rate limit, transport failure, upstream failure, missing required account metadata, or unknown/unavailable.
3. An optional safe recommended action where supported by evidence: retry later, verify with provider, reauthenticate, or inspect configuration.
4. Do not mark every unavailable quota as reauth_required. Only propagate credential rejection into reauth state when the underlying result establishes that.
5. Document that health: healthy means no known stored account-health problem, not a successful current quota probe.

Exact field names are only suggestions; maintaining the existing API shape while improving diagnostic codes/documentation would also help.

Validation scenarios

Provider adapters can be tested with synthetic failures; no real account deletion is necessary:

• expired/rejected credential vs timeout produce distinct safe diagnostics;
• verification-required is not mislabelled as a generic network error;
• transient quota failure does not falsely set reauth state;
• Anthropic exposes a reason when the adapter knows one;
• stale/cached quota and its latest probe failure remain distinguishable;
• diagnostic fields never contain tokens, cookies, email addresses, raw response bodies or authorization URLs.

Related, but not identical

• #1062 — broader Antigravity account/pool-health and quota UX.
• #2566 — exposing per-account Anthropic quota in the CLI.
• #3644 — Codex plan/quota missing after an otherwise healthy login.

This report is specifically about loss/ambiguity of per-account quota-probe diagnostics across providers. If already tracked under one of those, linking/closing as a duplicate is welcome.