Reference
Limits
Sizes and timeouts the router enforces, and the limits that come from your provider plan.
Router limits#
Sizes and timeouts the hosted router enforces. There is no cap on connections, requests or sentences per org.
| Limit | Value |
|---|---|
Text per segment, or per /v1/audio/speech input | 20,000 characters |
Request body, /v1/audio/speech and the HTTP drop-ins | 80,000 bytes |
| WebSocket message | 64 KB |
/v1/stream: no message while the router waits for input (between segments, or before flush) | Closed after 5 minutes |
| Sarvam WebSocket drop-in: no message | Closed after 60 seconds, as Sarvam does |
| Every client WebSocket | Pinged every 20 seconds; closed if no pong within 20 seconds |
| Provider's first audio for a sentence | 10 seconds, then 10 seconds between chunks: provider_timeout |
| A whole REST reply from the provider (Sarvam above 24 kHz, the HTTP drop-ins) | 60 seconds |
Text over a limit is a bad_request (HTTP 400; on the drop-ins, the provider’s own shape). The LiveKit plugin keeps its pooled connections well inside the idle limit.
Your provider's limits#
Rate and concurrency limits are your provider plan's, on your provider key, exactly as when you call the provider directly.
- Each client connection to the router has its own connection to the provider, never shared, so the provider counts your connections as it would without the router. A cache hit makes no provider request at all.
- When the provider throttles your key, you get
provider_rate_limited(retryable), or the provider’s own error on the drop-ins. - Sarvam limits WebSocket connections and REST requests per minute by plan; Raya publishes no limits; ElevenLabs limits concurrent requests by plan.