OpenAI distinguishes rapid traffic growth from model overload
Rapid traffic growth uses 429/slow_down; model overload uses 503/server_is_overloaded. Clients must inspect both status and code.
Kingy verdict
OpenAI API clients should handle 429/slow_down and 503/server_is_overloaded separately. Inspect the error code, respect a valid Retry-After delay and bound the total retry work. Preserve older handlers while needed; billing and quota failures require corrective action.
Required action
Inspect HTTP status and error.code. Handle 429/slow_down separately from 503/server_is_overloaded; honor a valid Retry-After as a minimum, otherwise use exponential backoff with jitter. Reduce and gradually ramp traffic for slow_down. Bound attempts and total retry time, account for SDK retries, and defer rather than shorten a valid server delay. Preserve legacy handlers while needed; exclude billing/quota errors and do not automatically replay consumed streams.
Read the status and error code
Rapid traffic growth can return HTTP 429 with type rate_limit_error and code slow_down. Temporary model overload uses HTTP 503 with type service_unavailable_error and code server_is_overloaded. A slow_down response can occur within your requests-per-minute and tokens-per-minute limits. Reduce traffic and increase it gradually. If model overload persists, increase the delay between retries.
Honor the server delay
Treat a valid Retry-After value as a minimum wait and add a small random delay. If it is missing or invalid, use exponential backoff with jitter. If the valid delay exceeds your supported or configured maximum, defer the request rather than retry sooner.
Bound the whole retry operation
Limit attempts and total elapsed time. If the application manages retries, disable SDK retries or include them in those limits so nested loops do not multiply requests. SDK support for long server delays varies by version and configuration. An SDK may return the original HTTP error when it declines a delay; cancellation and timeout errors remain separate. A timeout for each attempt is not necessarily a deadline for the full operation.
Keep compatibility with earlier responses
Some endpoints previously used 503/slow_down for both traffic growth and overload. Handle both 429 and 503, inspect the error body and keep older response handling while your application can still receive it. No SDK-wide retry default change or complete endpoint rollout is established by this review.
Separate errors that need action
Billing, spend and quota errors are not ordinary transient retries. Inspect error.code even when the broader error.type is insufficient_quota. Retrying alone will not restore access.
Do not replay consumed streams
The HTTP errors described here apply before streaming begins. Later failures can arrive as stream events. Do not automatically replay a request after consuming output. Video requests rejected before job creation and errors reported within an existing job are separate cases. Documentation about video error handling does not establish current Sora availability.
Notice date and evidence limits
September 2, 2026 is the documented notice date. No mandatory migration or retirement deadline is established, and this record adds no calendar milestone. Historical first-detection date is unverified. Publication and source-check dates do not establish when Kingy first detected this change. The fuller retry guidance was also present in retained September 27 evidence; it is not a newly dated incident. Kingy has not run account-specific requests, reproduced errors or tested SDK retry defaults for this record.