Skip to main content
Chariot limits how many requests you can run at the same time (concurrency), scaled to your plan. There is no fixed requests-per-second cap. The control is on simultaneous in-flight generations.

How concurrency works

Each workspace may have a fixed number of TTS generations running concurrently. When a request starts it takes a slot; when it finishes it releases the slot. If all slots are busy, the next request is rejected immediately with 429 rather than being queued. The limit is scoped to your workspace and driven by your plan tier.

Limits by plan

These are the current defaults and can change as plans evolve. Check your plan in the dashboard for the value that applies to your workspace.

The 429 response

When you exceed your concurrency limit:
If your plan does not include the product at all, you get 403 instead:

Handling limits

The API does not queue requests or send a Retry-After header, a 429 is an immediate rejection. Handle it on the client:
  • Cap your in-flight requests to your plan’s concurrency limit so you rarely hit 429 in the first place.
  • Retry with exponential backoff and jitter when you do, e.g. 0.5s, 1s, 2s, 4s with random jitter.
  • Use a worker pool sized to your limit rather than firing all requests at once.
Python

Need more headroom?

If you consistently hit your concurrency limit, upgrade your plan for more slots, or contact support@chariot.in to discuss higher limits.