Diagnose a failed request

Start with the HTTP status, public error code, request-id header and the time of the request. Do not paste the API key, prompt, response or raw internal error into a report.

Read the error envelope for the protocol you used: OpenAI-compatible and Anthropic-compatible APIs format errors differently, but the safe public code identifies the next action. Preserve the response headers before retrying. For a request that never received a response, first check the connection path; an absent response is not the same as an API rejection.

Check the failure

1. For 401 authentication_required, verify the Bearer or Anthropic key header, key state and expiry. For 403 permission_denied or early_access_required, check the selected organization, plan access and key permissions using authentication. Do not send a paid request merely to test a credential.
2. For 402 insufficient_credits, inspect eligible credits and limits. A top-up cannot pay for a subscription-only Jailbreak execution. For 429, distinguish temporary rate_limit_exceeded from usage_limit_exceeded and respect Retry-After and x-should-retry.
3. For 404 model_not_found, choose an actual ID from the free model catalog, not a display name. For 413 request_too_large, reduce the request body or media size before trying again.
4. For unsupported_capability, context_length_exceeded or invalid_request, change the unsupported capability, context size or malformed field first; the API guides and selected model's capabilities provide the constraints. Repeating the same body cannot make it valid.
5. For 409 idempotency_conflict, compare parameters with the original Idempotency-Key. A duplicate still in progress can be retried after the advised delay with the same key and body; a mismatch must be corrected instead of retried.
6. If an SSE stream began with HTTP 200, read its terminal event. A later error is still a failed run. Do not treat the initial 200 as proof of a completed or charged result.

Retry without duplicating work

Use idempotency and retry guidance before reconnecting after a timeout or broken stream. Keep the same Idempotency-Key and normalized parameters within its 24-hour window when retrying the same logical request. Do not start a new paid request just because the network disconnected; the original may still be running. If x-should-retry: false is present, correct the cause or wait for the published reset condition rather than looping.

If the request never reaches the service, follow connection checks. Use doctor only for a client or authentication problem. To investigate with support, record the UTC time, endpoint, public model ID if relevant, status, safe error code, stream mode and request-id or x-request-id header. A public request ID and code are enough to start; never attach the body, credential or full environment dump. Check API Activity for a recent logical operation, but do not assume its run ID equals the HTTP request ID.