Skip to content

Individual-quota 429 'Resets in 4h9m10s' is not parsed; the account is retried on the default backoff #39

Closed

Description

@willowite

Bug description

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

  1. Receive a 429 with the body above (no RetryInfo or quotaResetDelay in details).
  2. Expected: the account/model cooldown is about 4 h 9 min.
  3. Actual: retryDelayMs is null, so the cooldown comes from the default backoff and the account is retried.

Proposed change

-const afterMatch = message.match(/reset after\s+([0-9hms.]+)/i)
+const afterMatch = message.match(/(?:reset after|resets? in)\s+([0-9hms.]+)/i)

parseDurationToMs already handles the compound 4h9m10s.

Environment

  • Model: antigravity-gemini-3.8-flash
  • Plugin version: 2.2.1 (the parsing line is unchanged in 3.0.4)
  • OpenCode version: 1.19.0
  • OS: Windows 11, Node.js v24.21.0, standard native terminal
  • Google accounts configured: 1
  • Reproducibility: always for this message text
  • Debug logs: the error body above is the relevant excerpt from the plugin's debug log; the full log holds account details and is not attached.
  • Personal development use only.

Activity

  1. agauth-alfonso commented on Oct 23, 2026

    @agauth-alfonso

    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.

  2. agauth-alfonso commented on Oct 23, 2026

    @agauth-alfonso

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions