DEV Community

Cover image for Limites de Taxa da API GPT: Níveis, Limites de Uso e Como Testar com Apidog
Lucas
Lucas

Posted on • Originally published at apidog.com

Limites de Taxa da API GPT: Níveis, Limites de Uso e Como Testar com Apidog

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?

Experimente o Apidog hoje

💡 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"
  }
}
Enter fullscreen mode Exit fullscreen mode

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:

  1. gasto total da conta;
  2. 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:

  1. 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.
  2. 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:

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:

  1. crie um novo projeto;
  2. adicione uma nova requisição;
  3. configure o método e a URL.
POST https://api.openai.com/v1/chat/completions
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

Clique em Send.

Depois da resposta:

  1. abra a aba Headers no painel de resposta;
  2. localize os campos x-ratelimit-*;
  3. anote limit e remaining para requests e tokens.

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:

  1. abra a requisição salva;
  2. clique no menu ao lado de Send;
  3. selecione Run in Test Scenario;
  4. 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:

  1. Algumas chamadas retornam 429. Isso confirma que o limite está sendo aplicado conforme os cabeçalhos indicam.
  2. 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
}
Enter fullscreen mode Exit fullscreen mode

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-tokens após cada resposta;
  • abortar o cenário quando os tokens restantes caírem abaixo de um limite;
  • registrar latência separadamente para 200 e 429.

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);
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 map paralelo 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:

  1. Reproduza a chamada no Apidog.
  2. Abra os cabeçalhos x-ratelimit-*.
  3. Compare remaining-requests e remaining-tokens.
  4. Leia o corpo do erro.
  5. Classifique o problema: RPM, TPM, RPD ou billing.
  6. Rode um teste pequeno de pico.
  7. Ajuste retry, fila, concorrência ou tamanho do prompt.
  8. 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
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)