LiteLLM vs OpenRouter: custos, controle e qual escolher

Na comparação LiteLLM vs OpenRouter, escolha o LiteLLM se você precisa operar o gateway e manter as credenciais dos provedores na sua infraestrutura. Escolha o OpenRouter se prefere roteamento hospedado e cobrança unificada dos modelos: as compras de créditos do plano Standard têm uma taxa de 5.5%, enquanto a licença do software de código aberto do LiteLLM custa $0. A decisão depende de quem opera o gateway, de qual conta paga pela inferência e de quanto as taxas evitadas compensam o custo de operação.

LiteLLM vs OpenRouter: qual faz mais sentido para o seu produto?

O OpenRouter leva vantagem para quem quer acessar vários provedores sem operar mais um serviço. O LiteLLM leva vantagem quando o gateway, as credenciais e as políticas de tráfego precisam ficar em uma infraestrutura sob seu controle. Um volume alto de uso, por si só, não resolve a escolha: usar suas próprias chaves no OpenRouter tem uma estrutura de custos diferente da compra de créditos de inferência.

Um gateway fica entre o seu produto e os provedores de modelos. Este comparativo analisa o Proxy Server do LiteLLM em infraestrutura própria, e não apenas seu SDK Python, e o serviço hospedado do OpenRouter, tanto com créditos quanto com chaves próprias, modalidade conhecida como bring your own key (BYOK).

Preços e documentação verificados em 12 de outubro de 2026, incluindo a página de preços do LiteLLM e a página de preços do OpenRouter. A conta apresentada abaixo usa as taxas publicadas nessas páginas. Não houve teste com conta autenticada nem benchmark de latência.

Os recursos da tabela seguem a arquitetura do LiteLLM, o schema de chaves do OpenRouter e a documentação específica de roteamento, logs e cache citada adiante. Integrações com provedores e modelos disponíveis para compra são contagens diferentes; nenhum desses números garante que a combinação exata de modelo, região e recursos de que você precisa esteja disponível.

Para um produto pequeno sem uma pessoa responsável pela plataforma, comece pelo OpenRouter, a menos que o caminho hospedado da requisição viole um requisito concreto. Para um produto que já opera infraestrutura compartilhada e exige limites de requisições por chave aplicados de forma centralizada, escolha o LiteLLM. Se o produto está crescendo e já tem contratos negociados com provedores, compare OpenRouter BYOK com LiteLLM, em vez de aplicar a taxa de compra de créditos às duas opções.

Quem guarda as chaves, faz a cobrança e encaminha a requisição?

Com o LiteLLM, você controla onde o gateway opera; com o OpenRouter, você usa um intermediário gerenciado. BYOK muda a credencial usada no provedor e quem paga a conta, mas mantém esse intermediário no caminho.

LiteLLM: seu gateway, suas contas nos provedores

O LiteLLM é um gateway de código aberto que você instala entre a aplicação e seus provedores de modelos. No fluxo documentado, ele valida uma chave virtual, aplica orçamentos e limites de requisições, escolhe a rota e converte a chamada para o formato de API do provedor. A chave virtual é uma credencial de aplicação emitida pelo gateway; assim, a aplicação dispensa o acesso às credenciais secretas de cada provedor. Arquitetura de requisições do LiteLLM.

As contas configuradas nos provedores pagam pela inferência. O gateway precisa de um orçamento operacional próprio: computação, banco de dados para chaves e gastos, além de qualquer estrutura de cache ou de limitação compartilhada de requisições que você implantar. A documentação de implantação em produção descreve esses componentes, mas não apresenta um custo de hospedagem que sirva para todos os cenários.

Vencedor em controle de credenciais e implantação: LiteLLM. Evite essa opção se ninguém vai assumir as atualizações, a disponibilidade do banco de dados e as requisições com falha. Software gratuito não substitui esse responsável.

OpenRouter: roteamento hospedado, com escolha de quem paga

O OpenRouter reúne um gateway hospedado e um catálogo de modelos. Com créditos comprados, a aplicação usa uma chave do OpenRouter e o consumo é descontado desse saldo. No BYOK, você fornece as credenciais dos provedores; o OpenRouter afirma que elas são criptografadas e usadas nas requisições ao provedor indicado. A conta no provedor arca com a inferência, e as taxas de roteamento aplicáveis são descontadas dos créditos do OpenRouter. Documentação de BYOK do OpenRouter.

Um comportamento padrão merece atenção: o fallback para capacidade compartilhada. Quando uma chave BYOK priorizada não consegue atender à requisição, o OpenRouter pode usar sua própria capacidade e consumir seus créditos do OpenRouter. A configuração mais restritiva no nível do provedor é Nunca usar capacidade compartilhada para nenhum modelo deste provedor. Outros provedores ainda podem atender à requisição se você não restringir também quais são permitidos. Essa configuração define quem paga, além de afetar a disponibilidade.

Vencedor em acesso imediato ao catálogo, compras unificadas e operação do gateway: OpenRouter. Use BYOK se manter suas contas nos provedores for importante, mas decida explicitamente se um fallback pode transferir a cobrança para o OpenRouter.

Preços do OpenRouter: compra de créditos e BYOK

O OpenRouter cobra pela compra de créditos e, acima de uma franquia, pelo roteamento BYOK. São cobranças distintas. O FAQ informa uma taxa de 5.5%, com mínimo de $0.80 por compra de créditos, e uma taxa de 5% para pagamentos em criptomoedas. Os preços de inferência dos provedores são repassados sem acréscimo. FAQ de taxas do OpenRouter.

A tabela de planos informa 5.5% para o Standard e 8% para o Business. Ambos incluem $25,000 de inferência por mês, a preço de tabela, sem taxa BYOK; acima disso, a taxa é de 5%. As condições do Enterprise são negociadas. O exemplo de cobrança usa o Standard; não aplique seu percentual ao Business. Tabela de planos vigente.

A base de cálculo da taxa BYOK é o que o mesmo modelo e provedor normalmente custariam no OpenRouter. Ela não corresponde necessariamente à sua fatura com desconto no provedor. A franquia é medida pelo valor da inferência, e não pela quantidade de requisições; a taxa é descontada dos créditos do OpenRouter. Definição da taxa BYOK.

Para entender melhor as cobranças de compra de créditos e de uso, veja nosso guia de preços do OpenRouter.

LiteLLM Open Source e Enterprise

O LiteLLM Open Source não cobra licença, inclusive em produção. A página de preços inclui chaves virtuais, acompanhamento de gastos, orçamentos, limites de requisições, fallbacks, logs de requisições e respostas e métricas do Prometheus. Esses recursos não são todos exclusivos do Enterprise. Planos do LiteLLM.

O Enterprise acrescenta controles de identidade e organização, como SSO/SCIM, autenticação OIDC/JWT, logs de auditoria, gerenciadores de segredos e rotação de chaves, além de suporte e opções de implantação. O preço é anual e depende da capacidade de requisições do gateway, da arquitetura e das necessidades de suporte, em vez do gasto com tokens. Não há um valor público em dólares para incluir em uma comparação mensal justa; use a sua cotação.

Quanto fica a conta mensal com uso baixo e em crescimento?

Em um cenário ilustrativo de $50,000 mensais de inferência a preço de tabela, os créditos Standard custam $52,750; o uso exclusivo de Standard BYOK custa $51,318.75 nas condições de compra de créditos descritas abaixo. O LiteLLM Open Source custa $50,000 mais a sua operação. São cálculos, e não pacotes cotados ou cargas de trabalho medidas.

Considere os mesmos modelos, provedores e proporção de tokens, normalizados para um valor mensal de inferência B. O cenário de uso baixo adota $100; o de crescimento, $50,000, o dobro da franquia BYOK publicada. As premissas são: faturas dos provedores iguais aos preços de tabela, nenhuma economia com cache ou descontos negociados, nenhum fallback para capacidade compartilhada e uma única recarga Standard sem criptomoedas, com consumo integral dos créditos. Impostos e extras opcionais ficam fora da comparação.

Considere H como o seu custo mensal real de hospedagem e manutenção do LiteLLM. Não o substitua por uma estimativa inventada de servidor.

O cálculo usa a taxa de compra de créditos e a franquia BYOK vigente. Ele pressupõe que um mês de uso exclusivo de BYOK dispensa a compra de créditos quando não há taxa de roteamento a pagar.

No cenário de crescimento pago com créditos, você compra $50,000 em créditos e acrescenta $50,000 × 5.5% = $2,750. Desembolso total: $52,750.

Para o mesmo uso via BYOK, a fatura do provedor é de $50,000. A taxa de roteamento incide sobre a inferência que ultrapassa a franquia: ($50,000 − $25,000) × 5% = $1,250. Comprar créditos Standard para pagar essa taxa acrescenta $1,250 × 5.5% = $68.75. Total: $50,000 + $1,250 + $68.75 = $51,318.75. A taxa de compra de créditos decorre do pagamento das taxas BYOK com créditos comprados; ela não é uma segunda taxa sobre a fatura do provedor.

O ponto de equilíbrio depende de como você usaria o OpenRouter

Em relação aos créditos Standard, o LiteLLM gera economia quando H é menor que a taxa de compra de créditos evitada. Acima da faixa em que vale a taxa mínima, o ponto de equilíbrio é B = H ÷ 0.055. No cenário de uso baixo, sobram apenas $5.50 para cobrir H; no de crescimento, $2,750.

Em relação ao uso exclusivo de Standard BYOK, não há economia de taxa de roteamento abaixo da franquia. Acima dela, quando a taxa percentual da recarga supera a mínima, o ponto de equilíbrio é B = $25,000 + H ÷ 0.05275. No cenário de crescimento, a operação do LiteLLM precisa custar menos de $1,318.75 por mês para compensar apenas por esses custos. Uma licença Enterprise muda H para H mais a parcela mensal da sua cotação real.

Descontos diferentes nos provedores, preços dos modelos, valores das compras de créditos ou uso de fallback mudam a conta. A quantidade de requisições, sozinha, não permite encontrar esse ponto de equilíbrio, porque cada requisição tem um custo em tokens diferente.

Fallbacks, orçamentos e cache: qual gateway de IA leva vantagem?

O LiteLLM leva vantagem nos controles que você opera dentro do gateway; o OpenRouter, no roteamento que você usa sem precisar manter esse gateway. O que decide a escolha é a configuração e o alcance dos recursos, além da simples presença de “fallbacks” na lista.

Roteamento e fallbacks: OpenRouter para uma operação gerenciada

O roteador de provedores do OpenRouter permite definir a ordem dos provedores, uma lista de permitidos e o controle allow_fallbacks. Separadamente, o array models tenta modelos alternativos quando o principal não consegue atender à requisição. A distinção importa: trocar o provedor de um mesmo modelo e trocar o próprio modelo são decisões de produto diferentes. Roteamento de provedores, fallbacks de modelos.

O LiteLLM documenta novas tentativas dentro de um grupo de modelos configurado e fallbacks para outro grupo. Essas implantações e regras ficam sob sua responsabilidade. Arquitetura de roteamento do LiteLLM.

Vencedor: OpenRouter para quem busca failover gerenciado. Escolha o LiteLLM quando os destinos de fallback aprovados são implantações que você já administra. Nem uma lista de fallback nem este comparativo demonstram vantagem de latência.

Orçamentos e limites por chave: LiteLLM para governar o tráfego

O LiteLLM oferece controles de orçamento e limites de requisições por minuto (RPM) e tokens por minuto (TPM) para chaves virtuais. Um teto de gastos controla o custo acumulado; um limite de requisições controla a velocidade com que uma aplicação consome capacidade. Um cliente pode ficar dentro do orçamento mensal e, ainda assim, gerar um pico indesejado. Controles de orçamento e limites do LiteLLM.

A limitação é a dependência de um banco de dados. A documentação do LiteLLM é explícita: os orçamentos não limitam o uso em uma implantação sem banco de dados. A verificação do orçamento global deixa as requisições passar, e os orçamentos de chave, usuário e equipe ficam indisponíveis. Definir um valor de orçamento no arquivo de configuração não basta se o serviço do qual ele depende estiver ausente.

O OpenRouter documenta limites em dólares por chave, períodos de renovação e a configuração include_byok_in_limit. Seu schema de criação de chaves não lista campos de RPM/TPM por chave configuráveis pelo usuário, enquanto a página de limites descreve controles de capacidade da plataforma e dos provedores. Um limite de gastos por chave não equivale a um limite de vazão específico para a aplicação. Controles de chaves, limites de requisições e orçamento.

Vencedor: LiteLLM quando regras de gasto e vazão por chave são requisitos. O OpenRouter oferece controles de gasto, mas é preciso verificar se o escopo documentado abrange a conta que paga.

Logs e cache: LiteLLM para controlar o armazenamento

O LiteLLM permite escolher destinos de logs e ocultar o conteúdo das mensagens preservando os metadados de gasto. Seu cache de respostas aceita armazenamento local, Redis e outros backends documentados; o cache por correspondência exata reutiliza uma resposta quando a requisição é idêntica. Controles de logs, backends de cache.

O OpenRouter oferece logs privados de entradas e saídas mediante adesão explícita. Também documenta o cache de respostas no gateway, que pode devolver uma resposta salva para uma requisição idêntica sem chamar o provedor, separadamente do cache de prompts no provedor, que reaproveita o processamento do prompt dentro do provedor. O cache de respostas fica desligado até ser ativado e tem escopo por chave de API. Logs privados, cache de respostas, cache de prompts.

Vencedor: LiteLLM para escolher onde ficam os logs e caches do gateway. O OpenRouter é a opção hospedada mais simples. Antes de adotá-lo, avalie esta limitação específica: a retenção zero de dados no nível da conta desativa o cache de respostas, enquanto provider.zdr por requisição não altera a elegibilidade para cache. Exigir que o provedor não retenha dados não desativa, por si só, a retenção no cache de respostas do gateway.

Tratamento de dados: controlar o gateway garante que nada saia da sua infraestrutura?

O LiteLLM retira um fornecedor de gateway hospedado do caminho, mas não transforma inferência remota em local. Sua página de segurança afirma: “Nenhum dado ou telemetria é armazenado nos servidores do LiteLLM quando você usa hospedagem própria.” A arquitetura continua encaminhando requisições aos provedores de modelos que você escolheu. Segurança do LiteLLM, caminho da requisição.

Isso dá a você controle sobre o proxy, seus logs e os destinos configurados. As políticas do provedor do modelo e de qualquer serviço externo de logs que você ativar continuam valendo.

O OpenRouter declara: “Qualquer retenção de prompts no OpenRouter sempre depende de adesão explícita.” Ele separa os logs privados de depuração da permissão para usar entradas e saídas na melhoria do produto; as duas opções vêm desligadas por padrão. O serviço armazena metadados das requisições e descreve a amostragem de uma pequena quantidade de prompts para categorização com um modelo cuja política é de retenção zero de dados. Sem a adesão ao uso de entradas e saídas, afirma que as categorias são armazenadas anonimamente, sem vínculo com sua conta ou ID de usuário. Coleta de dados do OpenRouter.

O provedor do modelo é outra parte a avaliar. O OpenRouter documenta políticas separadas de retenção e treinamento e permite filtrar endpoints por retenção zero de dados, ou ZDR. Não treinar com os dados e não reter os dados são compromissos diferentes. A documentação de ZDR também alerta que plugins e ferramentas ativados podem ter suas próprias políticas de retenção. Políticas dos provedores, controles de ZDR.

Vencedor em controle do tratamento de dados no gateway: LiteLLM. O OpenRouter pode se encaixar em uma política que permita serviços hospedados, mas avalie separadamente o gateway, o provedor, o cache e qualquer ferramenta ativada. “BYOK”, por si só, não responde a nenhuma dessas questões de retenção.

Como migrar do OpenRouter para o LiteLLM — ou fazer o caminho inverso

O custo da migração está em reconstruir as políticas e a apuração de gastos em torno da API, além de trocar seu endereço. Um formato de requisição compatível não transfere contratos com provedores, orçamentos, histórico de logs ou regras de fallback.

1. 1

   Mapeie quem paga e qual credencial é usada em cada rota

   Ao migrar para o LiteLLM, identifique as credenciais e contas dos provedores que vão substituir o acesso pago com créditos. Ao migrar para o OpenRouter, escolha entre créditos comprados e BYOK e defina se as requisições de fallback podem recorrer à capacidade compartilhada e consumir créditos do OpenRouter.

2. 2

   Mapeie os modelos e seu comportamento

   Registre os identificadores ou aliases dos modelos usados pelo produto, os provedores permitidos, os parâmetros de requisição aceitos e os destinos de fallback. Preserve o comportamento que a aplicação espera do modelo, em vez de tratar todos os itens do catálogo como intercambiáveis.

3. 3

   Recrie orçamentos, limites e retenção com critérios explícitos

   Transfira a política de gastos de cada chave, seu período de renovação e o controle de vazão necessário. No LiteLLM, inclua o banco de dados do qual os orçamentos dependem. No OpenRouter, decida quais orçamentos incluem BYOK. Documente a retenção de logs e cache separadamente da retenção do provedor.

4. 4

   Defina um marco para a apuração de gastos e o retorno à configuração anterior

   Guarde os registros de uso anteriores conforme sua política, registre o momento da virada e mantenha a configuração de roteamento anterior disponível. Defina quem vai conciliar as faturas dos provedores e os créditos do gateway depois da mudança.

Não migre um produto pequeno que funciona bem no OpenRouter para o LiteLLM só para evitar uma taxa menor que o custo de operar mais um serviço. Não leve uma implantação funcional do LiteLLM para um roteador hospedado se manter o gateway sob seu controle for um requisito inegociável. E não migre apenas porque um catálogo é maior sem verificar os modelos e recursos específicos de que seu produto precisa.

É possível usar os dois: o LiteLLM documenta o OpenRouter como provedor de destino. Isso permite manter um ponto de controle local e usar o catálogo do OpenRouter, mas preserva também o caminho de requisições do OpenRouter e suas taxas aplicáveis. Não transforma inferência hospedada em um sistema inteiramente local.

Alternativas ao OpenRouter: Vercel e Cloudflare

O Vercel AI Gateway é a primeira opção hospedada a comparar em taxas; o Cloudflare AI Gateway faz sentido quando seus controles se encaixam na infraestrutura que você já usa. Em ambos os casos, continua sendo necessário entender qual credencial determina a cobrança.

O Vercel AI Gateway informa que não cobra acréscimo sobre tokens, taxa de plataforma nem taxa de gateway para BYOK. O BYOK exige créditos comprados; requisições BYOK com falha podem ser repetidas com credenciais do sistema e cobradas do saldo do gateway. A faixa gratuita inclui $5 mensais para modelos elegíveis, mas a compra de créditos encerra essa franquia mensal gratuita. Taxas de processamento de pagamento e adicionais opcionais ainda podem ser cobrados. Preços publicados pela Vercel.

O Cloudflare AI Gateway oferece gratuitamente os recursos básicos de análise, cache e limitação de requisições. O Unified Billing acrescenta 5% às compras de créditos: o exemplo publicado é de $100 em créditos por uma cobrança de $105, com repasse dos preços de inferência dos provedores. Novos clientes cujo primeiro gateway foi criado em 24 de setembro de 2026 ou depois seguem os preços do Workers Logs; portanto, recursos gratuitos do gateway não significam logs gratuitos sem limite. Preços publicados pela Cloudflare.

Para essas novas contas de logs, o Workers Paid inclui 20 milhões de logs por mês e cobra $0.60 por milhão adicional; o plano Free lista 200,000 logs por dia. Preços do Workers Logs. Nosso artigo sobre controle de cobrança na Cloudflare explica as regras de credenciais, e o comparativo de alternativas ao OpenRouter amplia a lista de opções.

Dúvidas comuns antes de escolher

OpenRouter vs LiteLLM: quem guarda minhas chaves dos provedores?

Com o LiteLLM em infraestrutura própria, você controla as credenciais dos provedores usadas pelo gateway. No OpenRouter BYOK, você fornece essas chaves ao serviço hospedado, que afirma criptografá-las. O uso do OpenRouter pago com créditos dispensa o fornecimento da chave de cada provedor.

Posso manter meus contratos com os provedores ao usar o OpenRouter?

O BYOK permite que as requisições usem suas contas nos provedores. A fatura do provedor, a taxa BYOK do OpenRouter calculada a preço de tabela e um eventual fallback para capacidade compartilhada são pontos distintos da cobrança. A franquia sem taxa não torna gratuita a inferência do provedor.

O LiteLLM fica mais barato conforme o uso aumenta?

Somente quando seu custo de operação, somado a uma eventual licença Enterprise, é menor que as taxas do OpenRouter que você evitaria. Compare com a taxa BYOK quando essa for a alternativa; aplicar o percentual de compra de créditos à fatura inteira do provedor em BYOK superestima a economia.

Posso usar o LiteLLM junto com o OpenRouter?

Sim. O LiteLLM documenta uma integração com o OpenRouter como provedor. As duas camadas de roteamento permanecem, assim como os custos operacionais correspondentes, as taxas do OpenRouter e o caminho hospedado dos dados.

Receba o AI Business Workflow Audit Checklist pela newsletter para mapear suas chaves de provedores, os gastos com modelos e quem responde pelo fallback antes de trocar de gateway.