Niveles de uso de la API de OpenAI explicados: Build, Launch, Grow y topes de gasto

Actualizado October 7, 2026 · publicado originalmente October 7, 2026

OpenAI simplificó sus niveles de pago de la API en Build, Launch y Grow el 6 de octubre de 2026. Las organizaciones suben de nivel automáticamente cuando las compras acumuladas de crédito superan cada umbral, lo que por lo general desbloquea límites de tasa más altos. El nivel es una señal de capacidad y de margen de uso mensual; es independiente de los límites de gasto por proyecto u organización, que deben configurarse como controles presupuestarios.

¿Qué cambió en los niveles de uso de la API de OpenAI?

El changelog del 6 de octubre de OpenAI indica que la plataforma de API pasó de cinco niveles de pago a tres: Build, Launch y Grow. La guía de límites de tasa vigente enumera estos niveles de calificación: Build con $5 en compras totales de crédito, Launch con $100 y Grow con $500. También menciona un límite de uso de $100 al mes para los usuarios elegibles del nivel gratuito. OpenAI afirma que los niveles superiores suelen recibir límites de tasa más altos por modelo.

Los importes de compra son umbrales acumulados que determinan la elegibilidad del nivel. No son el precio de una suscripción mensual ni una promesa de que su organización gastará exactamente esa cantidad cada mes. La guía publicada los describe como compras totales de crédito. Consulte el panel de su organización para ver su nivel real, el límite de uso mensual aprobado y los límites por modelo; lo que importa para la planificación operativa es el estado de su organización.

¿Qué aporta un nivel superior a un equipo?

Los límites de tasa pueden restringir las solicitudes por minuto (RPM), los tokens por minuto (TPM), el volumen diario, el rendimiento de imágenes o el trabajo en cola de Batch. Un trabajo puede estar por debajo de su límite de uso mensual y aun así alcanzar un límite por minuto. La guía actual muestra diferencias según el modelo: para GPT-6 Astra, Sol y Terra, sus ejemplos estándar de RPM/TPM pasan de 5,000 RPM y 1 millón de TPM en Build a 10,000 RPM y 4 millones de TPM en Launch, y a 15,000 RPM y 40 millones de TPM en Grow. Los límites estándar indicados para GPT-6 Luna vuelven a ser distintos. Son valores de referencia publicados, no un sustituto de los límites que se muestran para su organización, modelo y proyecto.

Esta distinción importa durante los lanzamientos. Un equipo puede prever un margen mensual suficiente y aun así sufrir limitaciones cuando una nueva carga de trabajo envía tráfico demasiado rápido o supera su rendimiento de solicitudes o tokens. Los límites de tasa también pueden aplicarse a nivel de organización y de proyecto, y distintos modelos pueden compartir un límite. Lea las cabeceras de respuesta y el panel antes de tratar el nombre de un nivel como una garantía de capacidad.

¿Sirven los niveles de uso para limitar el gasto mensual?

No. OpenAI documenta los límites de uso mensual aprobados por separado de los límites de gasto configurables de la organización o del proyecto. Una alerta de gasto envía una notificación mientras el tráfico de la API continúa. Un límite de gasto estricto bloquea las solicitudes afectadas con una respuesta 429 cuando se alcanza el importe configurado. Elija el tope estricto cuando importe la aplicación efectiva; una alerta es visibilidad, no un cortacircuitos.

Esto también significa que comprar crédito para cruzar un umbral de nivel no es, por sí solo, una política segura de control de costes. El nivel puede mejorar el rendimiento, pero no sustituye la responsabilidad por proyecto, el enrutamiento de alertas, la previsión de uso ni un tope estricto deliberado. Un grupo de ingeniería que necesite más capacidad para un lanzamiento debería modelar tanto el umbral de compra necesario para calificar como el techo de gasto mensual por separado que Finanzas quiere hacer cumplir.

¿Cómo deben gobernar Finanzas e ingeniería las subidas de nivel?

1. Inventaríe la organización y los proyectos. Registre el nivel, el margen de uso mensual, los RPM/TPM por modelo, los límites compartidos y los responsables de cada proyecto en producción.
2. Fije controles de gasto explícitos. Configure límites estrictos a nivel de proyecto donde el tráfico deba detenerse en un presupuesto fijo, y alertas donde los equipos necesiten un aviso temprano. No dé por hecho que el margen del nivel aporta este control.
3. Estime el crecimiento de la carga de trabajo. Prevea las solicitudes y los tokens por minuto además del gasto mensual en tokens. Un servicio puede alcanzar un límite de rendimiento mucho antes que un techo mensual en dólares.
4. Controle las compras ligadas al nivel. Trate las compras adicionales de crédito que hacen avanzar el umbral acumulado como una decisión de acceso y capacidad. Exija una previsión de la carga de trabajo, un responsable y la revisión de los controles existentes antes de solicitarlas.
5. Observe la respuesta real. Use las cabeceras de límites de tasa y los registros para distinguir el agotamiento de solicitudes, tokens u otros límites. Aplique retroceso (backoff) ante respuestas temporales de límite de tasa en lugar de provocar una tormenta de reintentos.

Por ejemplo, hipotéticamente, un equipo de producto espera que una campaña de lanzamiento triplique las solicitudes por minuto pero mantenga el uso mensual de tokens por debajo del tope de Finanzas. La cuestión operativa es si los RPM y TPM del proyecto para cada modelo pueden soportar el aumento. La cuestión financiera es si el límite de gasto estricto está fijado en el presupuesto aprobado de la campaña. Son revisiones relacionadas, pero son controles distintos.

¿Cómo debe decidir un equipo si pasar de Build a Launch?

Parta de la evidencia de la carga de trabajo, no de la etiqueta del nivel. Si los registros de producción muestran un agotamiento repetido de límites en el nivel actual, estime el margen de RPM y TPM necesario, identifique qué límites de modelo y proyecto se aplican y confirme el efecto del nivel en el panel. Después compare la compra de crédito necesaria para calificar con el valor de negocio y la política presupuestaria. Si los límites actuales bastan, subir de nivel solo porque existe el siguiente no aporta ningún beneficio operativo.

OpenAI señala que los niveles superiores suelen elevar los límites, y los umbrales publicados pueden cambiar. Vuelva a consultar la guía de límites de tasa y el panel antes de un ciclo presupuestario o de un cambio material de tráfico. Mantenga la revisión de alertas de gasto y de topes estrictos dentro de la misma rutina mensual de FinOps que la mezcla de modelos, los reintentos y el coste por tarea exitosa.

¿Cuál es la conclusión práctica?

Build, Launch y Grow responden a una pregunta de capacidad: ¿qué límites y margen de uso pueden aplicarse a medida que aumentan las compras acumuladas de una organización? Sus controles de gasto responden a una pregunta presupuestaria: ¿cuándo debe avisarse a los equipos y cuándo deben detenerse las solicitudes? Haga seguimiento de ambas. Una subida de nivel puede desbloquear rendimiento, pero solo un límite estricto configurado por separado impone un límite mensual de coste.

¿Qué investigación relacionada deberían leer los equipos?

• Los límites de tasa son un control de costes
• El gasto comprometido es una apuesta sobre su previsión
• Un runbook de producción para un pico de costes de LLM

Relacionado

• Los límites de tasa son un control de costes
• Gasto comprometido y previsiones
• Runbook para picos de costes de LLM

¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita →

Volver a finopsllm.com