Skip to main content
provider_rate_limited means the model service was too busy to accept the call, on every route OpenType tried. Read this page when runs fail with this code under load.

What happened

Route: POST /v1/runs. The model service answered that it was rate-limiting OpenType. OpenType already tried its fallback route before answering, so this code means every route it tried was limited. It is not a limit on your organization: OpenType has no request-rate limit, and your own limits are the period quotas, which answer 429 before the run starts. Every provider_* code has the same message, “the provider call failed”. Branch on code, never on the message. The message never contains model output. If this was the first model call, the run was refused before the model served it. You are not charged, and the hold is released, but the run stays pending: a replay with the same Idempotency-Key returns 202 with "state": "pending". If an earlier call in the same run was served (a verdict repair), the run is settled failed and a replay returns 200 with "state": "failed". In both cases, retry with a new key.

How to fix

  • Retry with backoff (for example 2, 4, 8 and 16 seconds) and a new Idempotency-Key on each attempt. Log the request_id of every failed attempt.
  • Spread bursts out. If you send many runs at once, add jitter to the backoff so retries do not arrive together.
  • Do not treat this as a quota. Spend and token quotas answer 429, not 503.

Example

A retry loop with backoff and a new key per attempt:
  • Spend limits and quotas - the limits that do apply to your organization.
  • 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.