Skip to main content
Two independent controls protect the platform and your spend. Both return an OpenAI-compatible error envelope so the standard SDKs surface them cleanly.

​
Request rate limit (per key)

Each API key has a requests-per-minute setting (60 by default). The same limit applies across authenticated /v1 endpoints; it is not a separate allowance for each path. On overflow you get HTTP 429 with Retry-After plus X-RateLimit-* headers:
Treat the per-key limit as a floor — brief bursts slightly above it may succeed, so don’t rely on it as an exact ceiling. Contact Mirobody Support to raise a key’s limit.

​
Monthly account cap

Hosted environments can enforce a monthly account cap in USD. Once it is enabled, authenticated /v1 requests return HTTP 429 with insufficient_quota as soon as the current month’s metered usage reaches the cap — until the next calendar month, or until support raises it:
The cap covers all keys under the account together. The error message reports the configured cap and the current-month metered amount. To confirm or change your account’s cap, contact Mirobody Support.

​
Client pacing

Keep the combined request rate for one key below its configured RPM. Streaming calls count when the request starts. Batch structured records into one POST /v1/data request (up to 500 records), and don’t poll an uploaded file in a tight loop before its text is ready.

​
Client backoff

  • On 429 rate_limit_exceeded, respect Retry-After — never retry immediately; double the backoff after two consecutive hits, up to 5 minutes.
  • On 429 insufficient_quota, do not retry — the cap resets monthly or on a support change; surface it to the operator.

​
See also

  • Models — per-tier capacity and price.
  • API Overview — the error envelope these limits return.
  • Streaming — how a stream ends when a limit is hit.