Errors

The API returns different error shapes depending on the surface you call. Match your handler to the surface.

OpenAI-style errors

The OpenAI-style endpoints (/v1/chat/completions, /v1/models, /v1/files, /v1/audio) return the OpenAI-canonical nested error object. OpenAI SDKs and gateways (Bifrost, LiteLLM) parse it as error.message out of the box.

{
  "error": {
    "message": "Invalid API key format.",
    "type": "invalid_request_error",
    "param": null,
    "code": "invalid_api_key"
  }
}

The error.type and error.code follow the HTTP status.

A request body that fails validation returns 400 with a single collapsed message ("messages: Field required"), the same as OpenAI. The request ID is on the X-Request-Id response header.

Talos-specific endpoints

Endpoints outside the OpenAI standard (for example /v1/audit) keep the flat legacy envelope:

{
  "error": "Audit rate limit exceeded.",
  "code": "HTTP_429",
  "request_id": "req_..."
}

In-stream errors

When an inference error happens mid-stream, the stream emits one error chunk and then closes with [DONE].

{
  "error": {
    "message": "inference backend unavailable",
    "type": "service_unavailable",
    "code": "inference_error"
  }
}

data: [DONE]

Anthropic-style errors

The Anthropic-style endpoints (messages and batches) return the Anthropic error shape.

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "max_tokens is required"
  }
}

The error.type is mapped from the HTTP status.

Status codes

Next

• Rate limits
• Overview