OpenCode retry loop hammers rate limits when the provider returns 529

Symptoms

During an Anthropic capacity event, OpenCode sessions went into a hot loop: `anthropic error (529): overloaded_error` scrolling continuously, ~4-5 retries per second, no delay between attempts. The TUI shows 'retrying...' as if it's being patient; the debug log shows it isn't. Left unattended, one session fired 2,600 requests in 10 minutes. Two of us then hit account-level rate limiting that outlived the capacity event, and on token-billed keys the retried request bodies aren't free either.

Likely cause

The provider adapter in ≤0.6.1 treated 529 as a retryable transport error and reused the generic retry path, which had `delay: 0` for 'connection-level' failures. 429s had backoff; 529s slipped into the wrong class. Fixed in 0.6.2 by classifying 429/529 together with exponential backoff, jitter, and honoring retry-after when present.

Affected

0.5.x – 0.6.1; fixed in 0.6.2

Environments

Anthropic provider (API key and OAuth both); other providers' overload codes were already classified correctly · macOS, Linux, Windows

Confidence

High confidence · verified Jul 27, 2026

Upgrade to 0.6.2

0.6.2 classifies 529 alongside 429 with exponential backoff (1s base, x2, jitter, 60s cap) and honors retry-after. Upgrade and verify; if you're stuck on an older build, cap retries in config as a stopgap.

01

Upgrade and confirm:

opencode upgrade && opencode --version

Copy

02

Verify the backoff behaviour in the debug log next time the provider blips — you want to see increasing delays, not a wall of instant retries:

grep -E 'retry(ing)? in [0-9]+' ~/.local/share/opencode/log/latest.log | tail

Copy