You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Individual-quota 429 'Resets in 4h9m10s' is not parsed; the account is retried on the default backoff #39
extractRateLimitBodyInfo reads the reset time from the error message with /reset after\s+([0-9hms.]+)/i only. Google's individual-quota 429 uses a different phrase, so no reset is found:
Individual quota reached. Please upgrade your subscription to increase your limits. Resets in 4h9m10s.
The plugin then applies its default backoff (default_retry_after_seconds) and retries an account whose quota is hours away.
Still present on main (v3.0.4): packages/opencode/src/plugin/shared/request-services.ts, extractRateLimitBodyInfo, the afterMatch line. Observed on 2.2.1: 3 such errors in two sessions, 3 s apart (2026-09-16).
Exact error message
{
"error": {
"code": 429,
"message": "Individual quota reached. Please upgrade your subscription to increase your limits. Resets in 4h9m10s. [Debug Info] Requested Model: antigravity-gemini-3.8-flash",
"status": "RESOURCE_EXHAUSTED"
}
}
Steps to reproduce
Receive a 429 with the body above (no RetryInfo or quotaResetDelay in details).
Expected: the account/model cooldown is about 4 h 9 min.
Actual: retryDelayMs is null, so the cooldown comes from the default backoff and the account is retried.
Thanks. The response you posted is enough to confirm the problem. The plugin recognizes "reset after" but not "Resets in 4h9m10s", and that's still true in 3.0.10. When the response has no retry header and no structured delay, the plugin waits only its configured fallback interval instead of the reset time in the message, so it can retry too early.
We're adding the "reset in" and "resets in" forms, with a test that uses your exact response. We're also checking that the account stays unavailable for that model until the reset time, without making a request wait longer than its configured limit. We don't need any further logs or account information.
Fixed in 3.0.11. "Resets in 4h9m10s" (and "reset in") is now understood. That account stays unavailable for that model until the stated reset, and your other accounts keep serving in the meantime. Please upgrade.
Activity
agauth-alfonso commentedon Oct 23, 2026
Thanks. The response you posted is enough to confirm the problem. The plugin recognizes "reset after" but not "Resets in 4h9m10s", and that's still true in 3.0.10. When the response has no retry header and no structured delay, the plugin waits only its configured fallback interval instead of the reset time in the message, so it can retry too early.
We're adding the "reset in" and "resets in" forms, with a test that uses your exact response. We're also checking that the account stays unavailable for that model until the reset time, without making a request wait longer than its configured limit. We don't need any further logs or account information.
Merge: honor "Resets in" quota reset text and hold the account model …
agauth-alfonso commentedon Oct 23, 2026
Fixed in 3.0.11. "Resets in 4h9m10s" (and "reset in") is now understood. That account stays unavailable for that model until the stated reset, and your other accounts keep serving in the meantime. Please upgrade.