API Fusion do OpenRouter

• Parte da constatação de que sintetizar os resultados de vários modelos pode superar com folga o desempenho de qualquer modelo isolado
• Usa deliberação multi-modelo: vários modelos especialistas analisam um único prompt em paralelo, e um modelo juiz (judge model) sintetiza os resultados para produzir a resposta final
• Os modelos do painel executam análise paralela com pesquisa na web e web fetch ativados, enquanto o modelo juiz organiza a análise em consenso, contradições, concordância parcial, insights únicos e pontos cegos
• O padrão é o preset Quality, mas é possível trocar para o preset Budget para usar modelos mais baratos ou redefinir completamente painel e juiz pelos campos do plugin fusion
• Indicado para pesquisa, crítica especializada e situações em que o custo de uma resposta errada supera o custo adicional de geração
• Como executa todos os membros do painel e também a chamada do juiz, o custo da requisição é cobrado pela soma das completions individuais, não como um único modelo

---

Como funciona

• Converte um único prompt em uma pequena deliberação multi-modelo
  • Um painel de modelos especialistas analisa o prompt em paralelo com web search e web fetch ativados
  • O modelo juiz sintetiza as respostas do painel e gera uma análise estruturada em consenso, contradições, cobertura parcial, insights únicos e pontos cegos
  • Com base nessa análise estruturada, o modelo juiz escreve a resposta final

Composição e configuração do painel

• O painel padrão usa o preset Quality
  • Se quiser membros mais baratos, é possível mudar para o preset Budget
  • Os campos analysis_models e model do plugin fusion permitem sobrescrever completamente o painel e o juiz
• Recomendado quando um único modelo não é suficiente
  • Adequado para pesquisa, crítica especializada ou áreas em que o custo de uma resposta errada supera o custo adicional de geração

Preços e limitações

• Como executa todos os membros do painel e também a chamada do juiz, o custo da requisição é calculado pela soma das completions individuais, não por um modelo único
  • É possível verificar quais modelos foram realmente executados na página Activity
• O limite de contexto varia conforme os modelos escolhidos

Os presets usam 6 modelos

• Maior qualidade: Claude Opus, OpenAI GPT, Google Gemini Pro
• Menor custo: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

---

Anúncio relacionado: "Superando o desempenho de frontier com Fusion"

• Uma ferramenta que sintetiza os resultados de vários modelos para superar o desempenho de modelos individuais, permitindo escolher diretamente um painel de modelos participantes e um modelo judge que funde os resultados, com chamada como se fosse um único modelo
• Em medições com 100 tarefas de deep research do benchmark DRACO, o painel superou os modelos individuais de forma consistente
  • A fusão de Fable 5 + GPT-5.5 alcançou 69.0%, superando todos os modelos individuais, incluindo o Fable 5 sozinho (65.3%)
  • Um painel de baixo custo (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) chegou a menos de 1% da pontuação do Fable 5 com 50% do custo, superando GPT-5.5 e Opus 4.8
• O prompt é enviado em paralelo aos modelos do painel, e o judge analisa pontos de consenso, contradições, insights únicos e pontos cegos; com isso, o modelo chamado produz a resposta final
• Todo o pipeline roda server-side, permitindo uso da mesma forma que chamadas de modelo individuais
• Mesmo ao fundir o Opus 4.8 com ele próprio, o resultado chegou a 65.5%, alta de 6.7 pontos frente ao uso isolado (58.8%), confirmando o efeito da etapa de synthesis em si
• Foi identificado um risco de contaminação quando os modelos do painel encontravam online a rubrica de avaliação; isso foi bloqueado com uma configuração de uma linha para exclusão em web search e web fetch
• Há 4 formas de uso: Chatroom (sem necessidade de código), Model slug (troca de string), Server tool (controle máximo), Plugin (definição do painel)
• Não é um substituto drop-in para o Fable; tarefas de long-horizon em que o Fable se destaca não foram incluídas, e em programação pode ser usado como ferramenta de chamada seletiva

[GN⁺]

Comentários do Hacker News

• Há alguns meses, tentei criar o Fusion com um MCP usando o OpenRouter. A ideia era oferecer um “painel de especialistas” para consultar quando o Claude travasse
  Depois de muitos testes e benchmarks, descobri que fazer um modelo avaliar a resposta de outro na prática não produzia respostas melhores. No fim, isso equivale a perguntar “o quanto esta resposta se parece com a que você teria dado”, e rodadas extras ou soluções “óbvias” que surgem na hora eram, na prática, parecidas com aumentar a temperatura. Encontrei uma solução, mas o custo era absurdamente alto. Se essa abordagem receber mais atenção, talvez eu publique a minha também

  • O prompt é importante. Se você quer a opinião de outros modelos, naturalmente precisa fazer com que eles gerem desde o começo com o mesmo prompt e depois sintetizar; se quiser, também dá para fazê-los trabalhar sobre respostas já existentes
    Eu peço explicitamente para encontrarem problemas por nível de gravidade, passo esses problemas por um painel de modelos julgadores e só faço corrigir a resposta original aquilo que passa de um certo limiar. A grande melhoria veio quando pedi ao modelo julgador para avaliar separadamente os eixos de veracidade e de “utilidade/precisa ser corrigido”. Isso porque, ao forçar a busca por problemas, inevitavelmente aparece implicância com detalhes triviais, e o eixo de veracidade também foi melhor para avaliar modelos de detecção de problemas adequados ao meu caso de uso. Isso é aplicado em parte ao gerar explicações como esta: https://hanzirama.com/character/%E6%9D%A5#explain — hoje esse site virou um pequeno subproduto do meu sistema de avaliação de LLM. Se você precisa da melhor qualidade, provavelmente vai ter que fixar o provedor no OpenRouter. Só :exacto dificulta obter bons resultados reproduzíveis, especialmente com modelos de pesos abertos
  • Já vi o modelo julgador dissecar a resposta com muita crueldade quando eu dizia que ela vinha de um LLM local pequeno e fraco. Mas não fiz isso de forma sistemática, então não sei se dá para generalizar além da minha impressão
    Queria saber se mais alguém já sentiu que, quando se engana um LLM para ele entrar num modo em que “se sente superior”, ele pode ficar bem maldoso
  • Fiz uma versão rudimentar dessa ideia em 2024[0], e ainda acho interessante ver esse conceito continuar aparecendo. Dava para definir um limiar de qualidade, mas isso não parecia fazer muita diferença, e os modelos de ponta quase sempre concordavam entre si e davam notas altas para as respostas
    O cenário mudou completamente em relação a dois anos atrás, então vale a pena revisitar isso. [0] https://github.com/Ceroxylon/konsensis
  • Acho que isso depende de a resposta ser verificável ou não
    Testei dois modelos julgadores no meu app. O primeiro era um julgador para um modelo de adaptação de currículo: ele comparava o currículo final com o currículo original e com a vaga, avaliando adequação e honestidade numa escala de 10 pontos, e funcionou bem, sendo útil. O segundo era um modelo de revisão numa plataforma de bot de trading com LLM, revisando as decisões do modelo principal. Aqui, como o bot lida com ambiguidade, isso pode até atrapalhar, a menos que detecte erros óbvios, como julgar com um preço de candle errado ou dar BUY quando deveria ser SELL. Primeiro, isso adiciona atraso à decisão: no Gemma 4 31B, 30 segundos viram algo como 60 segundos, o dobro. Além disso, como o modelo de revisão roda só para decisões de BUY/SELL e não para HOLD, por causa do atraso e do custo o bot pode acabar ficando excessivamente cauteloso, em vez de aumentar o número de operações. Por isso, se a resposta não puder ser verificada com facilidade, acho melhor usar de uma vez um modelo melhor do que recorrer a um modelo de revisão. Nesse caso, também fica pouco claro por que o modelo julgador seria necessário e por que não deixar o próprio agente se revisar. Além disso, quando se lê o texto de raciocínio de modelos de raciocínio como o Gemma 4, dá para ver que eles já estão se revisando. Ou seja, já estão fazendo o melhor que podem, então uma nova revisão não acrescenta tanta informação. É um experimento interessante, mas precisa ser avaliado caso a caso
  • Tive a mesma experiência. Encontrar uma resposta objetivamente melhor foi bem mais difícil do que eu esperava, além de ser caro e lento

• Eu tinha um prompt que usava assim, só com o Claude Code
  Vamos revisar um problema de arquitetura. Suba 10 agentes, faça cada um criar uma persona, depois revisar _api.go e escrever a revisão em reviews/-review.md. Faça cada agente ler o resumo no início de cada revisão, responder em round-robin a 3 revisões que quiserem e escrever em response/--response.md. Depois, escreva uma contestação às respostas em rebuttals/-rebuttal.md. Por fim, faça cada agente subir de novo um agente para revisar sua própria revisão, resposta e contestação, e organizar o resultado em findings/-findings.md. No fim, outro agente reúne os resultados e escreve em review-findings.md, apresentando ali uma versão concisa. Isso funcionou bem tanto em modelos de ponta quanto em modelos hospedados localmente. A última vez que usei foi com o Qwen 3.5

  • Não tenho muita familiaridade com usar vários agentes em um mesmo fluxo, então fiquei com algumas dúvidas
    Você revisa todos os arquivos gerados para verificar se não há alucinações, ou olha só o arquivo final com o resultado conciso? Também queria saber se a ideia é que, ao passar por vários agentes, as alucinações acabem se anulando e no fim reste apenas a verdade. Queria saber também se você já viu conteúdo gravemente errado na versão final. Eu me preocuparia com o custo, mas usando modelos hospedados localmente isso deve pesar menos. Ainda assim, modelos hospedados localmente não continuam tendo problemas com execução de comandos locais ou acesso à internet? Se for esse o caso, fiquei curioso se isso roda só com o contexto daquele arquivo, sem consultar o restante do projeto
  • Parece haver bastante aparato em comparação com simplesmente rodar a mesma revisão n vezes e combinar os resultados. Fiquei curioso sobre por que você acabou chegando a esse desenho

• O contexto de fundo está aqui: Surpassing Frontier Performance with Fusion
  https://news.ycombinator.com/item?id=48525392
  O lugar com uma UI um pouco melhor é https://openrouter.ai/fusion. A Fusion API da OpenRouter envia a solicitação para vários modelos ao mesmo tempo, e um modelo avaliador combina as respostas para criar a resposta final. Dizem que isso aumenta bastante o desempenho em troca de mais tempo. Pelo menos foi assim no benchmark de deep research que eles testaram. O preset Budget é composto por 3 modelos mais baratos e, nesse benchmark, fica mais ou menos no nível do Fable custando metade. O preset Quality é composto por 3 modelos caros, supera o Fable, mas custa o dobro. Gráfico de Pareto: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost.... Curiosamente, até fundir o mesmo modelo com ele próprio melhorou o desempenho. 2xOpus4.8 fica mais ou menos no nível do Fable no benchmark, mas custa o dobro. Misturar modelos diferentes traz um ganho adicional pequeno. O principal ganho parece vir de compute em tempo de teste adicional. Seria bom ver mais pesquisa focada em modelos recentes e baratos, por exemplo casos de fundir o DSV4 com ele mesmo ou com o Mimo, e também ver o trade-off entre fusão como compute paralelo em tempo de teste e aumentar a quantidade de raciocínio ou o número de turnos

  • “Até fundir o mesmo modelo com ele próprio melhorou o desempenho” era uma abordagem bem comum na época da transição de GPT-2 para GPT-3
    Isso é basicamente tirar mais amostras do espaço de saídas possível. Se um modelo consegue realizar alguma tarefa com 60% de probabilidade, você pode tirar 5–10 amostras e implementar algo como voto da maioria. Isso passou a ser menos usado à medida que a precisão dos modelos aumentou em problemas em que combinar resultados é fácil, mas com avaliadores mais complexos, isto é, LLMs competentes, ainda dá para melhorar o desempenho só amostrando mais o espaço de saídas e escolhendo as partes boas
  • É interessante que o painel Fable 5 + GPT 5.5 supere com folga o desempenho de ponta de qualquer um dos dois isoladamente, mas, ao misturar Gemini, o painel de três modelos não melhora e na verdade piora
    Para mim isso sugere que o Gemini é mais fraco nessa tarefa, mas melhor em convencer o modelo avaliador da própria solução. E o fato de o painel com dois Opus 4.8 ficar quase exatamente no mesmo nível de um único Fable 5 também tem um cheiro suspeito. Será que dá para saber se a Anthropic já não está fazendo algo assim nos bastidores?
  • É uma pena que quase não tenham tratado de quanto mais tempo isso leva por causa da etapa de síntese. No benchmark de deep research isso pode não importar muito, mas fico curioso sobre como isso se aplicaria a tarefas de programação
  • Não sei se isso ainda vale para os modelos atuais, mas em uma pesquisa da Microsoft de algumas gerações atrás houve o resultado de que fazer o modelo repetir N vezes melhorava bastante o desempenho, e que o ponto ótimo era 4 repetições

• Rodei uma avaliação rápida para ver como isso difere qualitativamente de chamar diretamente o Opus 4.7 ou o GPT 5.5
  Como esperado, o Fusion foi 7x mais lento e 4x mais caro. Não digo isso como crítica; vejo o Fusion como algo da categoria “usar só quando precisar”. https://3fpi5avcqq.evvl.io/

  • Fusion realmente parece muito bom como alvo para destilação
  • Valeu por compartilhar. Minha maior preocupação era a velocidade, e eles não mencionaram isso
  • Fico curioso sobre quais modelos foram usados por baixo. Se você usou o padrão Quality da interface, faz sentido dar algo como 4x o custo, já que a estrutura é 3 modelos de ponta com um deles julgando
    A ideia principal provavelmente é usar Fusion com modelos mais simples e baratos
  • Acho isso bem contraintuitivo. Provavelmente não vai ser fácil encontrar o enquadramento e a estrutura certos para isso funcionar bem. Os modelos realmente odeiam cooperar
    Fico curioso para ver como a versão deles se sustenta em uso real

• Pensei bastante nesse problema e, simplificando para entender, vejo cada modelo como uma distribuição em forma de sino sobre o conhecimento humano, e cada modelo tem uma distribuição diferente
  Ao usar vários modelos, dá para alterar a distribuição de outro modelo com texto que estaria fora da curva original. Mas, pensando de novo, fico em dúvida se SFP e aprendizado por reforço já não alteram tanto a distribuição original de texto que as saídas combinadas dos modelos deixam de ser suficientemente diversas para formar algo melhor, virando só uma câmara de eco. Ainda não há como provar, mas eu acredito que não

• Como resultado anedótico sobre Fusion, rodei na OpenRouter Fusion a mesma consulta que usei no Fable e o resultado foi pior
  O Fable parecia captar alguma camada bem profunda de conhecimento/inteligência e, em vez de apenas dar uma resposta plausível, sugeria prioridades entre os itens a resolver e até propunha descartar alguns deles, o que me pareceu bem razoável. Já o Fusion pareceu uma versão um pouco mais variada do mesmo tipo de resposta que os modelos topo de linha anteriores ao Fable dariam e, nos testes bem limitados que fiz quando tive acesso ao Fable, ele não alcançou a mesma profundidade que o Fable alcançava

• No fim de semana, inspirado pelo novo modelo Fusion da OpenRouter, trabalhei para ver se dava para rodar isso no Claude Code e se eu poderia tornar fácil para outras pessoas testarem também
  O que eu fiz foi o claude-fusion-launcher — ele executa o Claude Code sobre um painel de modelos em vez de um modelo único. Também mostra o custo. https://github.com/smorinlabs/claude-fusion-launcher

  • Isso não fica caro muito rápido? Os prompts avulsos que testei no site custaram quase US$ 1 por prompt

• Fico me perguntando se regenerar o mesmo prompt várias vezes com o mesmo modelo, em temperatura mais alta, seria equivalente a rodar modelos diferentes
  Suspeito que boa parte da variabilidade percebida entre diferentes modelos de ponta venha da aleatoriedade de usar temperatura diferente de zero. Parece que os modelos foram treinados para devolver quantidades “bonitinhas” e redondas de itens, como 5, 10, 15. Talvez isso também venha de interferência do treinamento em material de marketing. Além disso, a taxa de recordação em contextos grandes está longe de 100%. Então, se houver 27 bugs no código, seja usando vários modelos diferentes ou chamando repetidamente o mesmo modelo, em cada execução você pode acabar encontrando 10 problemas diferentes entre esses 27

• Tenho curiosidade se existe pesquisa formal nessa área. Também tentei variações dessa abordagem, mas não consigo dizer com confiança que os resultados foram melhores.
  Fico me perguntando se isso é parecido com perguntar a 2 ou 3 consultores qual é a melhor estratégia para o negócio. Não sei se combinar as respostas realmente produz algo substancialmente melhor.

• Também lancei no meu TrustedRouter uma funcionalidade parecida em código aberto, com criptografia de ponta a ponta: https://trustedrouter.com/

  • É bom ver uma promessa real de privacidade. Tenho gastado muito tempo lendo sem parar termos de provedores evasivos e vagos.