Rate limits da plataforma
Cada workspace é limitado a um número fixo de solicitações por minuto, de acordo com a assinatura. Quando o limite é atingido, as solicitações são rejeitadas com429 Too Many Requests até que a janela de 60 segundos seja reiniciada.
- Os limites usam uma janela fixa de 60 segundos que começa com a primeira solicitação, a mesma janela usada nos limites de solicitações por minuto dos budgets.
- Solicitações roteadas por uma chave de integração de provedor ou para um modelo privado contam para esses limites como qualquer outra solicitação. Consulte Faturamento BYOK.
- Planos Enterprise podem negociar limites por minuto maiores com o Toqan Router.
- Deployments on-premise são licenciados, e não medidos: os limites baseados no plano não se aplicam. Um limite único para todo o sistema pode ser aplicado com a variável de ambiente
ORQ_SYSTEM_RPM_LIMIT.
429 com um header Retry-After e os headers X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset.
Limites de orçamento
Os Budgets aplicam limites configurados a um destino nomeado. Um budget define um ou mais limites: Cost em USD, Tokens e Requests per minute. Consulte Budgets para saber como configurá-los. O limite de solicitações por minuto sempre usa uma janela de 60 segundos que começa com a primeira solicitação, independentemente do período de reinício. Um budget mensal de50 req/min continua permitindo 50 solicitações em qualquer minuto, e o contador é reiniciado 60 segundos após a primeira solicitação da janela, e não no fim do mês. O período de reinício (Daily, Weekly, Monthly, Yearly, One-time) se aplica apenas aos limites de custo e de tokens.
Limites em uma chave de API
As chaves de API não têm campos de limite próprios. Defina limites de custo, tokens ou solicitações por minuto em uma chave criando um Budget com escopo nessa API Key. A capacidade restante da chave fica visível na página de detalhes do budget, e a capacidade de custo e de tokens aparece nos headers de respostaX-RateLimit-*-Cost e X-RateLimit-*-Tokens.
Os headers sem sufixo
X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset informam o rate limit da plataforma do plano em uma solicitação bem-sucedida, e não o limite de solicitações por minuto de um budget, porque o limitador da plataforma os grava por último. Os valores de solicitações por minuto de um budget aparecem nesses headers apenas em um 429 gerado por esse budget. Em vez disso, consulte o consumo de solicitações do budget na página de detalhes do budget.Vários limites em uma solicitação
Uma solicitação pode corresponder a vários budgets ao mesmo tempo: por exemplo, um budget com escopo no workspace e outro com escopo na chave de API que fez a chamada. Todos os budgets correspondentes são aplicados, e cada um acompanha o próprio uso. Prevalece o limite aplicável mais restritivo. Consulte Níveis de budget e interação para conhecer as regras completas e exemplos práticos.Rate limits do provedor
O provedor upstream aplica os próprios limites de taxa e de concorrência à conta por trás da integração do provedor. O gateway não coloca solicitações em fila: não há profundidade de fila, posição na fila nem timeout de fila para configurar. Quando o provedor retorna um erro de rate limit ou outro erro que permite nova tentativa:- O gateway mantém a solicitação aberta apenas durante o backoff da nova tentativa. Ele aguarda o intervalo
Retry-Afterretornado pelo provedor e usa um backoff padrão quando esse intervalo não está presente. - Com uma configuração de retry na solicitação ou no agente, ele tenta novamente até a quantidade configurada dentro da mesma solicitação.
- Com uma cadeia de fallback, uma série de tentativas esgotada passa para o próximo modelo.
- Se todas as tentativas falharem, o erro do provedor é retornado ao chamador como resposta.
A resposta 429
Quando qualquer limite é excedido, o gateway retorna429 Too Many Requests com um corpo de erro compatível com a OpenAI. As rejeições de budget incluem scope_kind, scope_target_id e dimension:
Budget rejection (requests per minute)
code e dimension identificam o limite excedido:
scope_kind e scope_target_id identificam qual budget rejeitou a solicitação e estão presentes apenas em rejeições de budget. O texto de message varia conforme o tipo de limite; use o campo code para correspondência programática.
Headers de rate limit
Os headers de rate limit são emitidos por dimensão, e cada grupo de três só está presente quando a dimensão se aplica à solicitação. Portanto, uma resposta contém alguns desses headers, e não todos. Os headers aparecem tanto em solicitações bem-sucedidas (mostrando a capacidade restante) quanto em rejeições.
Dois casos removem headers que a tabela lista como sempre presentes. O trio sem sufixo
X-RateLimit-* é omitido quando a solicitação não tem contexto de workspace e, em deployments on-premise, a menos que ORQ_SYSTEM_RPM_LIMIT esteja definido. Retry-After é omitido quando um budget que rejeitou a solicitação nunca é reiniciado por relógio, como um budget One-time.
Retries e fallbacks
429 permite nova tentativa. O recurso de Retries do gateway tenta novamente em 429 por padrão, com backoff exponencial, e respeita o header Retry-After, e os fallbacks roteiam para um modelo de backup quando o principal atinge o rate limit. Os retries são executados dentro do gateway em uma única solicitação recebida (o limitador da plataforma conta as solicitações de entrada dos clientes, e não as chamadas upstream); portanto, não consomem cota adicional da plataforma nem do budget.
Veja também
Budgets
Crie budgets com limites de custo, tokens e solicitações por minuto e configure alertas.
Níveis de budget
Como budgets em diferentes níveis interagem quando vários se aplicam à mesma solicitação.
Chaves de API
Crie e gerencie chaves de API do AI Gateway e associe um budget para limitar o uso.
Fallbacks e Retries
Tente novamente solicitações limitadas por taxa com backoff e roteie para modelos de fallback.