Seu Provedor de IA Está Mentindo: O que 606 Devs Descobriram sobre o OpenRouter

Você manda um request pra Claude, recebe HTTP 200, o JSON vem bonitinho. Tudo certo, né? Talvez não. Um desenvolvedor resolveu testar a fundo o que acontece quando você roteia chamadas de IA pelo OpenRouter, e o resultado explodiu no Hacker News com mais de 600 upvotes. A conclusão é desconfortável: o mesmo modelo, rodando em provedores diferentes, pode dar respostas completamente diferentes. E o pior: quando dá errado, ninguém te avisa.

Se você usa OpenRouter em produção (ou está pensando em usar), este artigo vai te fazer repensar algumas decisões.

O que é o OpenRouter (e por que virou tão popular)

Pra quem não conhece, o OpenRouter é um gateway de APIs de IA. Em vez de criar conta na OpenAI, na Anthropic, no Google, no DeepSeek e em mais dez provedores diferentes, você cria uma conta só no OpenRouter e acessa todos os modelos por uma API unificada. Uma chave, um endpoint, dezenas de modelos.

A proposta é atraente:

• Troca de modelo mudando uma string no código
• Dashboard unificado de gastos
• Fallback automático se um provedor cair
• 25 a 33 modelos gratuitos sem cartão de crédito
• Configuração simples: é só trocar a baseURL do SDK da OpenAI

Por isso o OpenRouter virou o queridinho de quem prototipa agentes, testa modelos diferentes, ou simplesmente não quer gerenciar cinco API keys distintas. Parece bom demais pra ser verdade. E em parte, é.

O post que estourou: benchmarks reais, provedores reais

O desenvolvedor Moustafa publicou uma análise detalhada testando o OpenRouter contra provedores diretos. Não foi achismo: ele rodou benchmarks padronizados (GPQA Diamond, tool-calling, vision) em múltiplos provedores servidos pelo OpenRouter. Os números são preocupantes.

O DeepSeek V4 Flash, por exemplo, mostrou uma variação de 15 pontos no GPQA Diamond dependendo do provedor: 75% num host, 90% em outro. No benchmark de tool-calling, a diferença chegou a 23 pontos (de 58% a 81%). Moustafa resume bem: “uma variação de 20 pontos não é ruído”.

Pra quem está construindo agentes que dependem de tool-calling preciso, isso é catastrófico. Seu agente funciona perfeitamente na segunda-feira, e na terça o OpenRouter roteou seu request pra outro provedor e o agente quebra. Sem nenhuma mudança no seu código.

Modelos de visão: quando 200 OK significa “não vi nada”

O cenário fica pior com modelos de visão. Alguns provedores simplesmente ignoram a imagem enviada no request, mas retornam HTTP 200 como se tivesse dado tudo certo.

O teste com o Qwen3.5 no DeepInfra mostrou que o modelo identificou letras e cores erradas. Com o MiniMax M3, provedores como Venice e Together retornaram “no image provided” mesmo recebendo a imagem, mas o status era 200 OK. Nas palavras do autor: “eles fingem que está tudo bem.”

Imagina isso em produção. Você tem um pipeline que analisa documentos escaneados, extrai dados de notas fiscais ou valida selfies de usuários. O request passa, o status é sucesso, mas a resposta é lixo porque o provedor nem processou a imagem. Boa sorte debugando isso num sábado à noite.

Reasoning effort: o parâmetro que ninguém respeita

Modelos como o Claude e o DeepSeek oferecem um parâmetro reasoning.effort que controla quanto o modelo “pensa” antes de responder. Em teoria, max gera respostas mais profundas (e mais caras), enquanto low dá respostas rápidas e baratas.

Na prática? Vários provedores simplesmente ignoram esse parâmetro. DigitalOcean, GMI-Cloud, Mancer e Venice mostraram pouca ou nenhuma variação nos tokens de raciocínio entre low, high e max. Você pede pro modelo pensar mais, ele responde igual. Mas cobra como se tivesse pensado.

Isso quebra qualquer estratégia de otimização de custos baseada em reasoning tiers. Se você está usando low pra triagem rápida e max pra decisões críticas, pode ser que ambos estejam rodando exatamente igual, dependendo de pra onde o OpenRouter mandou seu request.

Quantização declarada vs. qualidade real

Um dos filtros mais usados no OpenRouter é a precisão do modelo: fp4, fp8, fp16. A lógica é simples: maior precisão = melhor qualidade. Mas os testes mostraram que a precisão declarada não tem correlação confiável com performance real.

O provedor Wafer, por exemplo, conseguiu as melhores notas em benchmarks sem declarar nenhuma precisão. Enquanto isso, hosts declarando fp4 apareceram espalhados por toda a distribuição de qualidade, alguns bons, outros péssimos.

Ou seja: filtrar por fp8 ou fp16 no OpenRouter não garante nada. O rótulo é do provedor, não há verificação independente.

Tool-calling: quando o modelo devolve XML cru

Se você está construindo agentes com function calling, prepare-se. Provedores frequentemente falham no parsing de tool calls e retornam markup cru ao invés de JSON estruturado:

<use_skills><parameters>{"skills":["search"]}</parameters></use_skills>

Em vez do JSON limpo que você espera:

{
  "tool_calls": [
    {
      "function": {
        "name": "search",
        "arguments": "{}"
      }
    }
  ]
}

Isso significa que, na prática, qualquer aplicação séria usando tool-calling via OpenRouter precisa implementar fallback parsing. Você precisa tratar tanto o formato correto quanto o formato quebrado, porque não dá pra saber qual provedor vai atender seu próximo request.

Falhas silenciosas: o bug fantasma

Talvez o problema mais perigoso seja o das falhas silenciosas. Alguns provedores retornam HTTP 200, mas o conteúdo da resposta vem null, sem nenhum output de raciocínio, sem nenhuma mensagem de erro. É um request que simplesmente desaparece.

O provedor StreamLake, por exemplo, teve um período em julho onde 92% dos completions vinham vazios, mas com status 200. Noventa e dois por cento. E o OpenRouter não sinalizava isso de nenhuma forma especial.

Se o seu sistema monitora apenas HTTP status codes (como a maioria faz), essas falhas passam completamente desapercebidas. Seus logs mostram 200 OK, seu dashboard de uptime mostra 100%, e seus usuários estão recebendo respostas vazias.

O problema do rate-limiting por IP

Outro gotcha que pega muita gente: provedores fazem rate-limiting por endereço IP, não por API key. O autor relata que Venice e Novita funcionavam perfeitamente do Mac dele, mas retornavam 429 (Too Many Requests) da infraestrutura de produção com a mesma API key.

Isso faz sentido quando você pensa que, em produção, múltiplos workers podem estar mandando requests do mesmo IP (ou range de IPs do cloud provider). Mas o OpenRouter não te avisa disso. Você configura fallback pra três provedores “confiáveis” (Cloudflare, Baidu, Alibaba) e, em semanas, todos estão retornando 429 ou descontinuaram o modelo.

Quanto custa essa “conveniência”?

Vamos falar de dinheiro. O OpenRouter cobra uma taxa de 5.5% sobre compras de crédito. Os preços dos modelos em si seguem a tabela do provedor original, sem markup. Parece justo, mas vamos colocar em perspectiva.

US$ 2,750 por mês é o salário de um desenvolvedor junior em muitos mercados. E isso sem contar o custo invisível: debugging de inconsistências entre provedores, retry logic extra, e o tempo perdido quando um provedor silenciosamente retorna lixo.

Tem um lado positivo real na latência, no entanto. Benchmarks recentes mostram que o OpenRouter foi 70ms mais rápido que a API direta da OpenAI no time-to-first-token (0.640s vs 0.712s). Isso provavelmente se deve ao caching e à infraestrutura de edge do OpenRouter. Mas outros testes reportam overhead de 80 a 250ms. Depende da geografia e do momento.

Quando o OpenRouter faz sentido (de verdade)

Eu não vou dizer que o OpenRouter é ruim. Ele resolve um problema real. Mas tem contextos onde ele funciona e contextos onde é uma bomba-relógio:

Funciona bem para:

• Prototipagem rápida e experimentação com múltiplos modelos
• Projetos pessoais e MVPs onde consistência não é crítica
• Comparação de modelos durante a fase de avaliação
• Aplicações com tolerância a variação de qualidade
• Times que ainda não decidiram qual modelo usar em produção
• Hackathons e provas de conceito com prazo apertado
• Desenvolvedores solo que não querem gerenciar múltiplas contas e billing

Evite em produção quando:

• Tool-calling preciso é requisito (agentes, automações)
• Processamento de imagens/documentos é parte do pipeline
• Você precisa de SLA de uptime (o OpenRouter não oferece)
• Consistência de resposta é crítica (saúde, finanças, jurídico)
• Seu volume justifica integração direta (acima de US$ 5k/mês)

A alternativa: integração direta com fallback manual

Se você decidir sair do OpenRouter (ou nunca entrar), aqui vai uma arquitetura que funciona:

import os
from anthropic import Anthropic
from openai import OpenAI

# Provedores diretos com fallback manual
providers = [
    {
        "name": "anthropic",
        "client": Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"]),
        "model": "claude-sonnet-4-6"
    },
    {
        "name": "openai",
        "client": OpenAI(api_key=os.environ["OPENAI_API_KEY"]),
        "model": "gpt-4.1"
    }
]

async def call_with_fallback(prompt, tools=None):
    for provider in providers:
        try:
            response = provider["client"].chat.completions.create(
                model=provider["model"],
                messages=[{"role": "user", "content": prompt}],
                tools=tools
            )
            if response.choices[0].message.content:
                return response
        except Exception as e:
            print(f"{provider['name']} falhou: {e}")
            continue
    raise Exception("Todos os provedores falharam")

Sim, é mais código. Sim, são múltiplas API keys. Mas você sabe exatamente o que está chamando, a resposta é consistente, e quando dá erro, é um erro de verdade (não um 200 OK com conteúdo vazio).

O que o OpenRouter deveria fazer (mas não faz)

A comunidade no Hacker News deixou claro o que falta:

1. Transparência de provedor: mostrar qual provedor atendeu cada request (alguns endpoints já mostram, mas não é padrão)
2. Validação de resposta: detectar e sinalizar respostas vazias ou malformadas antes de devolver pro cliente
3. Benchmarks contínuos por provedor: medir qualidade real, não confiar na declaração do provedor
4. SLA de qualidade: não só uptime, mas garantia de que o modelo roteado performa dentro de X% do benchmark de referência
5. Rate-limit unificado: abstrair o rate-limiting por IP dos provedores individuais

Até isso acontecer, a responsabilidade de validação cai em você. E a maioria dos devs não sabe que precisa fazer isso.

Como se proteger se continuar usando

Se mesmo depois de tudo isso você decidir continuar no OpenRouter (e tem motivos legítimos pra isso), aqui vão medidas práticas:

1. Pin de provedor: use o header X-Provider pra fixar um provedor específico ao invés de depender do roteamento automático.

2. Validação de resposta: nunca confie só no HTTP status. Verifique se o body tem conteúdo real:

const response = await fetch(openrouterUrl, options);
const data = await response.json();

if (!data.choices?.[0]?.message?.content?.trim()) {
  throw new Error('Resposta vazia do provedor');
}

3. Monitoramento de qualidade: rode benchmarks semanais contra seus casos de uso específicos. A qualidade de um provedor pode degradar sem aviso.

4. Fallback inteligente: não assuma que “três provedores confiáveis” é suficiente. Monitore ativamente e rotacione.

5. Orçamento de teste: separe 5% do orçamento pra testar provedores novos continuamente. O melhor de hoje pode ser o pior de amanhã.

O elefante na sala: confiança em infraestrutura de IA

Esse problema não é exclusivo do OpenRouter. Ele é um sintoma de algo maior: a infraestrutura de IA ainda é imatura. Estamos num momento onde provedores declaram capacidades que não entregam, onde “suporte a vision” pode significar “aceito o request mas ignoro a imagem”, e onde SLAs de qualidade simplesmente não existem.

Pra quem viveu a era dos early cloud providers (2008 a 2012), o déjà vu é forte. AWS, Azure e GCP também tiveram seus períodos de instabilidade, SLAs inexistentes e surpresas na cobrança. A diferença é que, com cloud, você percebia rápido quando o servidor caía. Com IA, a falha pode ser uma resposta que parece certa mas está errada. É uma categoria nova de risco.

A lição aqui não é “não use OpenRouter”. É: não confie cegamente em nenhuma camada de abstração sobre modelos de IA. Teste, monitore, valide. E quando algo parecer bom demais pra ser verdade (uma API, um preço, um benchmark), provavelmente é.

Se o seu produto depende de IA, a qualidade da resposta é o seu produto. Delegar essa responsabilidade pra um roteador automático sem monitoramento é como colocar seu banco de dados em produção sem backup. Funciona até o dia que não funciona. E quando não funciona, ninguém te manda um alerta.

Fonte de inspiração: So you want to use OpenRouter? por Moustafa, trending no Hacker News com 606+ upvotes.