ForgeRouter — Documentação

Roteamento e fallback

Como o ForgeRouter decide qual provedor atende cada requisição.

Toda requisição para /v1/chat/completions passa por um pipeline de seleção antes de chegar a um provedor real:

  1. Carregamento do registro — a lista de provedores ativos (do YAML ou do Postgres) é carregada, junto com o resultado do último health check de cada um.
  2. Filtragem por capacidade — provedores que não suportam o modelo pedido, ou que estão marcados como indisponíveis pelo health check, são descartados.
  3. Ordenação por prioridade — entre os provedores restantes, o de menor priority é escolhido primeiro.
  4. Tentativa com retry — se a chamada falhar (timeout, erro 5xx, limite de taxa), o ForgeRouter tenta automaticamente o próximo provedor da lista, até esgotar as opções configuradas.

Health checks

Cada provedor é verificado periodicamente com uma chamada leve. Um provedor que falha repetidamente é marcado como indisponível e volta a ser considerado só depois de responder normalmente de novo — isso evita que uma instabilidade pontual derrube o roteamento inteiro.

Protocolos suportados

Além do formato nativo OpenAI (/v1/chat/completions), o ForgeRouter expõe dois tradutores de protocolo que reaproveitam o mesmo pipeline de roteamento e fallback acima:

  • /v1/messages — compatível com a Anthropic Messages API.
  • /v1/responses — compatível com a OpenAI Responses API.

Um cliente que fala qualquer um dos três protocolos se beneficia do mesmo roteamento — a tradução acontece na borda, antes da seleção de provedor.

Precisa garantir que o roteamento continue saudável em produção, com alertas e ajuste fino de prioridade? A Darckware cuida da manutenção pra você.