Limites de taxa da OpenAI API — qual limite você atingiu, como interpretá-lo e a nova tentativa que resolve

Um 429 da OpenAI significa que você ultrapassou um dos cinco limites — e o primeiro trabalho é descobrir qual, porque as correções apontam em direções opostas. Esta página explica o que cada limite mede, como ler a resposta diretamente nos cabeçalhos, a lógica de novas tentativas que realmente interrompe os erros e o que fazer quando o recuo correto não é suficiente.

Verificado 30 de setembro de 2026 com base na documentação de limites de taxa da OpenAI.

Cinco limites, qualquer um dos quais pode ser acionado

O limite que se esgotar primeiro aciona o erro, portanto “estamos longe do limite de tokens” não é motivo para descartar um limite de taxa — você pode estar longe do TPM e exatamente no RPM. Os limites se aplicam por organização e por modelo, não por chave: criar chaves adicionais não cria cota adicional.

Como é um 429

HTTP/1.1 429 Too Many Requests
retry-after: 12
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 0
x-ratelimit-reset-requests: 12s
x-ratelimit-limit-tokens: 200000
x-ratelimit-remaining-tokens: 143820
x-ratelimit-reset-tokens: 17s

{
  "error": {
    "message": "Rate limit reached for gpt-5.4 in organization org-... on requests per min (RPM).",
    "type": "requests",
    "code": "rate_limit_exceeded"
  }
}

Tudo de que você precisa está nessa resposta. O corpo nomeia a dimensão (“requests per min (RPM)”), e os cabeçalhos informam o limite exato, o que resta e quando ele se recupera.

Níveis de uso

Seus limites são definidos pelo seu nível de uso, que a OpenAI promove automaticamente conforme os gastos acumulados aumentam:

Deliberadamente não reproduzimos aqui: os números de RPM e TPM por modelo. Eles diferem por modelo, mudam conforme novos modelos são lançados e podem ser ajustados por conta — portanto qualquer tabela publicada em uma página de terceiros é uma estimativa com uma data associada. As duas fontes oficiais para sua própria conta são a página de limites no painel da OpenAI e os cabeçalhos x-ratelimit-* em cada resposta que você já recebe. Leia os cabeçalhos.

A correção: respeite Retry-After e depois adicione jitter

A recomendação documentada pela OpenAI é usar recuo exponencial com jitter, seguindo Retry-After quando a resposta o trouxer. As duas partes são importantes. Sem o cabeçalho, você pode tentar novamente cedo demais; sem o jitter, todos os clientes que falharam no mesmo instante tentam novamente no mesmo instante e falham juntos — uma debandada que transforma um segundo ruim em um minuto ruim.

import random, time
import openai

client = openai.OpenAI()

def call_with_backoff(fn, *, max_attempts=6, base=0.5, cap=30.0):
    """Retry 429s: honour Retry-After when present, jittered backoff otherwise."""
    for attempt in range(max_attempts):
        try:
            return fn()
        except openai.RateLimitError as err:
            if attempt == max_attempts - 1:
                raise
            # The server's own answer beats any formula you invent.
            retry_after = (err.response.headers or {}).get("retry-after")
            if retry_after:
                delay = float(retry_after)
            else:
                # Full jitter: sleep a random point in [0, 2^n * base], capped.
                # Without the randomness every client that failed at the same
                # instant retries at the same instant and fails again together.
                delay = random.uniform(0, min(cap, base * 2**attempt))
            time.sleep(delay)

resp = call_with_backoff(lambda: client.responses.create(
    model="gpt-5.4",
    input="Summarise this changelog in three bullets.",
))

O mesmo padrão em TypeScript:

import OpenAI from "openai";

const client = new OpenAI();
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

export async function callWithBackoff<T>(
  fn: () => Promise<T>,
  { maxAttempts = 6, baseMs = 500, capMs = 30_000 } = {},
): Promise<T> {
  for (let attempt = 0; ; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const status = (err as { status?: number }).status;
      if (status !== 429 || attempt === maxAttempts - 1) throw err;

      const retryAfter = (err as { headers?: Headers }).headers?.get("retry-after");
      const delay = retryAfter
        ? Number(retryAfter) * 1000
        : Math.random() * Math.min(capMs, baseMs * 2 ** attempt);
      await sleep(delay);
    }
  }
}

const resp = await callWithBackoff(() =>
  client.responses.create({ model: "gpt-5.4", input: "Hello" }),
);

Os SDKs oficiais já fazem novas tentativas das solicitações que retornam 429 por você, portanto a maioria das aplicações só precisa disso quando encapsula as chamadas em seu próprio cliente HTTP ou quando deseja um comportamento diferente — um limite de espera mais longo para trabalhos em segundo plano ou uma falha imediata para uma solicitação voltada ao usuário, em que esperar 12 segundos é pior que um erro.

Monitore antes que quebre

Os contadores estão em todas as respostas, não apenas nas falhas. Registrar os valores restantes transforma a limitação de taxa de um incidente em um indicador — você vê a margem diminuir dias antes de um lançamento esgotá-la.

# Log the remaining counters on every response, not just on failures.
# By the time you see a 429 the useful signal is already an hour old.
resp = client.responses.with_raw_response.create(model="gpt-5.4", input="…")
h = resp.headers

log.info(
    "openai_quota model=%s req_left=%s tok_left=%s reset_req=%s reset_tok=%s",
    "gpt-5.4",
    h.get("x-ratelimit-remaining-requests"),
    h.get("x-ratelimit-remaining-tokens"),
    h.get("x-ratelimit-reset-requests"),
    h.get("x-ratelimit-reset-tokens"),
)

parsed = resp.parse()   # the normal response object

Dois hábitos que vale a pena adotar junto: alerte quando x-ratelimit-remaining-tokens cair abaixo de alguma fração do limite, em vez de alertar pela contagem de 429, e adicione jitter às programações, não apenas às novas tentativas. Um cron que dispara tudo em :00 cria seu próprio pico.

Quando o recuo não é a resposta

O recuo correto corrige picos. Ele não faz nada para uma demanda sustentada acima do seu limite — nesse caso, as novas tentativas apenas adiam a falha. As correções estruturais, aproximadamente em ordem de esforço:

• Limite a saída. Tokens de raciocínio são cobrados e contabilizados como saída, portanto uma geração sem limite é a maneira mais rápida de consumir TPM.
• Reduza o contexto recuperado. Em um limite de TPM, reduzir pela metade os trechos recuperados dobra seu throughput gratuitamente.
• Dimensione o modelo corretamente. Uma etapa de classificação não precisa de um modelo de ponta, e modelos pequenos têm seu próprio orçamento separado.
• Separe as cargas de trabalho. Trabalhos em lote e tráfego sensível à latência competindo pelo limite de uma única organização são a versão mais comum desse problema causada pelo próprio usuário.
• Aumente o nível. Os níveis avançam com os gastos acumulados, portanto isso muitas vezes já está acontecendo.

Distribuindo a carga entre famílias de modelos

O último item dessa lista é onde um gateway conquista seu lugar. A Kunavo expõe uma API compatível com OpenAI — mesmo SDK, mesmo formato de chamada, uma chave — em várias famílias de modelos, portanto mover uma carga de trabalho para fora de um limite saturado exige alterar a string do modelo, em vez de fazer uma segunda integração:

from openai import OpenAI

client = OpenAI(
    api_key="sk-kn-...",
    base_url="https://api.kunavo.com/v1",
)

# Same SDK, same call shape — the model string chooses the family.
client.chat.completions.create(
    model="gpt-5-6-terra",            # or claude-sonnet-5, claude-haiku-4-5, …
    messages=[{"role": "user", "content": "Hello"}],
)

Concretamente: o trabalho de sumarização em lote que estava competindo com seu tráfego de produção pode ser executado em claude-haiku-4-5 a $0.70 / $3.50 por 1M, enquanto o caminho sensível à latência permanece em gpt-5-6-terra ($0.70 / $4.20) ou claude-sonnet-5 ($1.40 / $7.00). Família diferente, fila diferente.

Seja claro sobre o que isso faz e o que não faz. Ele elimina o gargalo de uma única conta e um único modelo e oferece uma alternativa para failover. Ele não cria capacidade: se o volume total realmente exceder o permitido por qualquer nível individual, a resposta ainda é aumentar o nível ou fazer menos trabalho. As tarifas de todos os modelos estão na página de preços, e o guia equivalente para os limites da Anthropic está em Claude API 429 rate_limit_error.

Perguntas frequentes