Você lança uma função que chama a API GPT. Ela funciona bem em staging. Os primeiros cem usuários a acessam em produção, e seus logs se enchem de 429 Too Many Requests. Agora você está adivinhando: são requisições por minuto, tokens por minuto ou limites diários? Você ainda está no nível 1? O modelo para o qual você mudou na semana passada tinha limites mais rigorosos do que o anterior?
💡 Este guia mostra como diagnosticar limites de taxa em modelos GPT atuais usando chamadas de API, cabeçalhos de resposta e um teste de carga pequeno no Apidog. No fim, você terá um fluxo repetível para descobrir exatamente qual limite está sendo atingido e uma coleção reutilizável para sua equipe.
Se você já trabalhou com OpenAI antes, sabe que a história dos limites de taxa ficou mais complexa a cada novo modelo. O GPT-5.5 tem limites diferentes do GPT-4.1, modelos de imagem contam de forma diferente dos modelos de texto, e seu nível de uso muda conforme seus gastos aumentam.
O Apidog ajuda a inspecionar cabeçalhos de resposta, simular tráfego concorrente e confirmar qual limite você está atingindo antes de enviar código para produção.
Os quatro limites que realmente importam
A OpenAI aplica vários limites de taxa a cada chave de API GPT. Em produção, você normalmente precisa monitorar estas quatro dimensões:
| Limite | O que significa | Quando costuma quebrar |
|---|---|---|
| RPM | Requisições por minuto | Muitas chamadas pequenas em paralelo |
| TPM | Tokens por minuto, somando entrada e saída | Prompts grandes, RAG, contexto longo |
| RPD | Requisições por dia | Chaves gratuitas ou contas em níveis baixos |
| IPM / TPD / fila de lote | Limites específicos para imagem, áudio, embeddings e batch | Workloads fora de texto/chat |
Quando uma requisição é recusada, a API retorna HTTP 429 com um corpo semelhante a este:
{
"error": {
"message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
"type": "tokens",
"param": null,
"code": "rate_limit_exceeded"
}
}
Leia primeiro o campo message e o campo type. Eles indicam se você excedeu:
-
tokens: limite de TPM; -
requests: limite de RPM; -
tokens_usage_based: limite relacionado ao uso de tokens; - cota ou faturamento: problema de billing, não necessariamente de rate limit.
Um 429 de TPM não é resolvido da mesma forma que um 429 de RPM.
Referências úteis:
Como funcionam os níveis da OpenAI
Sua chave de API GPT pertence a um nível de uso da OpenAI. Esse nível define os valores reais de RPM e TPM.
Você sobe de nível com base em dois fatores:
- gasto total da conta;
- tempo desde o primeiro pagamento.
Estrutura aproximada para modelos de texto:
| Nível | Gasto mínimo | Período de espera | RPM de texto | TPM de texto |
|---|---|---|---|---|
| Grátis | nenhum | nenhum | 3 | 40k |
| 1 | US$ 5 pagos | nenhum | 500 | 30k–200k por modelo |
| 2 | US$ 50 pagos | 7 dias | 5.000 | 450k |
| 3 | US$ 100 pagos | 7 dias | 5.000 | 1M |
| 4 | US$ 250 pagos | 14 dias | 10.000 | 2M |
| 5 | US$ 1.000 pagos | 30 dias | 10.000 | 2M+ |
Esses números são ilustrativos. Os limites mudam com o tempo e variam por modelo. Antes de dimensionar uma carga real, leia os limites atuais no painel da OpenAI ou nos cabeçalhos de resposta da própria API.
Implicações práticas:
- Promoção é automática. Quando sua conta ultrapassa o gasto mínimo e o período de espera termina, as próximas requisições passam a usar os novos limites.
- Rebaixamento pode acontecer. Inatividade prolongada ou falha de pagamento pode reduzir seu nível. Teste novamente depois de mudanças de cobrança.
Para comparar com outros provedores, veja também:
- explicador de limites de taxa de usuário da API OpenAI
- guia de limites de taxa da API Claude
- guia de limites de taxa da API Grok-3
Leia seus limites em tempo real pelos cabeçalhos
Você não precisa depender apenas de painéis. Cada resposta da API GPT inclui cabeçalhos de rate limit.
Procure estes campos:
| Cabeçalho | Uso |
|---|---|
x-ratelimit-limit-requests |
Limite de RPM para o endpoint |
x-ratelimit-remaining-requests |
Requisições restantes na janela atual |
x-ratelimit-limit-tokens |
Limite de TPM |
x-ratelimit-remaining-tokens |
Tokens restantes na janela atual |
x-ratelimit-reset-requests |
Tempo até reabastecer requisições |
x-ratelimit-reset-tokens |
Tempo até reabastecer tokens |
Os campos reset normalmente retornam valores como 6s ou 1m30s.
A forma mais simples de validar seus limites é enviar uma requisição mínima, abrir os cabeçalhos da resposta e registrar os valores retornados.
Passo 1: configure a requisição GPT no Apidog
No Apidog:
- crie um novo projeto;
- adicione uma nova requisição;
- configure o método e a URL.
POST https://api.openai.com/v1/chat/completions
Na aba Headers, adicione:
| Chave | Valor |
|---|---|
Authorization |
Bearer {{OPENAI_API_KEY}} |
Content-Type |
application/json |
A variável {{OPENAI_API_KEY}} deve ser definida em Environments. Assim, a chave não fica fixa dentro da requisição. Você também pode usar variáveis para IDs de organização e projeto, caso use atribuição de faturamento.
Na aba Body, selecione JSON e cole:
{
"model": "gpt-5.5",
"messages": [
{
"role": "user",
"content": "ping"
}
],
"max_tokens": 10
}
Clique em Send.
Depois da resposta:
- abra a aba Headers no painel de resposta;
- localize os campos
x-ratelimit-*; - anote
limiteremainingpararequestsetokens.
Esses valores são sua linha de base.
Se quiser configurar uma requisição de chat-completion com mais detalhes, veja o guia sobre como testar a API ChatGPT com Apidog.
Passo 2: confirme o RPM com um pico controlado
Ler os cabeçalhos mostra o limite. Mas você ainda precisa validar como a API se comporta quando esse limite é alcançado.
No Apidog:
- abra a requisição salva;
- clique no menu ao lado de Send;
- selecione Run in Test Scenario;
- configure um pico pequeno.
Exemplo:
| Configuração | Valor |
|---|---|
| Iterações | 50 |
| Concorrência | 10 |
| Atraso entre iterações | 0 ms |
Execute o cenário.
Resultados esperados:
-
Algumas chamadas retornam
429. Isso confirma que o limite está sendo aplicado conforme os cabeçalhos indicam. -
Todas retornam
200. Seu RPM pode ser maior do que o esperado. Verifique os cabeçalhos de resposta para confirmar o valor real.
No relatório do executor, ordene por código de status e abra as respostas 429. O corpo da resposta dirá se você excedeu RPM, TPM ou limite diário.
Para um guia mais amplo sobre erros 429, veja o guia de limite de taxa excedido.
Passo 3: separe estouros de RPM e TPM
O teste anterior mede principalmente RPM, porque a requisição é pequena.
Para testar TPM, envie menos requisições, mas com payload maior:
{
"model": "gpt-5.5",
"messages": [
{
"role": "system",
"content": "<3,000 tokens de contexto aqui>"
},
{
"role": "user",
"content": "Resuma o acima em uma frase."
}
],
"max_tokens": 200
}
Execute outro cenário:
| Configuração | Valor sugerido |
|---|---|
| Iterações | 20 |
| Concorrência | 5 |
| Atraso | 0 ms |
Se você estiver em um nível com TPM baixo, provavelmente atingirá o limite de tokens antes do limite de requisições.
A correção depende da dimensão:
| Problema | Sintoma | Correção |
|---|---|---|
| RPM | Muitas chamadas pequenas | fila, batch, controle de concorrência |
| TPM | Poucas chamadas grandes | reduzir prompt, cachear contexto, dividir requisição |
| RPD | Limite diário atingido | revisar plano, faturamento ou volume diário |
| Billing | Mensagem de cota/faturamento | resolver no painel de cobrança |
Passo 4: simule usuários concorrentes
Um pico artificial mede o teto. Produção é diferente: usuários simultâneos, tamanhos variados de prompt e picos sobre uma linha de base.
No Apidog, crie um cenário com três ou quatro variações da mesma requisição:
- pequena;
- média;
- grande;
- uma versão próxima do pior caso.
Use scripts JavaScript de pré e pós-requisição para:
- escolher aleatoriamente o tamanho da mensagem;
- ler
x-ratelimit-remaining-tokensapós cada resposta; - abortar o cenário quando os tokens restantes caírem abaixo de um limite;
- registrar latência separadamente para
200e429.
Exemplo de lógica de pós-requisição:
const remainingTokens = Number(response.headers.get("x-ratelimit-remaining-tokens"));
if (!Number.isNaN(remainingTokens) && remainingTokens < 1000) {
console.log("TPM próximo do limite:", remainingTokens);
}
Ao final, use o histograma de códigos de status como artefato de runbook. Quando alguém perguntar “estamos com rate limit?”, execute o mesmo cenário e compare o resultado.
O que fazer quando você é limitado
Depois de medir onde está a barreira, escolha a estratégia correta.
1. Aplique retry com backoff
Cada chamada GPT deve ter retry com backoff exponencial.
Quando a resposta for 429, leia:
x-ratelimit-reset-tokens
x-ratelimit-reset-requests
Use esse valor como atraso inicial. Ele é mais preciso do que um sleep fixo.
Exemplo em Python:
import time
import requests
def call_with_retry(payload, headers, max_attempts=5):
url = "https://api.openai.com/v1/chat/completions"
for attempt in range(max_attempts):
response = requests.post(url, json=payload, headers=headers)
if response.status_code != 429:
return response
reset_tokens = response.headers.get("x-ratelimit-reset-tokens")
reset_requests = response.headers.get("x-ratelimit-reset-requests")
if reset_tokens:
delay = parse_reset_header(reset_tokens)
elif reset_requests:
delay = parse_reset_header(reset_requests)
else:
delay = 2 ** attempt
time.sleep(delay)
return response
def parse_reset_header(value):
if value.endswith("ms"):
return float(value[:-2]) / 1000
if value.endswith("s"):
return float(value[:-1])
if value.endswith("m"):
return float(value[:-1]) * 60
return 1
2. Enfileire requisições
Se seu tráfego vem em picos, coloque as chamadas em uma fila e drene em uma taxa abaixo do limite.
Um padrão comum é usar um limitador tipo token bucket um pouco abaixo do TPM real.
Leia mais em:
3. Use batch quando a resposta não precisa ser síncrona
A API de Lote da OpenAI é adequada para workloads que toleram tempo de resposta maior, como:
- enriquecimento noturno;
- classificação de documentos;
- reconstrução de embeddings;
- processamento offline.
Isso libera a cota síncrona para tráfego voltado ao usuário.
Para entender a diferença entre throttling e rate limiting, veja throttling vs. limite de taxa.
Erros comuns de GPT 429
Rate limit reached ... requests per min (RPM)
Seu código está disparando chamadas demais por minuto.
Ações:
- limite o número de workers;
- evite
mapparalelo sem controle; - use fila;
- distribua chamadas ao longo do tempo.
Regra prática: configure o pool de workers abaixo do RPM dividido por um fator de segurança.
Rate limit reached ... tokens per min (TPM)
Suas chamadas estão consumindo tokens demais.
Ações:
- reduza prompts de sistema;
- corte contexto desnecessário;
- evite inserir documentos inteiros em pipelines RAG;
- use cache quando aplicável;
- divida requisições grandes.
You exceeded your current quota, please check your plan and billing details
Esse erro parece um 429, mas costuma indicar problema de cobrança ou cota.
Possíveis causas:
- limite mensal de gastos atingido;
- cartão falhou;
- saldo pré-pago zerado;
- plano insuficiente.
A correção está no painel de faturamento, não no código.
Checklist de diagnóstico
Use este fluxo quando aparecer um 429 em produção:
- Reproduza a chamada no Apidog.
- Abra os cabeçalhos
x-ratelimit-*. - Compare
remaining-requestseremaining-tokens. - Leia o corpo do erro.
- Classifique o problema: RPM, TPM, RPD ou billing.
- Rode um teste pequeno de pico.
- Ajuste retry, fila, concorrência ou tamanho do prompt.
- Salve a requisição e o cenário para reutilização pela equipe.
FAQ
O Apidog custa algo para testar limites de taxa do GPT?
Não. O plano gratuito cobre testes de requisição única e pequenas execuções concorrentes. Você só precisa de um plano pago para cargas maiores, espaços de trabalho em equipe ou execuções agendadas. Veja os preços do Apidog.
Posso testar limites de taxa sem gastar tokens reais?
Parcialmente.
A verificação mais barata é uma requisição com:
{
"max_tokens": 1
}
e uma mensagem mínima. Os cabeçalhos retornam completos.
Para testes de pico, você gasta tokens reais. Para testar a lógica de retry sem chamar a OpenAI, use o mock server do Apidog para simular respostas 429.
Por que minha chave de nível 1 parece mais lenta do que a de um colega?
Os limites são por organização, não apenas por chave. Se outras pessoas na mesma organização estão consumindo tokens, você compete com esse tráfego.
Teste as duas chaves lado a lado no Apidog e compare o decaimento de:
x-ratelimit-remaining-tokens
x-ratelimit-remaining-requests
Como sei qual modelo tem qual limite?
Leia os cabeçalhos de resposta. Não confie apenas em tabelas genéricas.
Faça uma requisição barata para cada modelo e registre os cabeçalhos. Snapshots diferentes, como gpt-5.5 e gpt-5.5-0901, podem ter limites diferentes.
Requisições de streaming contam de forma diferente?
Sim para TPM.
Uma requisição de streaming pode reservar tokens antecipadamente com base em max_tokens. Se max_tokens estiver alto demais, você pode consumir orçamento de TPM mesmo quando a conclusão real for curta.
Defina max_tokens com um teto realista. O comportamento de streaming também é abordado em como testar a API ChatGPT com Apidog.
Posso compartilhar o teste de limite de taxa com minha equipe?
Sim. Salve a requisição e o cenário de teste em um projeto compartilhado no Apidog. Cada pessoa pode trocar o ambiente e executar o mesmo teste com sua própria chave.
Isso transforma a pergunta “minha chave está limitada ou a deles?” em uma verificação rápida e reproduzível.
Top comments (0)