A comparação é apresentada de forma errada em quase todos os lugares onde aparece, e o quarto resultado desta pesquisa revela isso: é a própria página de documentação do LiteLLM sobre o OpenRouter. O LiteLLM inclui uma integração com o OpenRouter porque os dois não são substitutos — são camadas diferentes. LiteLLM é um proxy que você implanta sobre contas de provedores que possui; OpenRouter é um serviço hospedado que mantém contas de provedores para você e revende o acesso aos modelos. Um proxy precisa de uma fonte; o OpenRouter é uma delas. Muitas equipes usam ambos deliberadamente.
Viés declarado: o Kunavo é nosso produto e pertence ao lado do OpenRouter nesta página — uma fonte hospedada de modelos, não um proxy. Ele não é uma alternativa ao que o LiteLLM faz, e a página não afirma que seja.
A diferença entre as camadas, em uma tabela
| LiteLLM | OpenRouter | |
|---|---|---|
| O que é | Software que você implanta | Um serviço hospedado |
| Quem mantém as credenciais dos provedores | Você | OpenRouter |
| É uma fonte de modelos? | Não — precisa de uma por trás dele | Sim |
| Quem o opera | Você: implanta, corrige, dimensiona e recebe alertas | Ninguém do seu lado |
| Custo de inferência | As tarifas dos seus próprios provedores | Tarifas dos provedores mais a taxa sobre compras de créditos |
| O texto do prompt pode permanecer na sua infraestrutura? | Sim | Não |
Leia a linha “é uma fonte de modelos?” de cima a baixo e o enquadramento desmorona. Todas as outras diferenças decorrem desse único ponto.
Usando-os juntos, que é o caso comum
LiteLLM na frente, OpenRouter atrás: seus aplicativos conversam com um único endpoint interno, o LiteLLM aplica orçamentos por chave e roteamento por equipe, e o OpenRouter fornece o catálogo sem que você abra uma conta em cada provedor. Qualquer endpoint compatível com OpenAI se encaixa da mesma forma, então adicionar uma segunda fonte para failover exige apenas algumas linhas:
# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
- model_name: claude-sonnet
litellm_params:
model: openrouter/anthropic/claude-sonnet-4.6
api_key: os.environ/OPENROUTER_API_KEY
# A second source behind the same proxy — any OpenAI-compatible
# endpoint works the same way.
- model_name: claude-sonnet-backup
litellm_params:
model: openai/claude-sonnet-5
api_base: https://api.kunavo.com/v1
api_key: os.environ/KUNAVO_API_KEYEsse é o arranjo que a pergunta “vs.” geralmente deveria fazer: não qual dos dois, mas se você precisa mesmo da camada de proxy sobre uma fonte hospedada.
Quando você realmente precisa de apenas um
- Apenas OpenRouter — você não tem contas de provedores, não quer ter nenhuma, e suas necessidades de roteamento são atendidas pelo que um gateway hospedado já faz. Adicionar LiteLLM nesse caso proporciona um serviço para operar e pouco mais. Alternativa nessa categoria: a seleção do OpenRouter.
- Apenas LiteLLM — você já possui contas de provedores, possivelmente com tarifas negociadas, e o que lhe falta é controle: um endpoint, orçamentos por chave, política de roteamento e texto do prompt que nunca deixa sua infraestrutura. Um revendedor não pode oferecer esse último item por nenhum preço.
- Nenhum dos dois — você quer roteamento e governança, mas não quer operar um serviço. Isso é um plano de controle BYO-key hospedado, uma terceira categoria da qual ambos ficam de fora: as quatro categorias de gateway de LLM.
As duas coisas a verificar antes de se comprometer com qualquer um dos dois
No lado do LiteLLM: a superfície operacional. Um proxy auto-hospedado é um pacote na sua compilação, colocando seu CI/CD e cluster em seu raio de impacto — nada hipotético neste projeto, como mostrou o incidente da cadeia de suprimentos de março de 2026. A resposta do LiteLLM foi substancial e o incidente está encerrado para qualquer pessoa na v1.83.0 ou posterior, mas o ponto estrutural vale para todo proxy auto-hospedado.
No lado do OpenRouter: o piso de preço. Um revendedor que repassa os preços de tabela com uma taxa sobre compras de créditos não é automaticamente mais barato que sua própria conta — nem automaticamente mais caro, se sua conta estiver no preço público de tabela. A comparação que vale a pena fazer é entre sua tarifa real e a tarifa real do gateway, por modelo, para os modelos que você usa. O Kunavo lista a maioria dos modelos abaixo das tarifas oficiais dos provedores; é a mesma comparação na outra direção: Kunavo vs. OpenRouter.
Compatibilidade de protocolo, para que a troca continue barata
Ambos falam o protocolo de rede da OpenAI, assim como toda alternativa hospedada a qualquer um deles (documentação do OpenRouter · do LiteLLM). Seja qual for sua escolha, o custo de estar errado é uma base_url e uma troca de chave, que é o fato mais útil desta página: essa decisão não merece as semanas que algumas equipes gastam nela. Veja os detalhes no guia da API compatível com OpenAI.
Perguntas frequentes
Qual é a diferença entre OpenRouter e LiteLLM?
Eles atuam em camadas diferentes. LiteLLM é um software que você implanta — um proxy que fica na frente dos provedores de modelos usando chaves de API que você possui; ele próprio não é uma fonte de modelos. OpenRouter é um serviço hospedado que mantém as credenciais dos provedores e revende o acesso aos modelos em uma única carteira, portanto é uma fonte de modelos, mas não algo que você executa. A consequência prática é que o LiteLLM precisa de pelo menos uma conta de provedor por trás dele, e o OpenRouter pode ser essa conta.
É possível usar LiteLLM e OpenRouter juntos?
Sim, e essa é uma configuração documentada, não uma solução improvisada — o LiteLLM inclui uma integração com o provedor OpenRouter. O formato comum é o LiteLLM atuar como o proxy com o qual seus aplicativos conversam, tendo o OpenRouter como uma das fontes por trás dele. Assim, você obtém os orçamentos por chave e o roteamento por equipe do LiteLLM sobre o catálogo do OpenRouter, sem manter contas em cada provedor.
O LiteLLM é mais barato que o OpenRouter?
O LiteLLM não acrescenta custo de inferência porque não revende nada — você paga o que suas próprias contas de provedor custam, além da infraestrutura em que o executa e do tempo de engenharia para operá-lo. O OpenRouter cobra as tarifas dos provedores mais uma taxa sobre as compras de créditos. Portanto, em preço unitário, o LiteLLM vence quando você já tem contas de provedores com boas tarifas; a comparação se inverte quando não tem: uma conta que você precisou criar pelo preço de tabela não é mais barata que a tarifa de um revendedor apenas porque nenhum gateway ficou com uma parte.
Devo escolher OpenRouter ou LiteLLM?
Pergunte do que você sente falta, em vez de qual é melhor. Se você tem contas de provedores e precisa de roteamento, orçamentos e governança sobre elas, esse é o trabalho do LiteLLM. Se você não tem contas de provedores e não quer gerenciar nenhuma, esse é o trabalho do OpenRouter. Se nenhum dos dois problemas estiver resolvido, talvez você queira ambos; e, se quiser o roteamento sem operar um serviço, nenhum dos dois é a resposta — o que você procura é um plano de controle BYO-key hospedado.
É seguro usar o LiteLLM após o ataque à cadeia de suprimentos de 2026?
O LiteLLM lançou a v1.83.0 por meio de um pipeline de CI/CD reconstruído após o incidente de 24 de março de 2026, com credenciais dos mantenedores rotacionadas, perícia da Mandiant e imagens Docker assinadas. Se você está na 1.83.0 ou posterior, o incidente está encerrado para você. Vale ler o relato completo e suas implicações estruturais — um proxy auto-hospedado é um pacote na sua compilação — antes de escolher o lado auto-hospedado desta comparação.
Onde o Kunavo se encaixa nessa comparação?
No lado do OpenRouter, não no do LiteLLM: o Kunavo é um gateway hospedado que mantém as credenciais dos provedores upstream, portanto é uma fonte alternativa de modelos, e não um proxy que você implanta. Uma implantação do LiteLLM pode apontar para o Kunavo da mesma forma que aponta para o OpenRouter, por meio do provedor compatível com OpenAI do LiteLLM, com a URL base configurada. Ele não substitui o que o LiteLLM faz.