Límites de tasa

El límite

Alcance	Límite
Por clave de API	60 solicitudes por minuto

El límite se aplica por clave, no por workspace, así que dos claves dentro del mismo workspace obtienen cada una su propia cuota de 60 por minuto en lugar de compartir un solo grupo. Es un límite de cantidad de solicitudes, no de cantidad de tokens: una sola solicitud que genera una respuesta muy larga cuenta igual que una que genera una muy corta, y el hecho de usar streaming o no hace ninguna diferencia en cómo se cuenta una solicitud.

Este límite existe principalmente como salvaguarda contra bucles descontrolados, un bucle de reintentos sin espera, un error que dispara una solicitud por cada pulsación de tecla, y no como un tope significativo sobre el uso legítimo. El tráfico normal de una aplicación, incluso un uso de chat bastante activo, queda bien por debajo de él.

Superar el límite

Una solicitud que supera el límite recibe un 429 de inmediato, sin quedar en cola ni retrasarse, en el mismo envoltorio de error que cualquier otro error:

HTTP/1.1 429 Too Many Requests

{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}

La ventana se reinicia de forma continua (rolling), así que la respuesta correcta ante un 429 es una breve pausa antes de reintentar, no cambiar a otra clave ni suponer que algo está roto. Un único 429 en medio de una ráfaga de actividad es normal y esperable; múltiples 429 a lo largo de varias ráfagas separadas es una señal de que el propio patrón de solicitudes necesita una estrategia de espera, cubierta a continuación.

Esperar correctamente antes de reintentar

Reintentar un 429 de inmediato, en un bucle apretado, empeora la situación en lugar de mejorarla: mantiene la tasa de solicitudes exactamente en el mismo punto por encima del límite, así que cada reintento falla de la misma manera. Una espera corta, idealmente creciente, entre intentos (unos cientos de milisegundos, duplicándose en cada fallo consecutivo, hasta un tope razonable) resuelve casi todos los 429 en uno o dos reintentos sin afectar de forma perceptible la latencia visible para el usuario en una solicitud normal.

# Python: minimal retry with exponential backoff
import time

for attempt in range(4):
    try:
        response = client.chat.completions.create(model="tai-4.1", messages=messages)
        break
    except Exception as e:
        if attempt == 3:
            raise
        time.sleep(0.5 * (2 ** attempt))

Los SDK oficiales de OpenAI ya implementan por defecto un comportamiento de reintento con espera creciente exactamente para este tipo de error transitorio; si usa uno de ellos, esto probablemente ya está resuelto por usted sin código adicional, y solo verá una excepción una vez que se agote su propio presupuesto de reintentos.

Si 60 por minuto realmente resulta insuficiente

Para la mayoría de las aplicaciones, el volumen de solicitudes está naturalmente limitado por la rapidez con la que una persona o un bucle de agente puede realmente generar solicitudes, y 60 por minuto rara vez es una restricción real. Si un caso de uso legítimo alcanza el límite de forma sistemática, lo primero que conviene revisar es si las solicitudes pueden agruparse o consolidarse, enviando menos solicitudes más grandes en lugar de muchas pequeñas para la misma tarea subyacente, antes de asumir que el límite en sí necesita cambiar.