Límites de OpenAI API y GPT-6 Astra: RPM, TPM, 429 y 503

GPT-6 Astra ya tiene una referencia pública de capacidad para la API: OpenAI muestra solicitudes por minuto, tokens por minuto y capacidad de la cola de Batch para los niveles T1 a T5. Esa tabla permite hacer una primera estimación, pero no sustituye el límite que tiene asignado tu organización o proyecto.

Para operar sin sorpresas, usa tres fuentes en este orden: la página Limits de tu cuenta, las cabeceras x-ratelimit-* de las respuestas y, por último, la tabla pública como referencia de planificación. Además, separa el código HTTP del cuerpo del error: slow_down es un 429 asociado a un crecimiento demasiado rápido del tráfico, mientras que server_is_overloaded es un 503 por falta temporal de capacidad del modelo.

GPT-6 Astra: límites públicos por nivel

La ficha oficial de GPT-6 Astra publica estos valores para Astra Standard. La comprobación de esta página se realizó el 4 de septiembre de 2026:

GPT-6 Astra no está disponible en Free. Los valores T1–T5 tampoco garantizan que una cuenta de pago ya tenga acceso al modelo ni que su límite efectivo coincida exactamente con la fila pública. Son una referencia general para gpt-6-astra con procesamiento Standard; la configuración vigente de la cuenta es la que manda.

Las tres columnas responden a restricciones distintas:

• RPM limita cuántas solicitudes pueden entrar en un minuto.
• TPM limita el volumen de tokens procesado en un minuto.
• Batch queue limita los tokens de entrada acumulados en los trabajos Batch pendientes para ese modelo. No es el número de lotes ni una cuota diaria. Cuando un trabajo termina, sus tokens dejan de ocupar la cola, según la definición oficial de los límites de Batch.

La capacidad útil es la del primer límite que alcances. Por ejemplo, 180 solicitudes por minuto caben holgadamente bajo las 500 RPM de T1. Sin embargo, si cada solicitud consume de media 4.000 tokens, el tráfico suma unos 720.000 TPM y supera la referencia de 500.000 TPM de T1. En ese caso, repartir las solicitudes no basta: hay que reducir tokens, bajar el ritmo o disponer de más capacidad.

Haz el cálculo con consumo observado, no solo con el máximo configurado. Como estimación inicial:

• solicitudes previstas por minuto frente a RPM;
• tokens medios por solicitud multiplicados por solicitudes por minuto frente a TPM;
• tokens de entrada de todos los lotes pendientes frente a Batch queue;
• margen suficiente para picos, reintentos y variación entre solicitudes.

No conviertas esas tres cifras en datos que OpenAI no ha publicado. En las páginas oficiales comprobadas no aparecen límites específicos de Astra para RPD, TPD, número de solicitudes simultáneas ni una cuota independiente para contexto largo. La ausencia de una cifra no significa cero, ilimitado ni «igual que otro modelo».

El límite efectivo se consulta en Limits y en las cabeceras

Los límites de OpenAI API se aplican a la organización y al proyecto, no a cada usuario por separado. Pueden variar por modelo y algunas familias pueden compartir capacidad. La documentación pública de Astra no confirma que su cuota sea exclusiva, así que no conviene deducirlo.

Abre Limits en la plataforma con la misma organización y el mismo proyecto que usa la clave de producción. Después contrasta ese dato con una respuesta real. Las cabeceras más útiles son:

La sección oficial sobre cabeceras también contempla cabeceras de tokens del proyecto cuando proceda. Los valores de ejemplo de la documentación no son los límites fijos de Astra.

En los registros del incidente guarda, como mínimo, la hora, el modelo, la ruta de la API, la organización o proyecto, el estado HTTP, error.type, error.code y todas las cabeceras de límites. Una captura aislada de «429» no permite saber si agotaste solicitudes, tokens, cuota o si el tráfico creció con demasiada brusquedad.

Si la tabla pública, Limits y las cabeceras no coinciden, utiliza Limits y la respuesta actual para controlar el tráfico. Comprueba también que estás mirando el mismo proyecto que firma la solicitud. Para revisar esa relación, consulta cómo funcionan la clave de API, la organización y el proyecto.

Acceso, nivel y capacidad son comprobaciones distintas

El registro de cambios de la API fecha el lanzamiento de GPT-6 Astra el 3 de septiembre de 2026, pero el acceso se está habilitando de forma progresiva. A 4 de septiembre, la página del modelo seguía describiendo una apertura por fases. Estar en T1–T5 no demuestra por sí solo que el modelo ya esté habilitado para una clave concreta.

Si gpt-6-astra no aparece disponible en la cuenta, comprueba primero el acceso y el proyecto seleccionado. No lo trates automáticamente como un problema de RPM o TPM. Free no es compatible y, durante el despliegue, dos cuentas del mismo nivel pueden recibir acceso en momentos diferentes.

En ChatGPT Enterprise hay además controles propios del espacio de trabajo. La documentación de disponibilidad para Enterprise indica que el despliegue inicial requiere acceso Daybreak y que Astra permanece desactivado de forma predeterminada durante las dos primeras semanas; un administrador puede habilitarlo para usuarios o grupos que cumplan los requisitos. Esa configuración de Chat, Work o Codex no concede acceso a OpenAI API.

La secuencia correcta es:

1. Confirma que la organización o proyecto de la clave puede usar gpt-6-astra.
2. Consulta el nivel y los límites efectivos en Limits.
3. Mide RPM y TPM reales mediante las cabeceras.
4. Dimensiona el tráfico y la cola de Batch con margen.

Un 429 slow_down no es un 503 server_is_overloaded

OpenAI distingue ambos casos en su guía de crecimiento del tráfico y sobrecarga:

slow_down puede aparecer aunque x-ratelimit-remaining-requests o x-ratelimit-remaining-tokens todavía muestre margen. No solo importa el total de la ventana: también importa cómo aumenta la carga. Reducir la concurrencia y escalonar el arranque de los procesos suele ser más útil que rotar claves o lanzar más reintentos.

Un 503 server_is_overloaded describe capacidad temporal del modelo, no saldo insuficiente ni un nivel de uso demasiado bajo. Si persiste tras respetar la espera, revisa OpenAI Status y utiliza otro modelo únicamente si tu aplicación ya tiene una alternativa aprobada y probada.

Tampoco conviene convertir «429» en un diagnóstico completo. Lee siempre error.code. Si el cuerpo devuelve otro código, sigue la causa concreta en vez de aplicar a ciegas la receta de slow_down. Añadir saldo solo tiene sentido cuando el problema real es de cuota o facturación; no eleva automáticamente RPM o TPM.

Reintentos que no empeoran el incidente

Para slow_down y server_is_overloaded, da prioridad a Retry-After. Si no está presente, la recomendación oficial es usar retroceso exponencial con una pequeña aleatoriedad para evitar que todos los procesos vuelvan a la vez.

Un reintento seguro debería cumplir estas reglas:

1. Tener un máximo de intentos y un tiempo total límite.
2. Aumentar la espera después de cada fallo transitorio.
3. Añadir aleatoriedad para repartir los reintentos.
4. Detenerse ante errores no transitorios de acceso, parámetros, cuota o facturación.
5. Mantener un único presupuesto de reintentos entre SDK, pasarela y aplicación.

Este patrón ilustra el cálculo de la espera cuando no hay Retry-After:

ts
const baseMs = 500;
const maxMs = 15_000;

function retryDelay(attempt: number) {
  const exponential = Math.min(maxMs, baseMs * 2 ** attempt);
  const jitter = Math.random() * exponential * 0.25;
  return exponential + jitter;
}

El código de espera no arregla por sí solo el cuello de botella. Si el header de solicitudes se agota primero, limita concurrencia y suaviza las ráfagas. Si se agotan tokens, acorta el historial, elimina contexto irrelevante y ajusta el máximo de salida. Si la carga no necesita respuesta inmediata, pásala a una cola o a Batch.

Para decidir cuándo mantener el mismo modelo y cuándo usar una alternativa, aplica una política explícita como la descrita en reintento frente a cambio de modelo. El modelo alternativo debe estar probado para esa tarea; cambiarlo durante un incidente sin validar calidad, herramientas o formato puede crear un fallo diferente.

Batch y Fast no son atajos equivalentes

Batch ayuda cuando el resultado puede esperar. Permite sacar trabajo de la ruta interactiva, pero sigue teniendo una cola por modelo medida en tokens de entrada pendientes. Antes de enviar un lote grande, suma los tokens de todos los trabajos que todavía no han terminado y compáralos con el valor efectivo de la cuenta.

El modo Fast persigue otra finalidad. La guía oficial de Fast indica que Standard y Fast comparten el mismo límite de frecuencia para un modelo. Por tanto, activar Fast no compra RPM o TPM adicionales ni evita slow_down; Astra Fast también sigue sujeto al control de crecimiento del tráfico.

Para una carga operada desde España hay otra condición relevante: la documentación comprobada señala que GPT-6 Astra Fast no ofrece un SLA de latencia y no admite residencia de datos en la UE. Además, su precio por tokens en la API es el doble de la tarifa Standard correspondiente. Valora esos tres aspectos por separado: latencia, límite y tratamiento de datos no son la misma decisión.

TPM no es la ventana de contexto

La ficha de Astra publica una ventana de contexto de 1.050.000 tokens, un máximo de entrada de 922.000 y un máximo de salida de 128.000. Son límites por solicitud, distintos de los TPM que controlan el volumen por minuto.

También hay un umbral de 272K tokens de entrada a partir del cual cambia el precio de toda la solicitud: 2× para entrada y caché, y 1,5× para salida. Ese umbral es de facturación; no es la ventana de contexto, el máximo de entrada ni una cuota TPM.

La guía general advierte de que los modelos de contexto largo pueden tener límites específicos visibles en la consola. Las páginas públicas comprobadas no muestran una cifra independiente para Astra. Si tu carga supera 272K o se acerca al máximo de entrada, consulta la consola y mide la respuesta actual en vez de extrapolar otro modelo.

OpenAI API no comparte los límites de Work y Codex

Los RPM, TPM y Batch queue de este artículo pertenecen a OpenAI API. Las ventanas de uso de ChatGPT Work y Codex siguen la asignación del plan con el que el usuario inicia sesión; la tabla oficial de precios y uso las expresa como estimaciones de mensajes y créditos, no como throughput de la API.

Esto evita tres confusiones frecuentes:

• Habilitar Astra en un espacio de trabajo de ChatGPT no habilita la clave de API.
• Subir de plan en ChatGPT o comprar créditos de Work/Codex no aumenta por sí solo las RPM o TPM del proyecto de API.
• Iniciar Codex con una API key sí lleva el consumo y los límites a la organización o proyecto asociado a esa clave.

Work y Codex comparten la asignación del plan, y el consumo real varía con el modelo, el contexto, el razonamiento, las herramientas, la recuperación de información y la caché. Sus tasas en créditos tampoco deben convertirse en dólares de API sin una regla contractual explícita. Si el problema ocurre en ese producto, usa la guía de límites de uso de Codex o la comparación entre API key y suscripción de Codex.

Plan de actuación según la señal observada

Solicita más capacidad solo después de estabilizar el tráfico. Reúne el modelo y la ruta de la API exactos, picos y promedios de RPM/TPM, cabeceras de reinicio, concurrencia, tamaño de las solicitudes, reintentos aplicados y proporción de trabajo que podría ir a Batch. Así podrás distinguir una necesidad sostenida de un pico creado por la propia aplicación.

La regla práctica

La tabla T1–T5 de GPT-6 Astra sirve para presupuestar capacidad, no para programar un límite permanente. Primero confirma el acceso; después lee Limits y las cabeceras de la misma organización y del mismo proyecto que usa la clave. Si aparece 429 slow_down, reduce la velocidad de crecimiento. Si aparece 503 server_is_overloaded, trata el fallo como capacidad temporal del modelo. Si se agotan RPM o TPM, corrige el recurso que realmente limita la carga.

Esa separación evita tres remedios falsos: comprar saldo para un problema de frecuencia, activar Fast para buscar más cuota o cambiar un plan de Work/Codex esperando que modifique OpenAI API. Mide el límite vivo, reduce la presión adecuada y pide más capacidad únicamente cuando la carga optimizada siga sin caber.