blackdark
FerramentasOpenRouterAPI de IAgateway de LLMmodelos de IApagamento por usodesenvolvimento

OpenRouter: uma só chave para centenas de modelos de IA (guia 2026)

O que é o OpenRouter e por que importa: uma única API compatível com a OpenAI para aceder a centenas de modelos (GPT, Claude, Gemini, Llama…), como funcionam o routing e os fallbacks, preços por créditos, prós e contras e para quem vale a pena.

Por BlackdarkAtualizado em 7 min de leitura

Se andas há algum tempo a construir coisas com IA, conheces a dor: hoje queres testar o Claude para raciocinar, amanhã o GPT para escrever, para a semana um modelo open source barato para tarefas parvas. Cada um tem a sua própria API, a sua própria chave, o seu próprio SDK, a sua própria forma de cobrar. E de cada vez que queres mudar, toca reescrever pedaços de código e criar mais uma conta.

O OpenRouter existe para matar essa dor. A ideia é de uma simplicidade traiçoeira: uma só chave para todos os modelos. Vamos ver o que há mesmo por trás e quando vale a pena, sem fumo.

Nota

Este guia é técnico, mas útil quer programes, quer só queiras entender por que tanta ferramenta de IA "funciona com OpenRouter". Não é preciso ser dev para apanhar a ideia; a parte de código é opcional.

O que é o OpenRouter e que problema resolve

O OpenRouter é um gateway (passagem) de modelos de IA. Traduzindo: é uma camada intermédia que se senta entre a tua aplicação e as centenas de modelos que andam espalhados pelo mundo. Tu falas com o OpenRouter; o OpenRouter fala com a OpenAI, com a Anthropic, com a Google, com a Meta, com a Mistral, com dezenas de fornecedores de modelos open source. Uma só chave, um só URL base, uma só fatura.

O problema que resolve é a fragmentação. Hoje o mercado da IA está partido em silos: cada laboratório tem a sua API, o seu sistema de faturação e as suas manias. Se queres usar três modelos de três empresas diferentes, manténs três integrações. Se amanhã sai um modelo melhor, toca criar outra conta e ligar outro SDK. É atrito puro, e o atrito mata a experimentação.

O OpenRouter faz tudo isso desabar num único ponto de entrada. Dá acesso a centenas de modelos de dezenas de fornecedores através da mesma interface. E o detalhe que o torna viciante para quem programa: a sua API é compatível com a da OpenAI. Isso significa que se o teu projeto já usa o SDK da OpenAI, migrar é praticamente mudar duas coisas —o URL base e a chave— e começar a invocar qualquer modelo do catálogo com o mesmo código.

Há também um chat web (playground) para quem não quer tocar em código: entras, escolhes um modelo de um menu enorme e conversas, comparando respostas do GPT, Claude ou Gemini no mesmo ecrã sem saltar entre separadores. É a forma mais rápida de "provar" modelos antes de os meter em produção.

Como se usa: chave, URL base e escolher modelo

O fluxo para começar é curto. Registas-te, geras uma chave API e apontas o teu código para o URL base do OpenRouter:

Chamada básica ao OpenRouter (Python)
import requests, json

response = requests.post(
url="https://openrouter.ai/api/v1/chat/completions",
headers={
  "Authorization": "Bearer <A_TUA_CHAVE_OPENROUTER>",
  "HTTP-Referer": "https://oteudominio.com",
  "X-Title": "A Tua App",
},
data=json.dumps({
  "model": "anthropic/claude-sonnet",
  "messages": [
    {"role": "user", "content": "Resume isto numa frase: ..."}
  ]
})
)

O importante desse bloco não é a sintaxe, é o que implica. O URL base é sempre https://openrouter.ai/api/v1. O modelo escolhe-se com um slug do tipo fornecedor/modelo (anthropic/claude-sonnet, openai/gpt-..., google/gemini-..., meta-llama/...). Queres mudar de Claude para GPT? Mudas a string do campo model. Uma linha. O resto do código não se toca.

Essa é a magia operacional: o modelo deixa de ser uma decisão de arquitetura e passa a ser um parâmetro. Podes fazer A/B testing de dois modelos na mesma função, deixar o modelo numa variável de ambiente, ou expô-lo como definição para que o utilizador final escolha. Tudo sem reescrever integrações.

Como a API imita a da OpenAI, quase qualquer biblioteca ou ferramenta que "fala OpenAI" funciona com o OpenRouter mudando esses dois campos. Por isso vês tantas apps de IA, clientes de chat e frameworks que o suportam de origem: para eles, suportar o OpenRouter é suportar todo o mercado de uma vez.

Preços: créditos e pagamento por uso

Aqui convém ser preciso para não haver surpresas. O OpenRouter funciona com créditos e pagamento por uso, não com subscrição.

  • Carregas saldo (com cartão ou cripto) e vai sendo descontado por tokens à medida que fazes chamadas.
  • Não há mínimos, nem quota mensal, nem prazo de validade do saldo. Pagas o que consomes e pronto.
  • O preço por token de cada modelo coincide com o que o fornecedor original cobra. O OpenRouter não inflaciona o preço por token.
  • A comissão está no recarregamento: à volta de 5,5% ao adicionar créditos com cartão (algo mais alta a pagar em cripto).

É um modelo honesto e fácil de raciocinar: vês o preço de cada modelo no seu catálogo, sabes que é o do fornecedor, e a única camada extra é essa comissão ao meter saldo. Como ordens de grandeza (não como preço exato), os modelos potentes rondam os poucos dólares por milhão de tokens e os leves descem a cêntimos; o catálogo tens sempre atualizado lá dentro.

Dica

Antes de gastares um euro, aproveita os modelos gratuitos: o OpenRouter oferece dezenas de modelos a custo zero por token (com limites de pedidos por minuto e por dia). Perfeitos para prototipar, montar o fluxo e comparar qualidade antes de ligar um modelo pago.

Routing e fallbacks: a parte que dá valor a sério

Se "uma só chave" é a isca, o routing inteligente é o que justifica ter uma camada intermédia em produção. O OpenRouter não se limita a reencaminhar o teu pedido: decide como e onde executá-lo.

Repartição entre fornecedores. Um mesmo modelo (digamos um Llama grande) costuma estar servido por vários fornecedores de computação ao mesmo tempo. O OpenRouter equilibra a carga entre eles e, se um cai ou fica lento, tenta noutro automaticamente. Para a tua app, o modelo "continua vivo" mesmo que um fornecedor concreto tenha um dia mau.

Otimizar por velocidade ou por preço. Podes afinar essa repartição com sufixos no slug do modelo:

  • :nitro prioriza o desempenho (mais tokens por segundo). Ideal para chat virado ao utilizador, onde se nota cada milissegundo.
  • :floor prioriza o preço (o fornecedor mais barato disponível). Ideal para trabalhos em lote onde o que importa é o custo, não a latência.

Fallback entre modelos diferentes. A repartição anterior mantém vivo um modelo. Mas e se quiseres que, quando um modelo inteiro falha (queda total, passas do limite de contexto, apanhas rate limit ou moderação), salte para outro modelo diferente? Para isso passas um array de modelos por ordem de prioridade: o OpenRouter experimenta o primeiro e, se der erro, desce para o seguinte da lista. O teu plano B (e C) automatizado.

E se nem sequer queres decidir, existe o Auto Router (openrouter/auto): passas-lhe o prompt e o OpenRouter escolhe o modelo por ti conforme o que detetar. Útil quando não sabes que tipo de pedidos te vão chegar. Regra simples: usa o Auto Router quando não controlas o input; usa o array de fallback quando sabes que modelo queres e só procuras resiliência por trás.

O bom e o mau, sem maquilhagem

Prós

  • Uma só chave e uma só integração para centenas de modelos de muitos fornecedores.
  • API compatível com a OpenAI: mudar de modelo é mudar uma string, não reescrever código.
  • Routing com fallback automático entre fornecedores: mais resiliência em produção.
  • Pagamento por uso transparente, sem subscrição, e dezenas de modelos gratuitos para testar.
  • Não te prendes a ninguém: comparas e migras de modelo em minutos, não em sprints.

Contras

  • Não baixa o preço do token: o preço é o do fornecedor mais uma comissão ao recarregar (~5,5%).
  • É mais uma camada intermédia: um ponto extra de dependência e possível latência.
  • Para um único fornecedor em grande volume, ir direto pode sair igual ou melhor.
  • Algumas funções muito específicas de um fornecedor podem não estar expostas da mesma forma.
  • Gerir saldo e vigiar o gasto por tokens exige disciplina própria.

Para quem é o OpenRouter?

O OpenRouter não é "o sítio mais barato para chamar a IA"; é a forma de não te casares com nenhum. E isso encaixa às mil maravilhas para uns e sobra para outros.

Interessa-te se: desenvolves e queres testar e comparar modelos sem montar três integrações; precisas de resiliência em produção e o fallback automático te vem a calhar; constróis uma app onde o modelo é uma preferência configurável; ou simplesmente não queres apostar tudo num fornecedor cujo melhor modelo de hoje pode não ser o de daqui a três meses. Também se és criador ou curioso e queres um único playground para provar GPT, Claude e Gemini lado a lado.

Não te interessa se: já tens claro que vais usar um só modelo de um só fornecedor de forma estável e em grande volume —aí a integração direta poupa-te uma camada e uma comissão—, ou se precisas de funções muito específicas que só a API nativa desse fornecedor expõe.

O caso real mais honesto: um dev que monta um assistente para um cliente arranca com um modelo open source gratuito para prototipar, sobe-o para um Claude potente para a versão a sério, deixa um GPT como fallback caso o primeiro caia, e faz tudo isso mexendo num punhado de strings, com uma chave e uma fatura. Essa agilidade —não o preço— é o que o OpenRouter vende. A pergunta não é "é o mais barato?", mas "quanto vale para mim poder mudar de modelo sem reescrever nada?". Se te dedicas a isto, costuma valer bastante.

FAQ

O OpenRouter é uma passagem (gateway) de modelos de IA: uma única API que encaminha os teus pedidos para centenas de modelos de muitos fornecedores (OpenAI, Anthropic, Google, Meta, Mistral e modelos open source) usando uma só chave e um só URL base. A sua API é compatível com a da OpenAI, por isso funciona como substituição direta em projetos que já usam esse SDK.

Paga-se por uso com um sistema de créditos: adicionas saldo com cartão ou cripto e é descontado por tokens conforme o modelo que usas, sem subscrição, sem mínimos e sem prazo de validade. A comissão está no recarregamento (à volta de 5,5%), não em cada token, por isso os preços por token coincidem com os do fornecedor. Além disso, há dezenas de modelos gratuitos com limites de pedidos por minuto e por dia.

Para um mesmo modelo, o OpenRouter reparte os pedidos entre os fornecedores disponíveis e, se um falhar ou for lento, tenta noutro automaticamente. Podes ordenar por velocidade acrescentando :nitro ao modelo, ou por preço com :floor. E se quiseres saltar para um modelo diferente quando o primeiro falha (queda, limite de contexto, rate limit), passas um array de modelos por ordem de prioridade.

Não necessariamente. Os preços por token são os mesmos que cada fornecedor cobra; o que o OpenRouter acrescenta é uma comissão ao recarregar créditos (~5,5%, um pouco mais em cripto). O que ganhas não é preço, é flexibilidade: uma só integração, comparar modelos sem atrito e fallbacks. Se usas um único fornecedor e não precisas de nada disso, ir direto pode sair igual ou ligeiramente mais barato.

Para quem desenvolve e quer testar e comparar modelos sem reescrever código, para apps que precisam de resiliência (fallback entre fornecedores) e para quem não quer ficar preso a um só fornecedor. Se só vais usar um modelo de um fornecedor de forma estável e em grande volume, a camada intermédia e a comissão podem não compensar face à integração direta.

Compartilhar
Newsletter

Receba os próximos guias no seu e-mail

Ideias e recursos de IA e marketing, sem enrolação. O que funciona e como aplicar.

Ideias e recursos sem spam. Cancela quando quiseres.

Este guia está ajudando?

Inscrever-se