Níveis de uso da API da OpenAI explicados: Build, Launch, Grow e tetos de gasto
Atualizado October 7, 2026 · publicado originalmente October 7, 2026
A OpenAI simplificou seus níveis pagos da API em Build, Launch e Grow em 6 de outubro de 2026. As organizações sobem de nível automaticamente quando as compras acumuladas de crédito ultrapassam cada limite, o que em geral libera limites de taxa mais altos. O nível é um sinal de capacidade e de franquia de uso mensal; é separado dos limites de gasto por projeto ou organização, que precisam ser configurados como controles de orçamento.
O que mudou nos níveis de uso da API da OpenAI?
O changelog de 6 de outubro da OpenAI diz que a plataforma de API passou de cinco níveis pagos para três: Build, Launch e Grow. O guia de limites de taxa atual lista estes níveis de qualificação: Build com $5 em compras totais de crédito, Launch com $100 e Grow com $500. Ele também menciona um limite de uso de $100 por mês para usuários elegíveis do nível gratuito. A OpenAI afirma que os níveis mais altos geralmente recebem limites de taxa maiores por modelo.
Os valores de compra são limites acumulados usados para determinar a elegibilidade do nível. Não são o preço de uma assinatura mensal, nem uma promessa de que sua organização gastará exatamente esse valor todo mês. O guia publicado os descreve como compras totais de crédito. Consulte o painel da sua organização para ver o nível real, o limite de uso mensal aprovado e os limites por modelo; o que importa para o planejamento operacional é o status da sua organização.
O que um nível mais alto oferece a uma equipe?
Os limites de taxa podem restringir requisições por minuto (RPM), tokens por minuto (TPM), volume diário, vazão de imagens ou trabalho em fila do Batch. Um job pode estar abaixo do limite de uso mensal e ainda assim atingir um limite por minuto. O guia atual mostra diferenças por modelo: para GPT-6 Astra, Sol e Terra, seus exemplos padrão de RPM/TPM sobem de 5,000 RPM e 1 milhão de TPM no Build para 10,000 RPM e 4 milhões de TPM no Launch, e 15,000 RPM e 40 milhões de TPM no Grow. Os limites padrão listados para o GPT-6 Luna são diferentes novamente. São valores de referência publicados, não um substituto dos limites exibidos para a sua organização, modelo e projeto.
Essa distinção importa durante lançamentos. Uma equipe pode prever uma franquia mensal suficiente e ainda assim sofrer limitação quando uma nova carga de trabalho envia tráfego rápido demais ou excede sua vazão de requisições ou tokens. Os limites de taxa também podem se aplicar nos níveis de organização e de projeto, e modelos diferentes podem compartilhar um limite. Leia os cabeçalhos de resposta e o painel antes de tratar o nome de um nível como garantia de capacidade.
Os níveis de uso servem para limitar o gasto mensal?
Não. A OpenAI documenta os limites de uso mensal aprovados separadamente dos limites de gasto configuráveis da organização ou do projeto. Um alerta de gasto envia uma notificação enquanto o tráfego da API continua. Um limite de gasto rígido bloqueia as requisições afetadas com uma resposta 429 quando o valor configurado é atingido. Escolha o teto rígido quando a aplicação efetiva importar; um alerta é visibilidade, não um disjuntor.
Isso também significa que comprar crédito para ultrapassar o limite de um nível não é, por si só, uma política segura de controle de custos. O nível pode melhorar a vazão, mas não substitui a responsabilidade por projeto, o roteamento de alertas, a previsão de uso nem um teto rígido deliberado. Um grupo de engenharia que precisa de mais capacidade para um lançamento deve modelar tanto o limite de compra necessário para se qualificar quanto o teto de gasto mensal separado que o Financeiro quer ver aplicado.
Como o Financeiro e a engenharia devem governar as subidas de nível?
- Faça o inventário da organização e dos projetos. Registre o nível, a franquia de uso mensal, os RPM/TPM por modelo, os limites compartilhados e os responsáveis por cada projeto em produção.
- Defina controles de gasto explícitos. Configure limites rígidos por projeto onde o tráfego deva parar em um orçamento fixo e alertas onde as equipes precisem de um aviso antecipado. Não presuma que a franquia do nível forneça esse controle.
- Estime o crescimento da carga de trabalho. Preveja requisições e tokens por minuto, além do gasto mensal em tokens. Um serviço pode atingir um limite de vazão muito antes de chegar a um teto mensal em dólares.
- Controle as compras ligadas ao nível. Trate compras adicionais de crédito que avançam o limite acumulado como uma decisão de acesso e capacidade. Exija uma previsão da carga de trabalho, um responsável e a revisão dos controles existentes antes de solicitá-las.
- Observe a resposta real. Use os cabeçalhos de limite de taxa e os logs para distinguir o esgotamento de requisições, tokens ou outros limites. Aplique backoff às respostas temporárias de limite de taxa em vez de criar uma tempestade de novas tentativas.
Por exemplo, hipoteticamente, uma equipe de produto espera que uma campanha de lançamento triplique as requisições por minuto, mas mantenha o uso mensal de tokens abaixo do teto do Financeiro. A pergunta operacional é se os RPM e TPM do projeto por modelo suportam o aumento. A pergunta financeira é se o limite de gasto rígido está definido no orçamento aprovado da campanha. São revisões relacionadas, mas controles diferentes.
Como uma equipe deve decidir se vai do Build para o Launch?
Parta da evidência da carga de trabalho, não do rótulo do nível. Se os logs de produção mostram esgotamento repetido de limites no nível atual, estime a folga de RPM e TPM necessária, identifique quais limites de modelo e projeto se aplicam e confirme o efeito do nível no painel. Depois compare a compra de crédito exigida para se qualificar com o valor de negócio e a política de orçamento. Se os limites atuais bastam, subir de nível só porque o próximo existe não traz nenhum benefício operacional.
A OpenAI observa que níveis mais altos geralmente elevam os limites, e os limites publicados podem mudar. Reverifique o guia de limites de taxa e o painel antes de um ciclo orçamentário ou de uma mudança material de tráfego. Mantenha a revisão de alertas de gasto e de tetos rígidos na mesma rotina mensal de FinOps que trata de mix de modelos, novas tentativas e custo por tarefa bem-sucedida.
Qual é a conclusão prática?
Build, Launch e Grow respondem a uma pergunta de capacidade: quais limites e franquia de uso podem se aplicar à medida que as compras acumuladas de uma organização aumentam? Seus controles de gasto respondem a uma pergunta de orçamento: quando as equipes devem ser avisadas e quando as requisições devem parar? Acompanhe ambos. Uma subida de nível pode liberar vazão, mas somente um limite rígido configurado separadamente impõe um limite mensal de custo.
Quais pesquisas relacionadas as equipes devem ler?
- Limites de taxa são um controle de custos
- Gasto comprometido é uma aposta na sua previsão
- Um runbook de produção para um pico de custos de LLM
Artigos relacionados
- Limites de taxa são um controle de custos
- Gasto comprometido e previsões
- Runbook para picos de custos de LLM
Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita →