Read the response, not only the status
HTTP status is the first clue. The error body, request identifier, time and selected model help distinguish your application, gateway and upstream failure. Redact secrets before sharing logs.
400, 401, 403 and 404
400 usually calls for checking the request format and supported parameters. 401 points to authentication: confirm the key and Authorization header without printing the key. 403 may indicate permissions or a policy restriction. 404 can mean an incorrect path or unavailable resource. Always read the actual error body.
429 and temporary upstream failures
For 429, reduce concurrency and request frequency, review account limits and honor Retry-After when supplied. For a temporary 5xx error, use a limited retry strategy with increasing delays. Do not loop indefinitely or assume every error is retryable.
A timeout does not prove cancellation
A request may have reached the model even if your client did not receive the response. Inspect usage before repeating an expensive request. For actions with real-world side effects, use application-level idempotency and reconciliation rather than relying on repeated model calls.
What to send to support
Send a sanitized minimal request, model name, endpoint, timestamp, status and request identifier to [email protected]. Do not include your complete key, password or private input. Support can start with metadata.