The service applies best effort request limits per API key and IP address.
Current defaults
The default limit is 120 requests per minute per key and 120 per minute per IP. Chat streaming is limited to 24 concurrent streams; when full, requests return 503 with service_unavailable.
A request rate limit returns HTTP 429:
{
"type": "https://platform.mymansa.ai/docs/errors#rate_limited",
"title": "Rate Limited",
"isError": true,
"detail": "Too many requests. Please try again shortly.",
"invalidParams": [],
"context": "rate_limited",
"description": null
}Recovery
Limit concurrency in your application. On 429, retry with exponential backoff and jitter. Do not assume a Retry-After header will be present. Avoid immediately retrying every request together.
Use separate keys for applications so you can rotate access independently. Contact Mansa to discuss sustained production throughput.
Token budgets vs throughput
Rate limits count requests, not tokens. Setting a higher max_tokens on /v1/chat does not grant extra requests per minute or additional concurrent streams.
Use max_tokens when you need longer single replies. Expect higher per-request cost when the model uses more output tokens — see Pricing. Keep concurrency and retry behavior aligned with the limits above so large replies do not amplify 429 or 503 responses across your fleet.
Long history arrays increase request duration and input-token cost but do not raise the requests-per-minute limit. Retry one thread at a time with backoff instead of firing parallel retries for the same conversation. See Chat.