Erro 429 no GPT-6 Astra: como tratar limite de requisição sem derrubar sua aplicação

Sua aplicação não cai porque o modelo é ruim, ela cai porque ninguém escreveu o except direito

O GPT-6 Astra foi lançado em 3 de setembro de 2026 pela OpenAI, entrou em preview limitado no mesmo dia e liberou para usuários pagos no dia seguinte

Só que o acesso está saindo em fases, nem toda conta tem liberação imediata, e logo depois do lançamento apareceu issue aberta no repositório openai/codex relatando 503 de overload repetido com o modelo

Ou seja: quem já colocou o gpt-6-astra em produção não convive só com token caro, convive com recusa de chamada

E recusa de chamada, sem tratamento, vira tela girando pro usuário

Bora destrinchar cada erro, um por um, com o que fazer em cada caso?

429 Too Many Requests: limite de requisição estourado

Sintoma: a API devolve HTTP 429, com a mensagem Too Many Requests, e o SDK levanta um RateLimitError

Causa: você estourou os limites de requisição da sua conta

Nada de misterioso aqui, é o caso clássico do erro 429 GPT-6 Astra: chegou mais chamada do que a cota permite naquela janela

Solução: backoff exponencial com jitter

A abordagem recomendada é essa mesma: espera crescente entre as tentativas, respeitando o Retry-After quando ele vem na resposta, e aumentando o intervalo por conta própria quando ele não vem

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Em respostas 429 também existe o retry-after-ms, que é a recomendação do servidor em milissegundos

E aqui vai o detalhe que muita gente ignora: trate o valor do Retry-After como PISO, não como número final

Se todos os seus clientes esperarem exatamente os mesmos segundos, todos voltam juntos e você reproduz o 429 em uníssono, lindamente sincronizado kkk

Por isso o jitter, o atraso aleatório que espalha os clientes no tempo

import random

def tempo_de_espera(tentativa, retry_after=None, retry_after_ms=None):
    if retry_after_ms is not None:
        piso = float(retry_after_ms) / 1000
    elif retry_after is not None:
        piso = float(retry_after)
    else:
        piso = 2 ** tentativa

    return piso + random.uniform(0, piso * 0.5)

Como prevenir: olhar o painel antes de bater na parede

A resposta da API expõe o estado do limite nos headers, então dá pra frear antes do erro acontecer

São eles: x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests e x-ratelimit-reset-tokens

Se o remaining está despencando, o certo é desacelerar a fila, não acelerar a esperança

429 que não é limite: saldo zerado e limite de gasto

Sintoma: o mesmo 429 de sempre, mas o retry nunca resolve

Você espera, repete, espera mais, repete de novo, e a resposta segue igual

Causa: nem todo 429 é limite temporário

A mesma resposta pode indicar saldo pré-pago esgotado ou limite de gasto e uso atingido

E erros de cobrança usam error.type igual a insufficient_quota, onde repetir a chamada NÃO restaura o acesso

Solução: casar pelo error.type e cortar o retry na hora

Queimar tentativa em cima de erro de cobrança é só atrasar o inevitável e aumentar a latência do usuário à toa

O caminho certo é falhar rápido, logar e avisar o time responsável pela conta

PERMANENTES_POR_TYPE = {"insufficient_quota"}
PERMANENTES_POR_CODE = {"misalignment_policy_violation"}

def deve_repetir(status, error_type, code):
    if error_type in PERMANENTES_POR_TYPE:
        return False
    if code in PERMANENTES_POR_CODE:
        return False
    if status in (429, 503):
        return True
    return False

Repare que a função olha error.type E code, e não só o status

O code está ali porque tem erro permanente que só se identifica por ele, é o caso do 403 de política que a gente vê logo abaixo

Como prevenir: alerta de saldo e monitoramento do limite de gasto configurado na conta

É chato descobrir que o saldo acabou pelo ticket do cliente, beleza? 😅

429 com code slow_down: rampa rápida demais

Sintoma: 429 com error.type igual a rate_limit_error e code igual a slow_down, mesmo quando você olha os números e jura que está dentro de RPM e TPM

Causa: a taxa de requisições subiu rápido demais

Esse caso existe justamente pra isso: não é o volume total que incomodou, foi a rampa

É o clássico do cron que dispara a fila inteira no segundo zero do minuto

Solução: suavizar a subida

Limite a concorrência do cliente, espace os disparos e faça a carga entrar aos poucos em vez de entrar num soco só

Se o seu worker sai do zero pra centenas de requisições concorrentes em poucos segundos, o problema não é a API, é a sua largada

Como prevenir: fila com taxa controlada, sempre

Disparo em lote é confortável de escrever e péssimo de operar

Uma fila com vazão fixa te dá previsibilidade e ainda deixa o backoff funcionar direito quando o 429 aparecer mesmo assim

503 server_is_overloaded: o modelo sem capacidade agora

Sintoma: HTTP 503 com service_unavailable_error e code igual a server_is_overloaded

Causa: o modelo pedido não tem capacidade naquele momento

Repare que a culpa aqui não é sua, e isso muda a estratégia: não adianta reduzir sua concorrência achando que você exagerou

Solução: backoff e caminho alternativo

Os SDKs oficiais da OpenAI já repetem automaticamente respostas 429 e 503 elegíveis, respeitando o Retry-After, conforme a configuração de retry do SDK

Então antes de escrever seu próprio laço, saiba que já tem um rodando embaixo

Como prevenir: ter pra onde correr

O parâmetro reasoning.effort do gpt-6-astra aceita low, medium, high, xhigh e max (o modelo não suporta none), e o nível mais baixo favorece velocidade e menor consumo de tokens

Se a sua tela precisa responder e não precisa filosofar, low é uma alavanca real

E se o seu drama for demora em vez de recusa, vale ler sobre por que o Astra demora para responder, porque é outro problema com outra solução

Outra saída: o gpt-6-astra também está disponível via Microsoft Azure e Amazon Bedrock, então dá pra desenhar um caminho alternativo em vez de depender de um único endereço

403 misalignment_policy_violation: o erro que retry não resolve

Sintoma: HTTP 403 com error type igual a invalid_request_error e code igual a misalignment_policy_violation, bloqueando a execução ANTES do streaming começar

Causa: o monitoramento de desalinhamento do Astra barrou aquela execução

Solução: casar pelo code e não pelo texto da mensagem

Texto de mensagem muda, code é contrato

Se o seu tratamento de erro faz if "policy" in mensagem, ele vai quebrar em silêncio no dia que a redação da mensagem mudar

Na prática é o misalignment_policy_violation dentro do PERMANENTES_POR_CODE lá do classificador, exatamente como no exemplo acima

Assim o retry para porque o código reconheceu um erro permanente, e não por sorte de o status não estar na lista de repetíveis

E repetir a chamada não resolve, esse erro não é transitório

Como prevenir: separar erro permanente de erro transitório na camada de retry

Essa é a linha divisória do post inteiro: sua camada de retry precisa saber a diferença entre "tenta de novo daqui a pouco" e "não adianta, avisa alguém"

Falha no meio do streaming: quando a resposta já começou

Sintoma: a saída começa a aparecer bonitinha na tela e morre no caminho

O pior dos mundos, porque o usuário viu meia resposta e acha que aquilo é a resposta

Causa: em streaming, a falha pode chegar depois que a saída já começou

Solução: tratar os eventos de falha

O cliente precisa lidar com response.failed, response.incomplete e erros de transporte durante o stream

Nada de assumir que o fim do socket significa conclusão

Como prevenir: nunca marque a resposta como concluída só porque a conexão fechou

Conexão fechada é fato de rede, resposta completa é fato de aplicação, são coisas diferentes

Se você persiste a saída parcial como se fosse final, o bug vira dado no seu banco

Como montar retry, fila e fallback em camadas:

Agora juntando tudo numa arquitetura defensiva, na ordem em que eu montaria

1. Classifique o erro antes de decidir repetir. Leia status HTTP, error.type e code, e só então escolha o caminho. O erro comum deste passo é repetir insufficient_quota junto com o resto: você gasta tentativa, gasta tempo do usuário e não muda nada

2. Decida quem repete: o SDK ou o seu código. No SDK Python da OpenAI o max_retries padrão é 2, ou seja, até 3 requisições no total contando a inicial. O erro comum é empilhar retry do SDK com retry próprio sem perceber: as tentativas internas se multiplicam pelas suas e viram uma latência que ninguém previu

from openai import OpenAI

# retry só no SDK
cliente = OpenAI(max_retries=2)

# ou retry só seu, desligando o de dentro
cliente = OpenAI(max_retries=0)

3. Aplique backoff exponencial com jitter, usando o Retry-After como piso. Quando o header vier, respeite; quando não vier, aumente o intervalo você mesmo. O erro comum é esperar o valor exato e sincronizar todos os clientes no mesmo instante

4. **Leia os headers x-ratelimit-* para frear antes do 429.** Dá pra reagir ao x-ratelimit-remaining-requests e ao x-ratelimit-remaining-tokens em vez de esperar o erro aparecer

restantes_req = resposta.headers.get("x-ratelimit-remaining-requests")
restantes_tok = resposta.headers.get("x-ratelimit-remaining-tokens")

if restantes_req is not None and int(restantes_req) < 5:
    fila.reduzir_vazao()

O erro comum aqui é ler os headers e não fazer nada com eles: log bonito, comportamento igual

5. Mande pra fila o que tolera espera. Nem toda carga precisa de resposta agora, e essa parte não deveria estar competindo por cota com a tela do usuário

params = {
    "model": "gpt-6-astra",
    "service_tier": "flex",
}

O erro comum é tratar job noturno e request de usuário com a mesma prioridade

6. Tenha mensagem de fallback pro caso que esgota as tentativas. Quando acabou o retry, o usuário precisa receber uma resposta clara, e não um spinner eterno. O erro comum é vazar o stack trace ou o texto cru da API pra tela

Quando vale usar Flex, Batch ou Scale Tier em vez de insistir no 429

Insistir é uma estratégia, mas às vezes a resposta certa é mudar o tipo de chamada

Carga assíncrona, avaliações e enriquecimento de dados:

Esse é o território do Flex, com service_tier=flex, suportado pelo gpt-6-astra

O Flex troca latência e garantia de disponibilidade por preço menor, com respostas mais lentas e indisponibilidade ocasional de recurso, e é indicado justamente para tarefas não críticas, avaliações, enriquecimento de dados e cargas assíncronas

Batch e Flex custam metade da tarifa padrão do Astra: US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de saída, contra US$ 10 e US$ 50 do padrão

Metade do preço em cima de uma carga que já era pesada faz diferença grande na fatura, ainda mais quando você soma os reasoning tokens da conta

Ah, e entrada em cache sai a US$ 1 por milhão, então prompt estável também é economia

Fluxo sensível a latência:

Aqui entra o Fast mode, que é o antigo Priority processing renomeado em 30 de julho de 2026

A API continua aceitando os dois valores do parâmetro, service_tier=priority e service_tier=fast

Tome cuidado: o Fast mode não está disponível para o gpt-6-astra em contas com residência de dados na União Europeia

Volume previsível com garantia:

O Scale Tier permite comprar antecipadamente uma cota fixa de tokens de entrada e saída por minuto para um snapshot específico de modelo, com SLA de 99,9% de uptime e computação priorizada

É a opção pra quem não quer que o pico de terça de manhã seja uma surpresa toda terça de manhã

Erros do GPT-6 Astra: repetir, esperar ou desistir

Conclusão

A diferença entre uma aplicação estável e uma que cai não é a quantidade de tentativas, é a classificação do erro ANTES de repetir

Repetir 429 de limite temporário faz sentido, repetir 429 de cobrança é desperdício puro, e repetir 403 de política é só barulho no log

Próximo passo bem prático: logue error.type, code e os headers x-ratelimit-* em produção, pra parar de discutir no achismo

Depois confira o tier da sua conta, lembrando que no Tier 1 o gpt-6-astra tem 500.000 TPM e que a promoção de tier é automática conforme o gasto acumulado na API

E por fim, tire da frente do usuário tudo que tolera espera, mandando essa carga pro Batch ou pro Flex

É retry bem feito, fila com vazão controlada e uma mensagem honesta quando nada der certo

Simples assim, e mto mais barato que aprender no incidente 😀

até o próximo post!