Confiabilidade, novas tentativas e tempos limite

Cada requisição é monitorada do início até o primeiro token. Se um caminho até o modelo travar ou falhar, a requisição passa para outro antes que qualquer coisa chegue até você.

Recuperação automática

• A maioria dos modelos está disponível por vários caminhos. Cada requisição começa pelo que está em melhores condições.
• Um caminho que retorna erro ou está inacessível é descartado para aquela requisição, que é tentada novamente em outro. Se o caminho está funcionando, aguardamos pelo tempo que uma requisição grande precisar; se ficar completamente sem resposta por 3 minutos (5 com esforço de raciocínio alto), ele é considerado falho.
• Caminhos que continuam falhando vão para o fim da fila para todos. Um caminho que fica sem resposta em um quinto ou mais das requisições fica atrás de outro que está respondendo sem problemas. Cada um volta a ser testado quando se recupera.
• Nada chega até você antes de um token real chegar, então tudo isso é invisível: você vê uma resposta um pouco mais lenta, não um erro.

A página de modelos mostra o status de cada modelo em tempo real (operacional, degradado ou indisponível), com base em requisições reais e nas nossas próprias verificações: cada modelo de chat é testado pelo menos a cada 10 minutos.

Tempos limite

Um stream não envia nada nos primeiros 20 segundos sem um primeiro token; depois, abre com comentários de keep-alive até a resposta começar. Uma requisição sem streaming não envia nada até terminar, então o streaming é mais indicado para clientes que desistem quando os cabeçalhos demoram (o fetch do Node espera 5 minutos por eles). Defina o tempo limite do seu cliente para pelo menos 10 minutos para raciocínios longos, respostas longas e imagemns. Os SDKs da OpenAI usam 10 minutos por padrão; alguns clientes HTTP usam 30 ou 60 segundos.

Limites de requisições

Sua conta não tem um limite global de requisições: as chaves só têm limites se você os definir. Um workspace pode executar 32 requisições ao mesmo tempo; uma requisição a mais recebe 429 concurrency_limit_exceeded com retry-after. Se um modelo estiver sobrecarregado, a requisição é tentada novamente pelos outros caminhos; se nenhum responder, você recebe 503 model_unavailable com retry-after. Aguarde um pouco e tente novamente, ou ative o roteamento inteligente.

Quando um modelo está indisponível

Em casos raros, todos os caminhos até um modelo falham. Sem roteamento inteligente, a requisição termina com 503 model_unavailable e retry-after. Quando os caminhos retornam erros, mas o modelo ainda responde a outras requisições, costuma ser uma falha passageira que se resolve em segundos, então primeiro continuamos tentando por até 2 minutos. Quando o modelo está indisponível para todos, o erro vem imediatamente; quando os caminhos ficam sem resposta, em até 10 minutos. Com o roteamento inteligente, uma alternativa semelhante responde no lugar.