OpenRouter não é mágica. É um cálculo.

Quase todo conteúdo sobre OpenRouter em pt-BR é "veja como é fácil". Esse é o lado do cálculo: quando faz sentido usar gateway, quando não faz, e a tabela de números que ninguém mostra.

O que é OpenRouter em duas frases

OpenRouter é um gateway que te dá acesso unificado a ~100 LLMs (Anthropic, OpenAI, Google, Mistral, Meta, modelos open-source) por uma única chave de API e uma única conta. Você paga só pelo que usa, sem assinatura mensal, e a cada request escolhe qual modelo quer rodar.

É isso. Não tem mais nada. O resto desse post é sobre quando isso vale a pena e quando não vale.

Por que eu uso (quando uso)

Eu uso OpenRouter por três motivos práticos, nenhum deles "porque é fácil":

Motivo 1 — Eu preciso testar 5 modelos sem abrir 5 contas. Quando uma feature nova exige decisão de modelo, eu não quero criar conta na OpenAI, validar cartão, esperar approval da Anthropic, configurar billing no Google Cloud, e depois descobrir que o Mistral resolve o problema melhor. OpenRouter colapsa esse atrito em zero. Isso é gateway de descoberta — não de produção.

Motivo 2 — Tarefas barato-quando-dá e caro-quando-precisa. Solo founder não tem orçamento pra mandar tudo no modelo mais caro. Eu tenho rotinas onde Haiku (R$0,25 por milhão de tokens de input) resolve em 80% dos casos, e os 20% restantes eu faço fallback pra Sonnet. Implementar isso sem gateway exige 2 SDKs, 2 sets de auth, lógica de fallback custom. Com OpenRouter é uma string no header.

Motivo 3 — Failover automático. Se a Anthropic cair (e cai, raramente, mas cai), o OpenRouter redireciona pro próximo provider que serve o mesmo modelo. Você não precisa codar isso. Pra workload de produção, isso é tranquilidade barata.

Quando eu NÃO uso (e por que isso importa)

A parte que ninguém escreve.

Eu não uso OpenRouter pro Claude Code do dia-a-dia. O Claude Code já tem Claude Sonnet/Opus direto via Anthropic Max — eu pago U$200 por mês fixo e tenho throughput dedicado. Mandar essas requests pelo OpenRouter seria pagar duas vezes: a assinatura mensal mais o custo per-token via gateway. Isso é jogar dinheiro fora com cara de sofisticação.

A regra que eu segui é simples:

Se você usa um modelo específico todo dia, vá direto na fonte. OpenRouter brilha pro buffet, não pro restaurante fixo.

Outras situações onde eu não uso OpenRouter:

• Requests sensíveis a latência extrema. O gateway adiciona ~50-200ms por request. Pra streaming de UI, é imperceptível. Pra loops automatizados de milhares de requests, soma.
• Quando preciso de feature exclusiva do provider. Function calling avançado da OpenAI, prompt caching da Anthropic, grounded generation do Google — algumas dessas funcionam parcialmente via OpenRouter, outras não. Quando eu preciso da feature inteira, vou direto.
• Quando o cliente exige BAA ou data residency específica. Compliance é coisa de relação direta com provider, não de gateway.

O cálculo real (com números, não promessas)

Vamos parar de falar em abstrato. Aqui é a tabela que eu queria ter encontrado em algum lugar quando comecei.

Cenário: processar 1 milhão de tokens de input + 500 mil tokens de output em Claude Sonnet 4 (modelo que eu uso de verdade pra trabalho sério).

Os números importam menos do que o shape do cálculo. Repare que GPT-5 e Gemini 2.5 Pro entram quase 40% abaixo do Sonnet pelo mesmo trabalho — ambos rodam em OpenRouter, e ambos competem em qualidade de raciocínio. Quando alguém te diz "OpenRouter é caro", o que essa pessoa está dizendo é "comparei só Sonnet via OpenRouter com Sonnet direto e ignorei que tem mais opções na mesa".

O reasoning tax escondido

A tabela acima é honesta sobre preço de tabela mas mente sobre custo real quando o modelo tem reasoning forçado. Eu descobri isso testando os 8 modelos em laboratório no mesmo prompt agentic — o tipo de prompt que um solo founder usa de verdade no dia a dia.

O experimento: mesmo prompt (planejamento de refactor de auth), max_tokens=4096, single call por modelo. Custo real medido pela própria API:

O que aconteceu: GPT-5 e Gemini 2.5 Pro têm reasoning mandatório que consome 76-88% dos tokens em processamento interno. Você paga por tokens que nunca vê na tela. A tese de marketing "GPT-5 é 75% mais barato que Opus" — baseada no preço de tabela $1,25/$10 vs $5/$25 — desmorona quando o modelo precisa gerar reasoning de 2300 tokens pra produzir 300 tokens visíveis.

A lição honesta: preço de tabela não é custo real quando há reasoning tax. Se você está fazendo o cálculo sério, divide o custo total pela quantidade de tokens úteis (visíveis pro usuário), não pela contagem bruta. Aí o quadro inverte: Haiku 4.5 e Sonnet 4.6, sem reasoning forçado, viram os campeões honestos. GPT-5 Codex (variante que evita reasoning) também. GPT-5 padrão e Gemini 2.5 Pro só compensam pra workloads onde o thinking realmente importa — análise multi-step longa, problemas matemáticos, casos onde você quer ver o raciocínio.

Pra agente típico (chat estruturado, output ≤500 tokens, tool use), os reasoning models são armadilha econômica. Pra trabalho de profundidade, são essenciais. Saber qual situação você está vivendo é a única coisa que importa.

A pergunta certa é:

1. Você usa o modelo pesado todo dia, e é especificamente Sonnet ou Opus? Vai de Max (assinatura) ou direto na Anthropic (pay-per-use), nunca pelo gateway.
2. Você precisa testar 5 modelos por semana? OpenRouter é o caminho — o overhead de configurar 5 contas separadas é maior que o markup do gateway.
3. Você quer qualidade Anthropic-class mas não está casado com a Anthropic? OpenRouter é o caminho — GPT-5 e Gemini 2.5 Pro saem mais baratos pelo gateway que Sonnet sai direto.
4. Você tem volume baixo mas variável? OpenRouter de novo. Você não quer 5 assinaturas pra usar 200 mil tokens por mês.
5. Você tem volume alto e previsível, em modelo único de provider único? Direto na fonte. Sempre.

A regra geral que eu adoto

Gateway é arquitetura de opção,
não de economia automática.

Se você vai pro OpenRouter esperando ser mais barato que ir direto, você vai se decepcionar — porque na maioria dos casos, não é. O preço efetivo é igual ou ligeiramente superior. O ganho não é centavo. O ganho é opcionalidade: a capacidade de mudar de modelo sem refatorar código, de testar hipótese sem abrir conta, de fazer fallback sem implementar lógica.

Opcionalidade tem valor — mas é um valor que aparece em decisões futuras, não em fatura atual. Se você é solo founder e não tem certeza de qual modelo vai usar daqui 6 meses, pagar 5% a mais hoje pra ter essa flexibilidade depois é racional. Se você já decidiu seu modelo fixo, pagar 5% a mais é teatro.

O que eu te recomendo testar antes de adotar

Se você nunca usou OpenRouter, três experimentos valem o tempo:

1. Pega uma task que você faria em Sonnet e roda em 4 modelos diferentes via OpenRouter: Sonnet, Llama 3.3 70B, Gemini Flash, DeepSeek. Compara saída. Isso te ensina mais sobre IA-em-2026 do que ler 50 threads de Twitter.

2. Calcula seu custo mensal real direto vs via OpenRouter com seus volumes. Se a diferença é menos de 10%, o gateway é barato pra opcionalidade que ele te dá. Se é mais de 30%, vai direto na fonte.

3. Implementa um fallback simples: Sonnet primeiro, se falhar tenta Haiku, se falhar tenta Llama. Em 5 linhas, você tem resiliência que antes exigiria SDK custom. Isso é o tipo de coisa que muda como você arquiteta.

O que eu não te recomendo

Não te recomendo OpenRouter como economia. Se sua decisão é financeira pura, vá direto na fonte do modelo que você decidiu usar.

Não te recomendo como solução pra "indecisão de stack". Se você não decidiu qual modelo usar porque não testou nenhum direito, o problema não é gateway — é falta de experimentação. Resolve esse antes.

Não te recomendo se você só usa um modelo, todo dia, sempre. Aí gateway é pure overhead.

E não te recomendo sem ler a página de pricing do provider que você quer usar antes. OpenRouter mostra preços, mas o catálogo do provider original geralmente tem mais nuance (cache discounts, volume discounts, batch processing).

Fechamento

OpenRouter é uma das ferramentas mais úteis da minha stack — quando eu uso. E eu não uso pra metade das coisas que ele poderia servir, porque pra metade dessas coisas o cálculo aponta pra outro caminho.

O ponto desse post não é "use OpenRouter". É: faça o cálculo. Gateway é uma decisão de arquitetura, e como toda decisão de arquitetura, o melhor não existe — só existe o que faz sentido pro shape do que você está construindo.

Se você é solo founder, AI-first, e tá começando a montar stack, OpenRouter vale conhecer. Se você já tem um modelo principal definido com volume previsível, talvez não. A diferença entre os dois cenários é a única coisa que importa.