Skip to main content
not_configured means the service is missing a part it needs to handle runs. Read this page when a runs route answers with this code; it is a service-side problem.

What happened

Routes: POST /v1/runs, GET /v1/runs, GET /v1/runs/{run_id}, GET /v1/runs/{run_id}/stream. Something a run needs is not configured: the data store, the service’s model list, the component that chooses a model, the model service, or the connection for the model chosen for this run. This is how the runs routes spell it; other routes use the more specific database_not_configured or billing_not_configured. On POST /v1/runs the refusal can come before or after the run is admitted. If it came after, the run is stored as pending and is never charged; a replay with the same Idempotency-Key returns 202 with that pending run.

How to fix

  • Retry after a few minutes with backoff. A fast loop gets the same answer.
  • On POST /v1/runs, use a new Idempotency-Key for the retry.
  • GET routes have no key; retry them as they are.
  • If it persists, report the request_id.

Example

Retrying a read with backoff and your own request id:
  • Error handling - a status-to-action table and a retry helper for every error.
  • Idempotency - when to reuse an Idempotency-Key and when to send a new one.
  • Request ids - send your own x-request-id and quote it when you report a problem.
  • Problem codes - every code, its status, and whether a retry can help.