Rate limits

Limits are per key, not per account, so a background job hammering one key cannot take down the key your product is using. A key's limit is stored on the key. A key with no stored limit gets the default: 120 requests per 60 seconds.

These are on every response from /v1, not only on a 429, so you can slow down before being refused. ratelimit-reset is the seconds until the window rolls over. A refused call is a 429 rate_limited with a Retry-After header.

A sliding window: the previous window's count is weighted by how much of it still overlaps the last interval. That smooths the burst a plain fixed window allows at its edge, where a client could otherwise fire two full windows of requests back to back across the boundary.

Limiting runs after authentication and before the body is read, so a refused call costs nothing and a call with no valid key never reaches the limiter.

Every operation caps a single request, measured in that operation's own billing unit. Transcription is **180 audio seconds** per call, synthesis is **5,000 characters**, and subtitle export is **900 video seconds**. Over the cap is a 413 request_too_large, and the error carries the limit and what was counted so you can split accordingly.

Longer audio is a client-side split. Nothing is lost by splitting: the service already cuts recordings into ten second pieces internally, at the quietest instant near each boundary, so no word is cut in half either way. Cost also grows faster than length, because attention is quadratic, which means three ten second pieces are genuinely cheaper than one thirty second pass.

There are two separate limits here and they fail differently on purpose.

• **Your own share**, 2 requests in flight by default. Past it you get a 429 organization_busy. This one is yours to manage: send fewer at a time, or ask us to raise it.
• **The server's capacity**, shared by everyone. Past it you get a 503 server_busy with Retry-After: 2. There is nothing you can do about this one, which is exactly why it has a different code.

Nothing is charged for either, and with an Idempotency-Key the retry is safe.

An organization can set a rolling 24 hour credit cap, which is separate from its balance. A balance stops you at the end of the money; this stops you well before, which is what you want if a key leaks or a loop misbehaves. Past it you get a 429 daily_limit_reached with a Retry-After set to when the oldest spend in the window ages out. It is off unless you set it in the dashboard.