5
gmasson
2 min de leitura ·

LocalRouter: Roteador Local Opensource Para APIs de IA

Quantas vezes você estava no meio daquele teste perfeito de uma nova feature de IA e tomou um erro 429 de "Rate limit reached"?

Semana passada eu perdi a paciência tendo que trocar o provedor de API manualmente só para a aplicação voltar a responder.

Foi caçando uma saída que desenvolvi o LocalRouter.

Ele é um gateway feito em PHP puro, que cria um endpoint único para suas LLMs e faz rotação automática entre provedores quando um falha.

Feito para aproveitar ao máximo as cotas diárias gratuitas da NVIDIA, Groq, OpenRouter e Cerebras.

Como a mágica acontece

O setup não tem frescuras. Não precisa de Composer, containers Docker pesados ou builds demorados — só o PHP 8.0+ que a maioria de nós já tem na máquina.

Você baixa o projeto e sobe o servidor embutido: php -S localhost:8000 (ou roda no XAMPP/WAMP)

No arquivo config.php, você cadastra seus provedores, modelos e junta as chaves de cada um para um mesmo modelo lógico.

Aponte seu app (usando qualquer SDK padrão OpenAI), agente de IA ou IDE para http://localhost:8000/chat/completions.

Se o seu app fizer a requisição abaixo e o provedor principal cair ou negar por falta de créditos, o roteador pula para o próximo da fila na mesma hora, e o app nem percebe a troca:

`
curl http://localhost:8000/chat/completions \
  -H "Authorization: Bearer SUA_CHAVE_DO_GATEWAY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss-120b",
    "messages": [{"role": "user", "content": "Qual o sentido da vida?"}]
  }'
`

Por que vale o espaço na sua máquina?

Você envia requisições no formato padrão OpenAI e o gateway traduz por baixo dos panos para a API. Comparado a subir gateways corporativos complexos, o LocalRouter resolve a dor do dev de forma muito limpa.

Além disso, se a conexão cair no meio de um streaming de texto, ele pega o que já foi gerado, injeta como contexto no próximo provedor e pede para continuar exatamente de onde parou.

*Um ponto de atenção: O único detalhe é que, focado em manter a simplicidade extrema, ele não guarda estado por padrão (um provedor esgotado será tentado novamente na próxima requisição, a menos que você ative a flag de COOLDOWN_SECONDS para deixá-lo "de castigo"). *

Quem quiser testar, o projeto tem licença MIT e está lá no meu GitHub: gmasson/localrouter.

Carregando publicação patrocinada...
4

Meus 2 cents,

Parabens pela iniciativa !

Tenho usado o OmniRoute para este tipo de atividade, que eh bem completo.

Disto isto, gostei do teu projeto: eh bem simples de implementar e manter (noves fora gosto muito do PHP), o que eh um ponto bem positivo.

Vou baixar e testar, mas um ponto que devo modificar (e indico como sugestao) eh: ele analisar a primeira linha do prompt para ver se eh um "comando" para o router.

Explicando: p.ex. no prompt mando na primeira linha "!CMD;modelo X" para indicar que para aquele prompt especifico ele deve usar o "modelo X", "!CMD;status" para ele so retornar o status/quotas do modelos atuais, "!CMD;info" para ele trazer quais os modelos cadastrados/disponiveis, "!CMD;default modelo X" para mudar o modelo como default, "!CMD;think" para ativar (ou desabilitar) CoT naquele prompt, "!CMD;raw" para retornar o RAW JSON da reposta original e assim por diante.

Desta forma nao preciso checar na linha de comando estes pontos e faco direto na propria interface que esteja trabalhando. Tem mais alguns detalhes, mas acho que voce pegou a ideia - tenho feito isso aqui e as vezes facilita meu trabalho.

Repositorio devidamente starreado e forkeado - obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

2

Opa, obrigado pelo feedback!

Então, a ideia é usar ele como uma API, você não precisa instalar nada, ele tem alguns comandos CLI mas nada fugindo da ideia de que, você use como API local para custom provider no VSCode, Cursor ou Claude Code ou em algum agente de IA.

Você insere o endereço, a sua chave de API, seleciona o modelo e faz chamada REST.

Também pode ser usada para chatbot, OpenClaw, Hermes Agent e etc.

Por exemplo, uso bastante o GLM 5.2 e o DeepSeek v4 Pro, ai uso 5 contas diferentes do NVIDIA Build e 2 do Hugginface, e o LocalRouter fica rotacionando essas api conforme programo no VSCode (coloquei como custom provider no Github Copilot), não gasto mais nada com IA.

Tenho uma assinatura ativa do OpenCode só de reserva, mas desde que criei o LocalRouter, só usei os Free Tier.

Minha ideia para a proxima versão é incluir RAG proprio e System Prompt, para as respostas sairem mais "mastigadas" pra quem faz chatbot, automações ou quer uma API pronta para algum SaaS e quer rotacionar com APIs Free e algumas pagas de Backup

3

Meus 2 cents extendidos,

Sim, usar com API eh a ideia: mas o pulo do gato que dei na sugestao eh exatamente este.

Veja, a API pode ser usada por um chatbot local, um agente ou um app - ate ai, nada de novo, eh a forma comum de usar.

So que para voce modificar o comportamento do AI Gateway/Localrouter, voce precisa modificar sua configuracao ANTES de chamar a API - o que tenho feito eh um pouco diferente, modifico DURANTE a chamada da api.

Se tenho diversos providers/modelos configurados no AI Gateway/Localrouter, um vai ser o default, certo ? Entao na chamada de API vai usar o default - mas digamos que SOMENTE PARA AQUELE PROMPT eu ja saiba antecipadamente que ele nao deve usar o default, mas um prompt mais barato (ou mesmo local).

Este eh o detalhe: sem precisar modificar o app que esta usando a API do AI Gateway/LocalRouter, coloco assim no prompt (exemplo):

!CMD;model barato
Qual a capital do Brasil ?

Desta forma consigo selecionar que para este prompt em especial, a API ao inves de usar o modelo default, vai usar modelo "barato".

O AI Gateway/Localrouter faz um parse do prompt, identifica que tem um "comando" na primeira linha e realiza alguma acao pre-programada, retira a linha de comando do prompt e envia o prompt normalmente para o modelo designado.

Veja, eh so um exemplo: no dia-a-dia existem diversas situacoes em que eh necessario mudar certos aspectos do harness que a API vai executar - de um modo geral fazemos isso direto no app (p.ex. langchain escolhendo modelo), mas o que tenho feito eh permitir fazer isso direto no prompt, o que permite uma flexibilidade um tanto maior.

Nao eh apenas uma questao de mudar o modelo, mas diversos tipos de parametros que podem ser alterados diretamente no AI Gateway/LocalRoute para cada chamada de API, sendo que o parametro de ativacao daquele comportamento vai direto no prompt.

Enfim, como disse, eh so uma sugestao de algo que ja estou fazendo aqui e tem diversas utilidades e ja que voce esta escrevendo seu proprio AI Gateway/Localrouter achei interessante compartilhar.

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Achei legal a proposta de manter o roteador pequeno e local. Para uso individual isso parece bem mais fácil de adotar do que subir uma stack completa de gateway.

Uma dúvida que eu teria ao usar em projetos reais é como classificar a falha antes de trocar de provedor. 429 e 5xx parecem bons candidatos para fallback, mas erro de auth, erro de contexto grande demais ou resposta bloqueada por política talvez não deveriam cair automaticamente no próximo modelo.

Você pretende tratar esses tipos de erro de forma diferente? Acho que essa distinção pode evitar um caso chato: o app “funciona”, mas muda de provedor em situações em que o comportamento esperado não era exatamente equivalente.