Límites y cuotas
300 peticiones por minuto y por clave, 32 transcripciones en vuelo, 2 GB por fichero.
| Límite | Valor | Qué pasa al superarlo |
|---|---|---|
| Peticiones por minuto | 300 por CLAVE | 429 rate_limit_exceeded con Retry-After |
| Transcripciones en vuelo | 32 por organización | 429 concurrency_limit_exceeded |
| Tamaño de fichero | 2 GB | 413 |
| Duración de audio | 10 h | 400 audio_duration_exceeded |
custom_vocabulary | 1 000 términos, 80 caracteres cada uno | 400 |
input de embeddings | 256 elementos | 400 |
max_tokens de chat | 32 000 | 400 |
| Ventana de idempotencia | 24 h | 409 si cambia el cuerpo |
Cabeceras en toda respuesta autenticada:
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 0
Callsist-Request-Id: req_9xKp2mQvRt4LDos detalles que cambian cómo se programa contra el límite
Es por clave, no por organización. Es una ventana deslizante de 60 s sobre el identificador de la clave. Dos claves distintas tienen dos cubos distintos: si necesitas más caudal, una segunda clave lo duplica. Y al revés — el sondeo de estado consume del mismo cubo que las llamadas de negocio si van con la misma clave. Separar «la clave que transcribe» de «la clave que analiza» es la forma barata de que un lote no ahogue al otro.
X-RateLimit-Reset vale 0 mientras la petición se permite. Solo dice algo real en
el 429, donde además viene Retry-After con el mismo número. Para frenar antes de
chocar, mira X-RateLimit-Remaining y espera un tiempo fijo; usar Reset sería esperar
cero segundos.
El techo de 32 en vuelo es el que gobierna un lote
Cuenta como «en vuelo» todo lo que esté en queued o processing. Con una cola propia
de 8 simultáneas nunca se toca; con 40 sí.
Y el sondeo tiene su propia trampa: no hay límite aparte para consultar estado, así que
sondear 400 transcripciones cada 10 segundos son 2 400 peticiones por minuto y un 429
inmediato. Sondea solo lo que está en vuelo. Con 8 en curso y un sondeo cada 10 s son
48 peticiones por minuto, que caben de sobra. Ver Lotes y límites.
Timeouts
POST /v1/chat/completions puede tardar varios minutos en devolver un error: el
cliente HTTP interno tiene 120 s de timeout y hasta 3 reintentos con espera creciente, y
no hay forma de acotarlo desde la petición. Pon tu propio timeout de cliente —60 a 120 s
para análisis por lotes— y trátalo como reintentable.
estimated_completion en la respuesta de POST /v1/transcripts no es un timeout: es
siempre «ahora + 6 minutos», una constante que no mira ni la cola ni la duración del
audio.