Límites de solicitudes

Nuestra API limita la cantidad de veces que un usuario o cliente puede acceder a nuestros servicios durante un período determinado.

¿Por qué aplicamos límites de solicitudes?

Los límites de solicitudes son habituales en las API y se aplican por varios motivos:

• Ayudan a proteger la API contra el abuso o el uso indebido. Por ejemplo, alguien podría enviar una avalancha de solicitudes para intentar sobrecargar la API o interrumpir el servicio. Con los límites de solicitudes, OpenAI puede prevenir este tipo de actividad.
• Los límites de solicitudes ayudan a garantizar un acceso equitativo a la API. Si una persona u organización envía demasiadas solicitudes, la API podría responder con lentitud a los demás. Al limitar la cantidad de solicitudes que puede enviar cada usuario, OpenAI permite que la mayor cantidad posible de personas pueda usar la API sin demoras.
• Los límites de solicitudes pueden ayudar a OpenAI a gestionar la carga total de su infraestructura. Si la cantidad de solicitudes a la API aumenta de forma drástica, los servidores podrían sobrecargarse y su rendimiento podría verse afectado. Al establecer límites de solicitudes, OpenAI ayuda a que el servicio funcione de manera fluida y estable para todos los usuarios.

¿Cómo funcionan estos límites de solicitudes?

Los límites de solicitudes se basan en métricas como RPM (solicitudes por minuto), RPD (solicitudes por día), TPM (tokens por minuto), TPD (tokens por día), IPM (imágenes por minuto) y, para algunos modelos de audio en streaming, minutos de audio por minuto. Se aplica el primer límite que alcances. Por ejemplo, si tu límite es de 20 RPM y envías 20 solicitudes con apenas 100 tokens al punto de acceso ChatCompletions en un minuto, alcanzas el límite de solicitudes por minuto aunque no hayas enviado los 150 000 tokens que te permitiría un límite de 150 000 TPM.

Los límites de la cola de la API Batch se calculan a partir del total de tokens de entrada en cola para cada modelo. Los tokens de los trabajos por lotes pendientes cuentan para el límite de la cola. Cuando finaliza un trabajo, sus tokens dejan de contar para el límite de ese modelo.

Ten en cuenta lo siguiente:

• Los límites de solicitudes se definen por organización y por proyecto, no por usuario.
• Los límites de solicitudes varían según el modelo que uses.
• En los modelos de contexto largo, como GPT-5.5, las solicitudes de contexto largo tienen un límite aparte. Puedes consultar estos límites de solicitudes en la consola para desarrolladores.
• OpenAI establece un límite de uso mensual aprobado para cada organización. Este límite es independiente de los límites de gasto que puedes configurar para una organización o un proyecto.
• Algunas familias de modelos comparten límites de solicitudes. Los modelos que aparecen bajo un mismo “límite compartido” en la página de límites de tu organización comparten ese límite. Por ejemplo, si el límite compartido es de 3,5 millones de TPM, los tokens de todas las llamadas a cualquiera de los modelos de esa lista cuentan para ese mismo total.
• La ingesta de datos en almacenes de vectores también está sujeta a un límite de solicitudes por ID de almacén. /vector_stores/{vector_store_id}/files y /vector_stores/{vector_store_id}/file_batches comparten un límite de 300 solicitudes por minuto para cada almacén de vectores. Para cargar volúmenes de datos más grandes, usa preferentemente /vector_stores/{vector_store_id}/file_batches.

Niveles de uso

Los tres niveles de uso de pago son Build, Launch y Grow. Tu organización sube de nivel automáticamente cuando el importe total de sus compras de créditos alcanza el umbral correspondiente. Por lo general, los niveles superiores ofrecen límites de solicitudes más altos para los distintos modelos.

Límites de solicitudes del modo estándar

Para consultar los límites de cada modelo en tu nivel de uso, ve a Configuración > Organización > Límites y revisa Límites de solicitudes. Para subir de nivel, selecciona Subir de nivel en la sección Niveles de uso.

Los límites de solicitudes del modo estándar son distintos de los límites de solicitudes del modo ultrarrápido.

Límites de gasto

Considera establecer límites de gasto para tu organización o tus proyectos a fin de controlar el gasto mensual en la API. Estos controles son independientes de los límites de uso mensuales indicados arriba.

Límites de solicitudes en los encabezados

Además de consultar tu límite de solicitudes en la página de tu cuenta, puedes ver en los encabezados de la respuesta HTTP cuántas solicitudes y tokens te quedan, junto con otros metadatos sobre tus límites.

Las respuestas pueden incluir los siguientes campos de encabezado:

Los encabezados de tokens del proyecto pueden aparecer cuando se aplica un límite de tokens a ese proyecto. Retry-After puede aparecer en respuestas 429 debidas a un límite de solicitudes temporal y en respuestas 503 debidas a una sobrecarga temporal del modelo. Su presencia no implica que puedas resolver con un reintento los errores de cuota, de facturación u otros que requieran que tomes medidas.

Límites de solicitudes de ajuste fino

También puedes consultar en el panel los límites de solicitudes de ajuste fino de tu organización u obtenerlos a través de la API:

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Disponibilidad de los modelos

El acceso a los modelos es independiente de los límites de solicitudes. Alcanzar el umbral de un nivel de uso no te da acceso a todos los modelos. Si un modelo que figura en la documentación no aparece en Playground o en la respuesta de GET /v1/models, o si una solicitud devuelve model_not_found, sigue estos pasos:

1. Verifica el ID del modelo y el punto de acceso. Usa el ID exacto que aparece en la documentación del modelo, confirma que el modelo sea compatible con el punto de acceso que usas y revisa si hay avisos sobre su retiro o disponibilidad.
2. Compara la organización, el proyecto y las credenciales. En Playground, selecciona la organización y el proyecto que quieres usar. Llama a Listar modelos con la misma clave de API que usaste en la solicitud fallida. Si esa solicitud incluía los encabezados OpenAI-Organization u OpenAI-Project, envía los mismos valores. Aunque veas un modelo en tu sesión del panel, es posible que no puedas acceder a él con otra clave de API.
3. Revisa las restricciones del proyecto y los requisitos del modelo. Pide a alguien que tenga permisos para administrar el proyecto que revise los permisos de acceso a los modelos y la configuración de retención de datos del proyecto. Cumple los requisitos de acceso específicos del modelo y consulta en su documentación los avisos sobre su implementación gradual. Si el modelo no aparece, ese dato por sí solo no basta para determinar la causa.
4. Actualiza la lista y vuelve a comprobar la disponibilidad. Después de cambiar la configuración de acceso, actualiza la lista de modelos o vuelve a cargar Playground. Si el modelo sigue sin estar disponible, comunícate con el equipo de soporte e indica el ID del modelo, los ID de la organización y del proyecto, la hora de la solicitud, el mensaje de error y, si está disponible, el valor del encabezado de respuesta x-request-id. No compartas tu clave de API.

Mitigación de errores

Cómo manejar los aumentos rápidos de tráfico y la sobrecarga del modelo

La API puede devolver slow_down si la frecuencia de tus solicitudes aumenta demasiado rápido o server_is_overloaded si el modelo solicitado está sobrecargado temporalmente. Para distinguir ambos casos, revisa el código de estado HTTP y error.code:

Si la respuesta no incluye Retry-After, aumenta la espera entre reintentos y añade una pequeña demora aleatoria.

Puedes recibir un error slow_down aunque tu tráfico se mantenga dentro de los límites de solicitudes por minuto y de tokens por minuto. El error indica que el tráfico aumentó demasiado rápido, independientemente de si agotaste esos límites.

Como regla general, una vez que tu tráfico alcance 1 millón de tokens de entrada por minuto (TPM), auméntalo como máximo un 50 % cada 15 minutos. El punto exacto a partir del cual se limita la velocidad de aumento del tráfico puede variar según el modelo y las condiciones del tráfico.

Los clientes empresariales cuyo tráfico de pago por uso alcanza con frecuencia los límites de aumento de tráfico pueden considerar el Nivel de capacidad para disponer de una capacidad más predecible en los modelos admitidos. Para GPT-5.6 y modelos posteriores, consulta el Nivel reservado. En cualquier nivel de capacidad, maneja las respuestas slow_down de la misma manera: respeta el tiempo indicado en Retry-After si está presente, reduce el tráfico y vuelve a aumentarlo gradualmente.

Actualiza los manejadores de errores existentes

Si tu aplicación ya manejaba las respuestas anteriores de limitación de tráfico y sobrecarga, revisa tanto el estado HTTP como error.code:

• En los puntos de acceso que antes devolvían 503 con el código slow_down en ambos casos, los aumentos rápidos de tráfico ahora devuelven 429 con slow_down. La sobrecarga del modelo sigue devolviendo 503, pero ahora usa server_is_overloaded.
• Antes, las solicitudes de video rechazadas por alguno de estos motivos antes de que se creara el trabajo devolvían 429 con el tipo invalid_request_error y el código rate_limit_exceeded. Ahora, los aumentos rápidos de tráfico devuelven 429 con rate_limit_error y slow_down. La sobrecarga del modelo devuelve 503 con service_unavailable_error y server_is_overloaded. Los errores que aparecen en el estado de un trabajo de video se manejan por separado.

Contempla tanto 429 como 503 en los manejadores de errores de tu SDK. Por ejemplo, los SDK de Python, TypeScript y Ruby usan RateLimitError para 429 e InternalServerError para 503. El SDK de Java usa RateLimitException e InternalServerException. Mantén la compatibilidad con los códigos de respuesta anteriores mientras tu aplicación aún pueda recibirlos. Otros errores pueden usar los mismos estados HTTP, así que revisa el cuerpo del error antes de decidir cómo recuperarte.

En las solicitudes de streaming, estas respuestas de error HTTP se aplican antes de que comience la transmisión. Una vez iniciada, puedes recibir un error como evento de la transmisión. Si ya consumiste parte de la salida, no vuelvas a enviar la solicitud automáticamente.

¿Qué medidas puedo tomar para mitigar estos errores?

El OpenAI Cookbook incluye un notebook de Python que explica cómo evitar errores por límites de solicitudes, además de un script de ejemplo en Python para procesar solicitudes a la API por lotes sin exceder esos límites.

Ten cuidado al ofrecer acceso programático, funciones de procesamiento masivo o publicación automatizada en redes sociales. Considera habilitar estas funciones solo para clientes de confianza.

Para evitar el uso indebido automatizado y a gran escala, establece un límite de uso por usuario para un período determinado (diario, semanal o mensual). Considera aplicar un tope estricto o implementar un proceso de revisión manual para quienes excedan el límite.

Reintentos con espera exponencial

Cuando una solicitud supera un límite de solicitudes temporal, la API devuelve un error 429. La respuesta puede incluir un encabezado Retry-After que indica cuántos segundos debes esperar antes de volver a intentarlo. Toma ese valor como mínimo: espera al menos ese tiempo y añade una pequeña demora aleatoria para que varios clientes no reintenten al mismo tiempo.

Cada SDK oficial de OpenAI reintenta automáticamente las solicitudes que reciben respuestas 429 y 503 cuando cumplen las condiciones de reintento, según la configuración del SDK. El manejo de Retry-After, en especial cuando indica esperas largas, varía según la versión y la configuración del SDK. Comprueba cómo maneja los reintentos la versión que tienes instalada antes de asumir que admite cualquier tiempo de espera indicado por el servidor.

Si el servidor indica un tiempo de espera válido que supera el máximo admitido o configurado para los reintentos, detén los reintentos y pospón la solicitud. Si el SDK rechaza un tiempo de espera superior a su límite, puede devolver el error HTTP original. Sigue manejando por separado los errores de cancelación y de tiempo de espera: si se cancela la solicitud o vence el plazo, los reintentos pueden detenerse sin devolver ese error HTTP. El tiempo de espera máximo de cada intento no necesariamente limita la duración de toda la operación.

Si usas tu propio cliente HTTP, respeta el tiempo indicado en Retry-After cuando el encabezado esté presente y contenga un valor válido. Si falta o no es válido, usa una espera exponencial con una pequeña variación aleatoria. Limita tanto la cantidad de intentos como el tiempo total dedicado a reintentar. Si gestionas los reintentos en tu aplicación, desactiva los del SDK o inclúyelos en esos límites para que los bucles de reintentos anidados no multipliquen las solicitudes. No reintentes solicitudes que fallaron por errores de cuota, de facturación u otros que requieran que tomes medidas.

La espera exponencial consiste en esperar brevemente después de una solicitud fallida y aumentar el tiempo de espera después de cada reintento fallido. El proceso continúa hasta que la solicitud tenga éxito o se alcance el límite de reintentos configurado.

Este enfoque tiene varias ventajas:

• Los reintentos automáticos permiten recuperarse de los errores por límites de solicitudes sin que la aplicación deje de funcionar ni se pierdan datos.
• Con la espera exponencial puedes hacer los primeros reintentos rápidamente y, si fallan, esperar más tiempo entre los siguientes.
• Añadir una variación aleatoria al tiempo de espera ayuda a evitar que todos los reintentos ocurran al mismo tiempo.

Ten en cuenta que las solicitudes fallidas cuentan para tu límite por minuto, por lo que reenviar una solicitud continuamente no resolverá el problema.

Los siguientes ejemplos muestran cómo reintentar una solicitud que usa gpt-6-luna en la API Responses. Cada función que envuelve la llamada limita la cantidad de intentos y desactiva los reintentos automáticos del SDK.

Los siguientes ejemplos en Python muestran cómo aplicar una espera exponencial cuando no hay indicaciones válidas del servidor. No comprueban Retry-After. Antes de usarlos, incorpora el manejo de los tiempos de espera válidos que indique el servidor para que las funciones que envuelven las llamadas no reintenten antes de tiempo. Desactiva los reintentos del SDK o inclúyelos en los límites de reintentos de tu aplicación.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28from openai import OpenAI, RateLimitError
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI(max_retries=0)


@retry(
    retry=retry_if_exception_type(RateLimitError),
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    reraise=True,
)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19import backoff
import openai
from openai import OpenAI

client = OpenAI(max_retries=0)


@backoff.on_exception(backoff.expo, openai.RateLimitError, max_tries=6)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI(max_retries=0)

# define a retry decorator


def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""

    def wrapper(*args, **kwargs):
        # Initialize variables
        num_retries = 0
        delay = initial_delay

        # Loop until a successful response or max_retries is hit or an exception is raised
        while True:
            try:
                return func(*args, **kwargs)

            # Retry on specific errors
            except errors:
                # Increment retries
                num_retries += 1

                # Check if max retries has been reached
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    )

                # Increment the delay
                delay *= exponential_base * (1 + jitter * random.random())

                # Sleep for the delay
                time.sleep(delay)

            # Raise exceptions for any errors not specified
            except Exception:
                raise

    return wrapper


@retry_with_exponential_backoff
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

Reduce max_tokens para ajustarlo al tamaño de tus respuestas

Para calcular tu límite de solicitudes, se toma el mayor de dos valores: max_tokens y la cantidad estimada de tokens según el número de caracteres de tu solicitud. Procura que el valor de max_tokens se acerque lo más posible al tamaño de la respuesta que esperas.

Agrupación de solicitudes por lotes

Si tu caso de uso no requiere respuestas inmediatas, puedes usar la API Batch para enviar y ejecutar grandes lotes de solicitudes sin afectar tus límites de solicitudes síncronas.

Para los casos de uso que sí requieren respuestas síncronas, la API de OpenAI tiene límites independientes de solicitudes por minuto y de tokens por minuto.

Si alcanzas el límite de solicitudes por minuto, pero aún tienes capacidad disponible en tokens por minuto, puedes mejorar el rendimiento agrupando varias tareas en cada solicitud. Así podrás procesar más tokens por minuto, especialmente con nuestros modelos más pequeños.

Enviar un lote de prompts funciona igual que hacer una llamada normal a la API, con la diferencia de que pasas una lista de cadenas al parámetro prompt en lugar de una sola cadena. Consulta la guía de la API Batch para obtener más información.