AIREITERDesde 28 de outubro de 2026, o roteamento padrão do OpenRouter mudou de critério: o tempo até o primeiro token caiu 16,9%, houve 67% menos eventos 429 no total e as requisições ficaram cerca de 6% mais caras. É uma melhora relevante, mas com uma contrapartida: o roteamento automático ainda pode direcionar seu tráfego para um provedor mais caro sem chamar atenção.
O novo roteador do OpenRouter não escolhe mais apenas pelo menor preço de token de entrada. Ele tenta calcular o custo de obter uma resposta boa — somando preço, espera e novas tentativas — e envia cada requisição ao provedor com o menor Routing Cost.
Resumo em 30 segundos, com os números
O roteamento de provedores do OpenRouter agora otimiza por Routing Cost, em vez de preço por token do prompt. A mudança entra automaticamente em ação quando a requisição não define provider.sort, provider.order, provider.only nem provider.ignore. Segundo o anúncio do OpenRouter, ela cobre aproximadamente 77% do tráfego, que usa modelos atendidos por mais de um provedor.
Os resultados vêm de um teste switchback de uma semana, com 24 milhões de requisições e 103 bilhões de tokens de entrada, divididos igualmente entre o roteador antigo e o novo.
| Métrica | Roteador antigo | Novo roteador | Variação* |
|---|---|---|---|
| TTFT p50 | 1.007 ms | 837 ms | 16,9% menor |
| Throughput p50 | 62,4 tok/s | 72,6 tok/s | 16,3% maior |
| Requisições com ao menos um 429 | 7,1% | 3,8% | 3,3 pontos percentuais menor; 67% menos eventos 429 no total |
| Requisições que exigiram retry | 10,4% | 6,9% | 3,5 pontos percentuais menor; 47% menos retries no total |
| Custo por 1 mil requisições | $1.25 | $1.32 | 6,0% maior |
| Custo por M tokens | $0.301 | $0.324 | 7,3% maior |
\*Os percentuais de requisições e as reduções na contagem de eventos foram ambos informados no anúncio: os 67% e 47% se referem ao total de eventos 429 e ao total de retries, não à proporção das taxas de ocorrência, pois uma requisição pode encontrar vários erros.
De acordo com o anúncio, o TTFT p95 medido pelo chamador caiu de 6.032 ms para 4.504 ms, o p50 da requisição completa foi de 4,00 s para 3,24 s, e o tempo desperdiçado em tentativas que falharam recuou de 349 ms para 242 ms por requisição.
Em resumo: mantenha o novo padrão para chat interativo ou agentes, caso aceite um custo cerca de 6% maior; volte ao modo orientado só por preço em grandes jobs em lote, nos quais cada centavo faz diferença.
Routing Cost, sem complicação
O Routing Cost responde a duas perguntas para cada provedor: quanto custa uma tentativa e qual a chance de ela dar certo. No exemplo do OpenRouter, uma tentativa de $0.40 mais $0.60 de espera resulta em $1.00. Dividido por uma chance de sucesso de 80%, o custo chega a $1.25 por resposta boa. Quem tiver o menor custo recebe mais tráfego.
Três componentes alimentam esse cálculo:
- Preço efetivo, não preço de tabela. O OpenRouter estima os tokens de entrada e saída a partir do tráfego recente e aplica a taxa real de acerto de cache e os preços de token de cada provedor. Exemplo do anúncio: 40K entradas sem cache a $2.00/M ($0.080), mais 60K entradas em cache a $0.50/M ($0.030), mais cerca de 4K saídas a $8.00/M ($0.032), totalizando $0.142. Um provedor com entrada barata, mas tokens em cache ou de saída caros, perde sua vantagem nesse ponto.
- Tempo de espera convertido em dinheiro. O throughput considera tokens de saída por segundo de ponta a ponta, incluindo o tempo até o primeiro token. Exemplo: 5 s até o primeiro token mais 500 tokens em 5 s equivalem a 50 tok/s. O roteador converte essa espera usando uma taxa por modelo, baseada nos preços e velocidades típicos dos provedores. O tempo até o primeiro token recebe peso extra, pois cadeias de chamadas de ferramentas em agentes dependem dele a cada etapa.
- Custo de falha. Um 429 indica que o provedor recusou a requisição; você espera pela rejeição e então a envia a outro lugar. Exemplo: 2.50 de espera mais penalidade × taxa de 0,4% adiciona 0.01. Erros de confiabilidade recebem uma penalidade cerca de 8x maior — uma taxa de erro de 1% eleva o custo em aproximadamente 8% — e provedores muito piores que seus pares deixam de receber tráfego até se recuperarem. Hoje, a qualidade verifica chamadas de ferramentas bem formadas; 95% de chamadas bem formadas elevam o custo em cerca de 5%. Provedores sinalizados ficam restritos a tráfego de teste, segundo o anúncio.
Há duas proteções contra uma concentração total em um único vencedor, segundo o anúncio: todo provedor preserva uma pequena parcela de tráfego, permitindo detectar sua recuperação, e o roteador recua diante de provedores com falhas enquanto aprende os limites de capacidade de cada um e desloca o excedente para outros.
Por que o roteamento padrão ainda pode quebrar apps em produção
Relatos de usuários mostram quatro falhas recorrentes que o preço por token não consegue capturar.
Trocas durante tool calls quebram schemas
o salto no meio da requisição foi o que realmente quebrou as chamadas de ferramentas para mim, não o preço anunciado de qualquer provedor.
— u/Michael_Jeffords, discussão no r/openrouter sobre provedores a evitar
Hoje, a pontuação de qualidade se baseia principalmente em chamadas de ferramentas bem formadas e sinalizações de precisão em benchmarks, segundo o anúncio. Ainda assim, uma troca no meio da conversa pode alterar quantização ou comportamento de recusa, porque a qualidade varia entre provedores, e alguns servem variantes mais quantizadas.
Quebra de cache aumenta a conta
Uma discussão documenta contextos de cerca de 700K tokens nos quais requisições que deveriam custar $0.20 com cache acabaram cobradas perto de $2.00 após mudanças de provedor. É o padrão por trás de "pagar 10-32x mais por causa de cache quebrado". O novo roteador mantém uma conversa no provedor original enquanto o cache está quente e seleciona algoritmicamente apenas a primeira requisição, conforme o roteamento sensível a cache do OpenRouter. Mas essa afinidade se desfaz em um fallback para outro provedor. Usuários que resolveram o problema fixaram um único provedor com sessões persistentes.
Acho uma falha bastante fundamental do OR que seja preciso configurar isso manualmente de antemão.
— u/welcome_to_milliways, discussão no r/openrouter sobre cache quebrado
Fallback caro e silencioso
Um relato de produção observou parte do tráfego migrando silenciosamente de Sonnet para Opus, a cerca de 5x o preço listado, enquanto o uptime seguia verde e o consumo total saltava de $184/hr para $412/hr, segundo @CarbonOnX. O novo roteador deixa essa troca explícita: um provedor mais rápido e confiável pode, legitimamente, ficar à frente do mais barato.
429 mesmo em conta paga
Ter saldo pago no OpenRouter não amplia a capacidade upstream, como observam usuários nesta discussão sobre 429. Um 429 reflete o pool compartilhado daquele provedor para o modelo. A reformulação reduziu os eventos 429 em 67% nos testes, mas fixar ou ignorar o provedor limitado continua sendo a solução em produção. Comece por como corrigir erros 429 no OpenRouter e consulte o guia do OpenRouter Auto Router para entender o padrão antigo, ponderado por preço.
Três configurações de roteamento que funcionam na prática
A melhor configuração depende de você priorizar velocidade sem intervenção, limites rígidos de custo ou comportamento determinístico. Todas usam o mesmo objeto provider: provider.order ignora a nova lógica e tenta os provedores na ordem exata; provider.only e provider.ignore filtram os candidatos, e o novo algoritmo escolhe entre os restantes; qualquer provider.sort explícito — price, throughput ou latency — o substitui.
1. Fique no novo padrão para chat interativo e agentes
Nenhuma mudança de código é necessária. Essa opção serve para chats voltados ao usuário e agentes de várias etapas, nos quais cada chamada de ferramenta espera pelo primeiro token. Aceite o custo cerca de 6% maior como orçamento de latência e retries. Durante uma semana, registre o provedor que atendeu a requisição — retornado na resposta da API e na página de atividade — junto com TTFT p50 e taxa de 429. Se sua parcela de 429 continuar próxima da nova base de cerca de 4% e a taxa de acerto de cache se mantiver, continue. Se um provedor concentrar as falhas ou os acertos de cache despencarem, passe à configuração 3.
2. Trave o caminho mais barato para lotes e trabalho com teto de custo
Há três formas de priorizar roteamento por preço quando o custo vale mais que a velocidade:
{ "provider": { "sort": "price" } }Você também pode acrescentar :floor ao slug do modelo — meta-llama/llama-4-maverick:floor — ou definir a ordenação padrão da conta como preço, conforme o FAQ do anúncio. Vale notar que :floor também aceita endpoints flex-tier, algo que o sort simples não faz, segundo o guia de roteamento do OpenRouter.
Combine com um teto:
{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }Use em prompts longos, saídas curtas e retries baratos.
3. Fixe um provedor estável para produção com cache ou tool calls
Fixe o provedor quando correção, acertos de cache ou compliance importarem mais que a otimização por requisição:
{
"provider": {
"order": ["deepinfra", "together"],
"allow_fallbacks": true,
"require_parameters": true
}
}require_parameters apenas evita endpoints sem os parâmetros obrigatórios da requisição; não garante comportamento idêntico de tool calls ou schemas entre provedores. Reserve order com allow_fallbacks: false para casos de compliance ou BYOK, em que uma indisponibilidade é preferível a usar um provedor não aprovado. Para a maioria dos apps, permita fallbacks, restrinja com only/ignore e envie um session_id estável para reutilizar o cache quente (roteamento sticky). Se um provedor for instável, bloqueie-o nas guardrails e compare as APIs diretas dos provedores. Vários usuários relatam que ir direto ao provedor eliminou lentidão e problemas de cache depois que o modelo foi definido (discussão de exemplo).
| Se você está... | Use | Motivo |
|---|---|---|
| Prototipando, com tráfego misto | Novo padrão, sem configuração | Menos retries nos testes |
| Usando um agente voltado ao usuário | Novo padrão + require_parameters | Mantém os ganhos de TTFT e evita endpoints incompatíveis |
| Executando lote noturno, 100M+ tokens | sort: price ou :floor + max_price | Recupera o adicional de 6-7% |
| Usando contexto longo com cache | order fixada + session_id | Evita a reprecificação por cache perdido |
O roteamento automático está melhor do que antes. Ainda assim, ele não substitui fixar um provedor quando uma única troca ruim custa mais do que uma semana de preços por token um pouco maiores.
Perguntas frequentes
Preciso mudar meu código para usar o novo roteamento?
Não. Requisições sem sort, order, only ou ignore explícitos de provedor usam o novo roteador automaticamente.
Como mantenho o roteamento apenas por preço?
Defina provider.sort como "price", acrescente :floor ou configure a ordenação padrão da conta como preço.
O novo roteamento substitui minha ordem de provedores?
Não. order o ignora; only/ignore filtram primeiro, e o novo algoritmo escolhe em seguida.
O novo roteamento vai custar mais?
Veja a tabela de resumo: +6,0% por 1 mil requisições e +7,3% por M tokens nos testes.
Como vejo qual provedor realmente atendeu minha requisição?
Consulte o campo provider da resposta da API e a página de atividade, conforme a documentação do OpenRouter.
Por que ainda recebo 429 em uma conta paga?
Por limites do pool compartilhado upstream, não por seu saldo. Fixe ou ignore o provedor com rate limit.