OpenRouter: Como construir uma empresa de mil milhões de dólares com um "hub de modelos"?

Autor: Zhang Aila

Hoje vamos falar sobre o "hub" (ou intermediário).

Simplificando, um hub de modelos consiste em conectar diferentes modelos como OpenAI, Claude, Gemini, DeepSeek etc. atrás de uma única entrada, permitindo que os programadores utilizem vários modelos com uma única interface, uma conta e faturação unificada, e possam escolher, alternar e ter backups entre diferentes modelos ou fornecedores.

Claro, para utilizadores na China continental, a maior razão para usar um hub é ter acesso a modelos estrangeiros e a preços mais baixos.

Todos sabem do que se trata, não vamos falar muito sobre os hubs domésticos; hoje vamos apresentar principalmente o OpenRouter.

Até 2026, a OpenRouter já tinha angariado 113 milhões de dólares numa ronda Série B, com uma avaliação de quase 1,3 mil milhões de dólares.

Ou seja, já é uma empresa unicórnio.

Vamos então analisar: porque é que um hub de modelos que "não cria modelos" vale tanto dinheiro?

O que é que a OpenRouter realmente faz?

A OpenRouter define-se oficialmente como: uma interface unificada para grandes modelos.

Atualmente, a OpenRouter suporta mais de 400 modelos e mais de 70 fornecedores de modelos.

O site oficial também revela que a plataforma processa mensalmente 100 biliões de tokens e tem mais de 10 milhões de utilizadores em todo o mundo.

No anúncio da ronda Série B de maio de 2026, foi também mencionado que, nos últimos 6 meses, o processamento semanal da OpenRouter cresceu de 5 biliões de tokens para 25 biliões de tokens, servindo mais de 8 milhões de programadores.

Estes números mostram uma coisa:

A OpenRouter já não é uma ferramenta de nicho para programadores, mas sim uma grande porta de entrada para chamadas de IA.

A forma como os programadores a utilizam é também muito simples.

Antes, era necessário ligar-se separadamente a modelos como OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, etc.

Cada integração exigia ler documentação, solicitar uma chave API, configurar faturação, lidar com diferenças de interface, ver regras de limite de taxa e fazer tratamento de exceções.

Com a OpenRouter, os programadores podem chamar diferentes modelos através da mesma interface.

Muitas vezes, o código que originalmente usava a interface da OpenAI só precisa de alterar o base URL, mudar a chave API e especificar o nome do modelo para poder chamar outros modelos através da OpenRouter.

Esta é também uma das razões para o seu rápido crescimento inicial: baixo custo de migração.

Porque é que os programadores não se ligam diretamente às empresas de modelos?

Aparentemente, os programadores podem contornar a OpenRouter e ativar diretamente a API no site oficial da empresa de modelos.

Mas no desenvolvimento real, isto não é assim tão simples.

Se um produto de IA for apenas uma demonstração, basta usar um modelo. Mas quando se entra em negócios reais, é difícil depender de apenas um modelo.

Por exemplo, uma ferramenta de escrita com IA pode ter vários tipos de tarefas diferentes:

Gerar títulos: basta usar um modelo barato;

Escrever artigos longos: requer maior capacidade textual;

Analisar dados: requer modelos com contexto longo;

Moderar conteúdo: requer capacidade de classificação de baixo custo e alta estabilidade;

Clientes empresariais exigem que os dados não sejam retidos, sendo necessário escolher fornecedores que cumpram as políticas de dados;

Durante picos, o modelo pode sofrer limitação de taxa, sendo necessário mudar automaticamente para um modelo de backup.

Neste ponto, o problema não é apenas "ligar uma API".

A equipa precisa de manter um sistema completo de chamadas de modelos:

Qual modelo é responsável por qual tarefa, qual modelo é mais barato, qual fornecedor é mais rápido, qual fornecedor tem menor taxa de falhas, como alternar quando algo corre mal, como atribuir a faturação, como isolar os dados dos clientes empresariais.

Mais problemático ainda, o mercado de modelos muda muito rapidamente.

Hoje o Claude é adequado para escrever código, amanhã o contexto longo do Gemini é mais vantajoso, depois de amanhã o DeepSeek ou algum modelo open source reduz o preço.

As capacidades dos modelos, preços, comprimento do contexto, políticas dos fornecedores, estão sempre a mudar.

O valor da OpenRouter reside precisamente aqui.

Não é escrever aplicações de IA para os programadores, mas sim gerir para eles "qual modelo usar, como chamar, como fazer backup, como controlar custos".

Não é apenas um supermercado de modelos, mas uma camada de orquestração de modelos

Se entendermos a OpenRouter apenas como um "supermercado de modelos", subestimamo-la.

O supermercado de modelos resolve "aqui há muitos modelos, podes escolher".

Mas a capacidade verdadeiramente importante da OpenRouter é orquestrar entre modelos e fornecedores.

O mesmo modelo pode ter serviços de inferência fornecidos por diferentes fornecedores.

Por exemplo, um modelo open source pode ser hospedado por vários fornecedores de cloud ou serviços de inferência. Os preços, velocidades e estabilidades de diferentes fornecedores não são iguais.

Na documentação da OpenRouter existe uma funcionalidade chamada provider routing, ou seja, roteamento de fornecedores.

Os programadores podem, com base em condições como preço, latência, débito, ordem dos fornecedores, fazer com que os pedidos sigam automaticamente para diferentes fornecedores.

Também suporta fallback, ou seja, quando um modelo ou fornecedor falha, o sistema muda automaticamente para uma opção de backup.

Para os programadores, a OpenRouter equivale a retirar a "seleção de modelos" e o "tratamento de falhas" do código de negócio e entregá-los a uma plataforma especializada.

Porque é que as empresas precisam desta camada?

Quando as empresas adotam IA, a questão inicial é normalmente "se funciona", mas rapidamente se torna "como gerir".

Dentro de uma empresa, muitas equipas podem estar a usar IA.

A equipa de marketing para escrever conteúdo, a equipa de apoio ao cliente para responder a utilizadores, a equipa de I&D para escrever código, a equipa de operações para analisar dados, a equipa jurídica para tratar contratos.

Se cada equipa se ligar aos seus próprios modelos, os problemas aumentam:

Faturação não clara; seleção de modelos não uniforme;

Políticas de dados opacas; diferentes equipas a ligarem-se repetidamente;

Quando algo corre mal, ninguém sabe de que chamada veio;

Quando o fornecedor do modelo muda, o sistema tem dificuldade em ajustar-se de forma uniforme.

Os workspaces, controlo de orçamento, registos de chamadas, políticas de fornecedores e roteamento de retenção zero de dados que a OpenRouter fornece resolvem estes problemas.

Por exemplo, a retenção zero de dados.

Para muitas empresas, nem todos os pedidos podem ser enviados para qualquer fornecedor de modelos. Informações de clientes, conteúdo de contratos, dados médicos, dados financeiros, podem ter requisitos rigorosos.

A documentação da OpenRouter suporta Zero Data Retention, ou seja, retenção zero de dados.

Os programadores podem configurar para enviar pedidos apenas para fornecedores que não armazenam dados. Esta política pode ser aplicada globalmente, por grupo de modelos, por regras de segurança ou por pedido individual.

Outro exemplo é o prompt caching, ou seja, cache de prompts.

Muitas aplicações de IA reutilizam prompts de sistema longos, conteúdo de bases de conhecimento ou contexto. Se forem recalculados sempre, o custo será elevado.

A OpenRouter suporta o aumento da taxa de acerto da cache através de roteamento de afinidade com o fornecedor, tentando fazer com que os pedidos subsequentes sigam para o mesmo endpoint do fornecedor, reduzindo assim o custo de contexto repetido.

Este tipo de funcionalidades pode não parecer atraente, mas são muito práticas, e quanto maior a escala da aplicação de IA, mais óbvia é a redução de custos.

Como é que a OpenRouter ganha dinheiro?

O modelo de negócio da OpenRouter é claro: ganha dinheiro com base no uso.

Os programadores compram primeiro créditos na plataforma e depois pagam com base nos modelos e tokens realmente chamados.

A OpenRouter escreve claramente:

A plataforma cobra uma taxa de 5,5% na compra de créditos, com um mínimo de 0,80 dólares; os preços dos fornecedores de modelos subjacentes são repassados aos utilizadores pelo preço original, sem margem adicional sobre o preço de inferência.

Este é um negócio muito típico de "portagem de tráfego".

A vantagem deste modelo é que a receita está ligada ao uso.

Quanto mais os programadores chamam, maior a receita da plataforma; quanto mais aplicações de IA e maior o consumo de tokens, maior o negócio da OpenRouter.

Mas também tem uma característica: a comissão por chamada não é alta, por isso tem de depender da escala.

É também por isso que o volume de processamento de tokens é importante para a OpenRouter.

A sua métrica principal não é o número de utilizadores registados, mas sim quantos tokens fluem através dela por semana e por mês.

Em 2025, o processamento anual da OpenRouter cresceu de cerca de 10 biliões de tokens para mais de 100 biliões de tokens.

Em 2026, a OpenRouter já atingiu um processamento anualizado de cerca de 1,5 quatriliões de tokens.

Esta é a lógica subjacente a este negócio.

Enquanto mais e mais aplicações de IA correrem em sistemas multi-modelo, a OpenRouter poderá continuar a cobrar taxas de serviço dessas chamadas.

Porque é que o crescimento recente tem sido tão rápido?

O crescimento da OpenRouter, em resumo, beneficiou de três mudanças.

A primeira mudança é que há cada vez mais modelos.

Antes, ao fazer aplicações de IA, muitas equipas usavam a OpenAI por defeito. Agora é diferente.

Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, e muitos modelos open source e de pesos abertos, têm vantagens em diferentes cenários.

Este não é um mercado de "quem substitui completamente quem".

Alguns modelos são bons a escrever código, outros são baratos, outros têm boa capacidade de texto longo, outros são rápidos, outros são adequados para role-playing, outros para documentos empresariais, outros para multimodalidade.

Quanto mais modelos, maior o custo de escolha; quanto maior o custo de escolha, mais valiosa é a camada intermédia.

A segunda mudança é que as aplicações de IA começaram a focar-se nos custos.

Muitos produtos usam os modelos mais fortes no início, porque primeiro precisam de demonstrar resultados.

Mas assim que o produto tem utilizadores, os custos dos modelos tornam-se rapidamente um problema.

Um chatbot de apoio ao cliente, um produto de pesquisa com IA, um assistente de código, uma ferramenta de geração de conteúdo, se todos os pedidos forem para o modelo mais caro, a margem bruta é facilmente consumida.

Uma abordagem mais madura é dividir as tarefas:

Tarefas simples: usar modelos baratos;

Tarefas complexas: usar modelos fortes;

Tarefas de alta frequência: dar prioridade a modelos de baixa latência;

Após falha, mudar para modelo de backup;

Quando envolvem dados sensíveis, usar apenas fornecedores que cumpram as políticas de dados.

Este é exatamente o cenário de uso da OpenRouter.

Pode não te ajudar a encontrar o "modelo mais forte", mas pode ajudar-te a equilibrar entre desempenho, preço, velocidade e estabilidade.

A terceira mudança é que as aplicações de IA estão a passar de caixas de chat para agentes.

Os agentes chamam ferramentas, leem ficheiros, pesquisam na web, executam tarefas, e também fazem chamadas consecutivas de várias rondas aos modelos.

Comparado com o chat normal, os agentes consomem mais tokens e dependem mais da estabilidade.

Isto é favorável para a OpenRouter.

Porque quanto mais chamadas e mais longa a cadeia, mais os programadores precisam de roteamento, backups, registos, controlo de custos e gestão de fornecedores.

É também por isso que o anúncio de financiamento da OpenRouter enfatiza que a IA está a passar da experimentação para aplicações críticas de produção e cenários de agentes.

O seu crescimento vem, essencialmente, do aumento do volume de chamadas de IA.

Este negócio também tem riscos

A posição da OpenRouter é boa, mas não é segura.

Está entre empresas de modelos, fornecedores de cloud e programadores de aplicações. Esta posição tem valor, mas também é facilmente comprimida.

O primeiro risco é que as grandes empresas podem construir as suas próprias soluções.

Para pequenas equipas, a OpenRouter é muito conveniente.

Mas para grandes empresas, o roteamento de modelos, permissões, registos, gestão de custos, também podem fazer eles próprios, ou entregar a fornecedores de cloud.

Especialmente clientes financeiros, de saúde e governamentais, podem preocupar-se mais com o controlo de dados e implantação privada.

Para a OpenRouter entrar nestes clientes, não pode contar apenas com "muitos modelos". Tem de aprofundar suficientemente as permissões, auditoria, políticas de dados, gestão de fornecedores e suporte empresarial.

O segundo risco é que os fornecedores de cloud também farão gateways de modelos.

Plataformas cloud como AWS, Google Cloud, Azure já têm clientes empresariais, sistemas de faturação, sistemas de permissões e capacidades de conformidade.

Elas podem perfeitamente transformar chamadas multi-modelo, roteamento, monitorização e gestão de custos numa parte do serviço cloud.

A vantagem da OpenRouter é ser aberta e neutra, com cobertura de modelos mais ampla e integração mais rápida.

Mas a vantagem dos fornecedores de cloud são as relações com clientes e os processos de aquisição empresarial; esta é uma competição de longo prazo.

O terceiro risco é a relação com os fornecedores de modelos.

A OpenRouter traz tráfego para as empresas de modelos, mas também distancia as empresas de modelos dos programadores finais.

Quando a plataforma se torna maior, ela detém mais relações com utilizadores e dados de uso de modelos.

Os fornecedores de modelos tanto desejam obter distribuição como temem que o seu poder de negociação seja enfraquecido.

Este tipo de plataformas de camada intermédia são geralmente bem-vindas pelos fornecedores no início; quando a escala aumenta, a relação torna-se mais delicada.

O quarto risco é que a taxa da plataforma pode ser reduzida.

A OpenRouter cobra 5,5% de taxa de plataforma, o que parece baixo agora.

Mas se houver cada vez mais serviços semelhantes, os programadores vão comparar preço, estabilidade, cobertura de modelos e funcionalidades empresariais.

Se alguns concorrentes estiverem dispostos a oferecer taxas mais baixas, ou se os fornecedores de cloud empacotarem estas capacidades nos seus serviços existentes, a OpenRouter precisará de provar que não é apenas um "encaminhador de pedidos".

Ela terá de continuar a oferecer melhor roteamento, maior cobertura de modelos, preços mais transparentes, serviços mais estáveis e controlo empresarial mais completo.