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
When the Anthropic API returns a 500 Internal Server Error via SSE stream, the agent loop stops immediately instead of retrying.
Root Cause
The Vercel AI SDK's Anthropic provider creates APICallError with isRetryable: error.type === 'overloaded_error' for SSE-delivered errors. This means internal_server_error (HTTP 500) is marked isRetryable: false.
In packages/opencode/src/provider/error.ts, parseAPICallError passes this through directly for non-OpenAI providers:
Then in packages/opencode/src/session/retry.ts (line 65):
if(!error.data.isRetryable)returnundefined
Returning undefined means "don't retry", so the processor stores the error and stops the loop.
Impact
Any Anthropic API 500 error kills the agent session. Users see AI_APICallError: Internal server error and the loop halts. This is especially disruptive during periods of API instability.
Note: OpenAI errors are handled separately with isOpenAiErrorRetryable() which correctly retries server errors. Only non-OpenAI providers are affected.
Evidence
From production logs — all 6 occurrences show statusCode: 500, isRetryable: false:
AI_APICallError: Internal server error
url: https://api.anthropic.com/v1/messages
statusCode: 500
isRetryable: false
Suggested Fix
In error.ts, add a server error check that overrides the SDK's isRetryable for any 5xx status:
This issue might be a duplicate of existing issues. Please check:
fix: 5xx errors from non-standard providers are not retried #19203: Very similar — also addresses 5xx errors not being retried due to isRetryable handling in non-OpenAI providers, and proposes the same fix of classifying any HTTP >= 500 as retryable regardless of SDK-reported value.
Both paths can produce the same symptom (5xx kills the session), but fixing only one still leaves the other unfixed. For example, OpenRouter returns 502s as UnknownError with {"code":502,"message":"Network connection lost.","metadata":{"error_type":"provider_unavailable"}} — even if isRetryable is corrected for APICallError, these errors bypass that code path entirely and need the fromError() classification that PR #19204 provides.
Related: #22448 documents the OpenRouter-specific gap where code (numeric) and metadata.error_type aren't checked by PR #19204's current JSON fallback either.
Activity
github-actions commentedon Mar 27, 2026
This issue might be a duplicate of existing issues. Please check:
isRetryablehandling in non-OpenAI providers, and proposes the same fix of classifying any HTTP >= 500 as retryable regardless of SDK-reported value.Please review those issues to see if they cover your case, and consider whether this can be consolidated.
tim-mohrbach-ikigai commentedon Apr 14, 2026
These two fixes are complementary rather than overlapping:
This issue (Anthropic 5xx errors incorrectly marked non-retryable, stopping agent loop #19394) addresses
APICallErrorinstances whereisRetryableis incorrectlyfalsefor 5xx responses — the fix belongs inerror.tsat theparseAPICallErrorlevel.fix: 5xx errors from non-standard providers are not retried #19203 / PR fix(opencode): extract statusCode from error variants for 5xx retry #19204 addresses errors that never become
APICallErrorin the first place — they arrive as plainErrororUnknownErrorbecause they don't come through the Vercel AI SDK'sAPICallErrorpath. The fix belongs infromError()to reclassify these as retryableAPIError.Both paths can produce the same symptom (5xx kills the session), but fixing only one still leaves the other unfixed. For example, OpenRouter returns 502s as
UnknownErrorwith{"code":502,"message":"Network connection lost.","metadata":{"error_type":"provider_unavailable"}}— even ifisRetryableis corrected forAPICallError, these errors bypass that code path entirely and need thefromError()classification that PR #19204 provides.Related: #22448 documents the OpenRouter-specific gap where
code(numeric) andmetadata.error_typearen't checked by PR #19204's current JSON fallback either.github-actions commentedon Jul 5, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.