HTTP 503 can indicate a temporary upstream outage. When the platform detects rate limits, quota limits, network failures, or upstream access restrictions, it pauses requests to the affected service and retries when availability conditions are met.
Automatic Routing
The platform tries other available upstream services. Success still depends on model availability, quotas, and upstream policies; automatic routing cannot guarantee that every request succeeds.
Tiered Handling of First-Byte Timeouts
response header timeout is commonly caused by temporary upstream congestion or longer reasoning. After consecutive failures, the platform records the failure and tries other available routes:
- 1st–2nd consecutive failure: Try another route
- 3rd–4th failure: Pause for 30 seconds
- 5th–6th failure: Pause for 1 minute
- 7th and subsequent failures: Pause for 5 minutes
A successful response clears the consecutive failure count. Other upstream restrictions may require a longer recovery time.
No Service Available
Clients may receive HTTP 503 with an error such as:
{
"code": "no_account_available",
"message": "all accounts cooling down, retry in 60s"
}
These are the actual API error fields, retained here for troubleshooting. retry in Xs suggests a retry delay; actual recovery depends on upstream status.
Client Handling
- Use exponential backoff with jitter, such as 1, 2, 4, and 8 seconds, and set a maximum retry count.
- Check whether your tool or SDK already retries requests to avoid stacking retry loops.
- Record failed automated tasks and provide a manual recovery path. Check whether tool calls or write operations have already executed before retrying to avoid duplicate actions.
- For persistent failures, check Service & support. If failures last more than 15 minutes or affect critical tasks, contact [email protected] with the request time, model, and error code.
Remove API keys and sensitive request content before sharing troubleshooting details.