Limites de taxa

O limite

Âmbito	Limite
Por chave de API	60 pedidos por minuto

O limite é aplicado por chave, não por workspace, pelo que duas chaves no mesmo workspace têm cada uma a sua própria margem de 60 por minuto, em vez de partilharem um único conjunto. É um limite de número de pedidos, não de número de tokens: um único pedido que gera uma resposta muito longa conta o mesmo que um que gera uma muito curta, e streaming versus não-streaming não faz diferença na forma como um pedido é contado.

Este limite existe sobretudo como salvaguarda contra ciclos descontrolados, um ciclo de nova tentativa sem recuo, um erro que dispara um pedido por cada tecla premida, e não como um teto significativo para utilização legítima. O tráfego normal de uma aplicação, mesmo uma utilização de chat bastante ativa, fica bem abaixo dele.

Ultrapassar o limite

Um pedido que ultrapasse o limite recebe imediatamente um 429, sem ser colocado em fila ou atrasado, no mesmo envelope de erro que qualquer outro erro:

HTTP/1.1 429 Too Many Requests

{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}

A janela é reposta de forma contínua (rolling), pelo que a resposta certa a um 429 é uma pequena pausa antes de tentar novamente, não mudar para outra chave nem assumir que algo está avariado. Um único 429 no meio de uma rajada de atividade é normal e esperado; 429s repetidos ao longo de várias rajadas separadas são um sinal de que o próprio padrão de pedidos precisa de uma estratégia de recuo, abordada abaixo.

Recuar corretamente

Tentar novamente um 429 de imediato, num ciclo apertado, piora a situação em vez de a melhorar: mantém a taxa de pedidos exatamente onde estava acima do limite, pelo que cada nova tentativa falha da mesma forma. Um atraso curto, idealmente crescente, entre tentativas (algumas centenas de milissegundos, a duplicar a cada falha consecutiva, até um limite sensato) resolve quase todos os 429 em uma ou duas tentativas, sem afetar de forma significativa a latência visível para o utilizador de um pedido normal.

# Python: nova tentativa mínima com recuo exponencial
import time

for attempt in range(4):
    try:
        response = client.chat.completions.create(model="tai-4.1", messages=messages)
        break
    except Exception as e:
        if attempt == 3:
            raise
        time.sleep(0.5 * (2 ** attempt))

Os SDKs oficiais da OpenAI já implementam por defeito um comportamento de nova tentativa com recuo exatamente para este tipo de erro transitório; se estiver a usar um deles, isto provavelmente já é tratado por si sem qualquer código extra, e só verá uma exceção lançada depois de esgotado o seu próprio orçamento de tentativas.

Se 60 por minuto for genuinamente baixo demais

Para a maioria das aplicações, o volume de pedidos é naturalmente limitado pela rapidez com que uma pessoa ou um ciclo de agente consegue de facto gerar pedidos, e 60 por minuto raramente é uma restrição real. Se um caso de uso legítimo está consistentemente a atingir o limite, a primeira coisa a verificar é se os pedidos podem ser agrupados ou consolidados, enviando menos pedidos, maiores, em vez de muitos pequenos para a mesma tarefa subjacente, antes de assumir que o próprio limite precisa de mudar.