Limits and retries

Limits can come from the Redgold account, an individual API key, platform capacity, or an upstream model provider. The response body and headers identify the path that rejected a request where possible.

Per-key request limits

An API key may have a positive requests-per-minute setting. The model API enforces that cap over a rolling 60-second window. When the cap is exceeded the response is a 429 whose error message states the retry interval; the per-key limiter does not set a Retry-After header. A key without a positive cap relies on account and provider limits instead.

Provider limits

Upstream providers may return 429 during a capacity or quota event, and that status propagates to the caller. The provider's own Retry-After header is not forwarded, so a client should apply its own bounded backoff. The public API does not promise an inline retry that hides the first 429.

Client behavior

For 429, 502, 503, and 529 responses:

1. Honor Retry-After when present.
2. Otherwise use exponential backoff with jitter and a bounded retry count.
3. Avoid retrying a non-idempotent operation unless the API contract supplies an idempotency mechanism.
4. Surface the final provider-shaped error to the user.

Validation and authentication failures should be corrected rather than retried. See errors.

Specific numeric account limits can vary by plan and are shown in the account interface. Planned quota controls are omitted from this page until they are enforced on the public path.