Rate limits

Two separate mechanisms can stop a request, and they return different errors:

1. Throughput limits: how fast you can go. Hitting one returns 429 rate_limited; slowing down fixes it.
2. Funding: whether your organization's included tokens or wallet can pay for the request. Running out returns 429 included_allowance_exhausted or 402 wallet_empty; slowing down does not fix these.

Throughput limits

Limits apply per organization (not per key, not per user), across all models combined:

Limit	Default
Requests per minute	60
Tokens per minute	1,000,000
Concurrent in-flight requests	20

These are the standard defaults; they can be raised per organization; contact support@mindsdb.com if your workload needs more. There is currently no API that reports your organization's limits or remaining headroom; the only signal is the 429 itself.

Exceeding any of the three returns the same error:

HTTP 429
Retry-After: 12

{"error": {"message": "Rate limit exceeded for model 'sonnet'. Please slow down and retry.",
           "type": "rate_limit_error", "param": null, "code": "rate_limited"}}

Honor Retry-After (seconds, always ≥ 1). The response does not identify which of the three limits you exceeded; if you see 429s at low request rates, suspect the token budget or the concurrency cap.

How the token budget is counted

When a request is admitted, the per-minute token budget reserves the larger of your estimated prompt size and your max_tokens, then settles to the real count after the request finishes. Consequences:

• A request with a huge max_tokens reserves that many tokens from the minute's budget up front, even if the model would have answered in 50. Oversized max_tokens values directly reduce how many requests you can run per minute.
• A burst of concurrent large-max_tokens requests can exhaust the budget before any of them finishes.
• A single request bigger than the whole per-minute budget isn't rejected outright; it waits for the budget to refill, surfacing as 429s until then.

Keep max_tokens realistic, but not too tight on models that reason internally; see the note in Chat completions.

No rate-limit headers on success

Successful responses carry no X-RateLimit-* headers. Build client pacing on the 429s and Retry-After, not on header telemetry.

Running out of tokens instead

Distinct from throughput: your organization's monthly included tokens can run out, and the wallet can run dry. Those return 429 included_allowance_exhausted (organizations with no payment method on file) or 402 wallet_empty (everyone else), and retrying won't help until the monthly reset or a top-up. How the funding model works, and how to check your remaining tokens from code, is covered in Billing; the exact error shapes are in Errors.

Practical guidance

• Cap client-side concurrency at or below 20, and queue beyond it.
• Retry 429 rate_limited honoring Retry-After; stop on included_allowance_exhausted. A worked loop is in Errors.
• Don't rely on the limiter as flow control: under degraded operation limits may not be enforced exactly, and nothing guarantees the 429 arrives precisely at the documented threshold.