Preços do OpenRouter Fusion: tamanho do painel e custo por token

Uma requisição do Fusion pode parecer gratuita na página do modelo do OpenRouter, mas custar várias vezes mais do que uma conclusão normal. O motivo é direto: o preço do OpenRouter Fusion é a soma de várias chamadas aos modelos envolvidos, e não uma tarifa independente por token. O tamanho do painel e o volume de tokens é que determinam se essa camada extra de análise vale o investimento.

OpenRouter Fusion: o que pesa na decisão

Em geral, o OpenRouter Fusion sai mais caro do que chamar uma única vez um modelo comparável. A documentação do Fusion Router no OpenRouter descreve um painel padrão com três modelos e uma chamada para o analista — algo em torno de 4 a 5 vezes o custo de uma conclusão única usando o mesmo prompt.

Um painel econômico pode superar um modelo premium quando a qualidade reduz o trabalho de revisão. Ainda assim, o Fusion é uma escolha entre custo e verificação, não um atalho automaticamente mais barato.

A unidade de cobrança é uma pilha de chamadas, não um token do Fusion

A página da API do Fusion no OpenRouter apresenta o Fusion como um roteador e exibe preço zero para prompt e conclusão no alias do roteador. Isso quer dizer que o Fusion não tem uma tarifa própria e independente; não significa que a inferência por trás dele seja gratuita.

O fluxo documentado é este:

1. O prompt é enviado a cada modelo selecionado no painel.
2. As respostas do painel são comparadas por um modelo analista ou juiz.
3. O modelo externo produz a resposta final.

Para montar o orçamento, use esta equação:

Fusion cost = sum(panel model costs)
             + analyst/judge cost
             + any final outer-model cost shown for your integration

A forma exata de contabilização depende de o Fusion ser chamado como o alias de modelo openrouter/fusion ou como a ferramenta de servidor openrouter:fusion. Não tente deduzir a fatura final a partir da linha $0 exibida pelo roteador. Confira a geração efetiva e o registro correspondente no OpenRouter Activity.

A documentação do OpenRouter oferece suporte a 1 a 8 modelos de análise. O painel padrão tem três. Como existem configurações Quality, Budget e personalizadas, não há um preço universal do Fusion por milhão de tokens.

O tamanho do painel aumenta a conta de forma linear — até o juiz entrar na equação

Se todos os modelos do painel receberem o mesmo prompt e gerarem aproximadamente a mesma quantidade de texto, adicionar um integrante significa, na prática, acrescentar mais uma chamada de modelo. O próprio OpenRouter afirma que o custo cresce linearmente com o tamanho do painel.

Mas contar chamadas subestima o custo do juiz, porque a entrada dele aumenta conforme crescem as respostas do painel:

C(n) = n × Cp + Cj(n) + Co

Aqui, n é o número de modelos no painel, Cp é o custo médio da resposta de cada modelo do painel, Cj(n) é o custo do juiz, incluindo a entrada crescente, e Co é o custo da resposta externa quando aplicável.

Por isso, a estimativa de 4 a 5 vezes o custo de uma conclusão única com o painel padrão de três modelos é uma referência de planejamento mais útil do que o $0 mostrado pelo roteador. O multiplicador pode subir quando o juiz é caro, as respostas são longas ou o modelo externo acrescenta outra conclusão paga.

Exemplo prático com tarifas editáveis

Use esta planilha com as tarifas atuais dos modelos escolhidos. Os valores são apenas ilustrativos, não preços do OpenRouter: considere 10.000 tokens de entrada, 2.000 tokens de saída por resposta do painel, 6.000 tokens de entrada para o juiz e 1.000 tokens de saída do juiz.

Panel input  = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input  = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output

Se a referência de um único modelo processar os mesmos 10.000 tokens de entrada e 2.000 de saída, compare diretamente o total dela com o resultado desta planilha. Num painel com três modelos, o prompt é cobrado três vezes, e o juiz lê um contexto separado de 6.000 tokens neste exemplo. Ajuste as premissas quando seus prompts ou respostas forem mais longos.

Em uma hipótese simplificada de custos iguais, o formato da conta conforme o número de chamadas é:

Esses números não são preços do OpenRouter. Eles mostram por que o número de modelos no painel importa mesmo antes de comparar tarifas diferentes. Um juiz caro pode dominar o custo de um painel barato; por outro lado, modelos de fronteira no painel podem custar mais do que o juiz.

O uso de tokens muda a comparação de duas formas

O consumo de tokens afeta mais o Fusion do que uma chamada única porque o prompt é processado repetidamente, enquanto o juiz também recebe as respostas geradas pelo painel.

1. Os tokens de entrada são repetidos em todo o painel

Considere I como o número de tokens do prompt e Pi como o preço de entrada do modelo de painel i:

Panel input cost = I × (P1 + P2 + ... + Pn)

Um prompt de 10.000 tokens enviado a três modelos do painel gera três cobranças de entrada diferentes, potencialmente com três tarifas distintas.

2. Os tokens de saída também se multiplicam

Se cada modelo do painel gerar O tokens de saída, o painel produzirá aproximadamente n × O tokens. Tokens de raciocínio cobrados podem ampliar ainda mais a diferença em relação ao tamanho visível da resposta.

Depois, o juiz lê essas respostas:

Judge input ≈ original prompt + n × panel output + orchestration overhead

Uma resposta mais longa pode, portanto, elevar o custo tanto em cada resposta do painel quanto no contexto de entrada do juiz.

Uma estimativa mensal útil é:

Total monthly cost ≈ requests × (panel input + panel output
                                  + judge input + judge output
                                  + outer response)

Use as tarifas atuais dos IDs concretos de modelo presentes no seu painel. “Budget” é o nome de uma configuração predefinida, não uma garantia de que o custo total será menor do que o de qualquer modelo único.

Budget, Quality ou um único modelo?

Prefira um único modelo quando velocidade, consistência e cobrança previsível forem mais importantes do que uma revisão independente. É uma escolha adequada para formatação, extração, preenchimento automático, reescritas rotineiras e muitos prompts comuns de programação.

Escolha o Fusion quando deixar passar um problema sair caro: pesquisas baseadas em fontes, críticas especializadas, due diligence ou decisões com evidências conflitantes. Comece pelo menor painel capaz de responder à pergunta. Três modelos são o padrão documentado; oito é o máximo, não uma recomendação.

A comparação relevante é:

incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposure

O anúncio separado de benchmark do OpenRouter relata uma avaliação DRACO com 100 tarefas, incluindo um resultado de 69,0% para uma configuração Fusion de fronteira e 64,7% para um painel econômico. Esses números apontam para um caso de uso em pesquisas aprofundadas, mas não representam uma taxa de conversão para todo tipo de prompt nem provam que um painel maior seja mais econômico.

Audite o número antes de escalar

Trate a primeira implementação do Fusion como um exercício de medição. Registre:

1. Os IDs dos modelos do painel e do modelo juiz.
2. O uso de tokens de entrada, saída e raciocínio, quando essas informações estiverem disponíveis.
3. Os metadados do roteador que confirmam se o Fusion foi executado.
4. O custo total e a latência.
5. Se a resposta final reduziu a quantidade de correções humanas.

A documentação do Fusion informa que os metadados da geração podem incluir "router": "openrouter/fusion". O campo comum model identifica o modelo concreto que processou a requisição, mas não é suficiente para provar que o Fusion foi executado.

Um relato de usuário ilustra o risco de configuração:

“this \"Fusion\" still calls Opus 4.8 as a judge. I see no way to disable it.” — @teortaxesTex on X

Esse é um relato de usuário, não uma regra de preços do OpenRouter. Ele mostra por que um painel de baixo custo não garante uma execução barata se o juiz for caro ou se a configuração não for exatamente a esperada.

Em produção, fixe o painel e o juiz quando a API permitir, estabeleça limites de orçamento e transforme o Fusion em uma rota explícita de escalonamento, em vez de disponibilizá-lo para toda requisição autônoma.

FAQ sobre os preços do OpenRouter Fusion

O Fusion é mais barato do que usar um modelo?

Normalmente, não quando a comparação é feita com um modelo único de preço semelhante. Ele pode custar menos do que um modelo premium quando um painel econômico entrega qualidade suficiente, mas o resultado depende das tarifas do painel, do custo do juiz e do uso de tokens.

O OpenRouter Fusion é gratuito?

O alias do roteador pode exibir $0 nos campos próprios de prompt e conclusão. O OpenRouter afirma separadamente que as conclusões dos modelos do painel e do juiz são cobradas. Portanto, não se deve presumir que uma requisição normal do Fusion custe zero.

Quantas chamadas uma requisição do Fusion faz?

O processo documentado usa N chamadas aos modelos do painel mais uma chamada do analista, enquanto a resposta externa final depende da integração. A configuração padrão com três modelos no painel é descrita como custando aproximadamente 4 a 5 vezes uma conclusão comparável.

Um painel maior sempre entrega melhor custo-benefício?

Não. Mais modelos podem ampliar a cobertura, mas também aumentam as cobranças do painel, a entrada do juiz, a latência e os erros correlacionados. Só aumente o painel quando testes com dados de validação mostrarem que o ganho de qualidade compensa o custo adicional.

Como estimar o custo do OpenRouter Fusion?

Liste todas as chamadas aos modelos envolvidos, multiplique as tarifas atuais de entrada e saída pelos tokens esperados, inclua a entrada do juiz contendo as respostas do painel e valide o resultado em Activity após uma requisição real. Uma calculadora de terceiros pode ajudar a simular cenários, mas as tarifas atuais do OpenRouter e o registro no Activity são a referência definitiva.

A decisão prática

Use um único modelo como ponto de comparação. Execute um conjunto de validação com 20 a 50 prompts usando esse modelo e um painel pequeno do Fusion. Mantenha o Fusion somente se a redução de correções factuais, de evidências ignoradas ou de horas de revisão compensar os tokens adicionais do painel e do juiz.

Para a maioria das equipes, a implantação mais consciente dos custos é um modelo para o tráfego rotineiro, Fusion com painel pequeno para decisões incertas ou de alto custo e painéis maiores somente quando o ganho medido justificar a conta.