Repository navigation
Anthropic overloaded_error is not retried, halts session #20384
Description
Bug description
When the Anthropic API is at capacity, it returns a stream error:
{"type":"overloaded_error","message":"Overloaded"}This error is not recognized as retryable. The session halts with a terminal UnknownError instead of retrying with exponential backoff.
Steps to reproduce
- Use an Anthropic model (e.g., claude-opus-4-6)
- Send a request when the API is under heavy load
- Observe the session stops with
{"type":"overloaded_error","message":"Overloaded"}displayed as a raw JSON error
Expected behavior
The error should be classified as a retryable API error, triggering the existing exponential backoff retry logic (2s → 4s → 8s → 16s → 30s cap), similar to how too_many_requests and rate limits are handled.
Actual behavior
The error falls through parseStreamError() (which only handles body.type === "error", not "overloaded_error"), becomes a NamedError.Unknown, and retryable() does not match it — the session halts.
Environment
- OpenCode version: 1.3.6
- Provider: Anthropic (via custom gateway)
- Model: claude-opus-4-6
- OS: macOS
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 1, 2026
This issue might be a duplicate of existing issues. Please check:
There are also several previously closed issues on this same topic (#163, #833, #1057, #1318) which may be worth reviewing to understand prior fix attempts.
OliPetry commentedon Apr 1, 2026
This is related to #19394 but covers a different code path:
Anthropic 5xx errors incorrectly marked non-retryable, stopping agent loop #19394 addresses HTTP 5xx errors (e.g.,
statusCode: 500) whereAPICallError.isRetryableis incorrectlyfalsebecause the AI SDK only sets it totrueforoverloaded_errortype. The fix is inparseAPICallError/retry.tsfor status-code-based errors.This issue (Anthropic overloaded_error is not retried, halts session #20384) addresses SSE stream errors where Anthropic sends
{"type":"overloaded_error","message":"Overloaded"}directly in the event stream. These go throughparseStreamError()inerror.ts, which only matchedtype === "error"— sooverloaded_errorfell through entirely and becameNamedError.Unknown.The two fixes are complementary — #19394's suggested fix (override
isRetryablefor 5xx status codes) wouldn't catch this case because stream errors don't carry an HTTP status code. The PR (#20373) addsoverloaded_errorhandling specifically inparseStreamError().