API de OpenRouter Fusion

• Parte del hallazgo de que sintetizar los resultados de varios modelos puede superar ampliamente el rendimiento de un modelo individual por sí solo
• Un enfoque de deliberación multimodelo en el que varios modelos expertos analizan en paralelo un solo prompt y luego un modelo juez (judge model) sintetiza los resultados para redactar la respuesta final
• Los modelos del panel realizan análisis en paralelo con búsqueda web y web fetch activados, y el modelo juez los organiza en un análisis estructurado de consenso, contradicciones, coincidencias parciales, insights únicos y puntos ciegos
• El valor predeterminado es el preset Quality; se puede cambiar a un preset Budget con modelos más baratos o redefinir por completo el panel y el juez con los campos del plugin fusion
• Adecuado para investigación y crítica experta cuando un solo modelo no basta, o en situaciones donde el costo de una respuesta errónea supera el costo adicional de completado
• Como se ejecutan todos los miembros del panel y también la llamada al juez, el costo de la solicitud no se calcula como un solo modelo sino como la suma de completions individuales

---

Cómo funciona

• Convierte un solo prompt en una pequeña deliberación multimodelo
  • Un panel de modelos expertos analiza el prompt en paralelo con web search y web fetch activados
  • El modelo juez sintetiza las respuestas del panel y genera un análisis estructurado en consenso, contradicciones, cobertura parcial, insights únicos y puntos ciegos
  • Con base en ese análisis estructurado, el modelo juez redacta la respuesta final

Configuración y ajustes del panel

• El panel predeterminado usa el preset Quality
  • Si se quieren integrantes más baratos, se puede cambiar al preset Budget
  • Los campos analysis_models y model del plugin fusion permiten redefinir (override) por completo el panel y el juez
• Se recomienda usarlo cuando un solo modelo no es suficiente
  • Adecuado para investigación, crítica experta, o para áreas donde el costo de una respuesta incorrecta supera el costo adicional de completado

Precio y limitaciones

• Como se ejecutan todos los miembros del panel y también la llamada al juez, el costo de la solicitud se cobra como la suma de completions individuales, no como un solo modelo
  • Los modelos realmente ejecutados pueden verificarse en la página de Activity
• El límite de contexto depende de los modelos seleccionados

Los presets usan 6 modelos

• Máxima calidad: Claude Opus, OpenAI GPT, Google Gemini Pro
• Menor costo: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

---

Anuncio relacionado: "Superando el rendimiento frontier con Fusion"

• Una herramienta que sintetiza los resultados de varios modelos para superar el rendimiento de cualquier modelo individual, permitiendo elegir directamente un panel de modelos participantes y un modelo judge que fusiona los resultados, y llamarlo como si fuera un solo modelo
• En la medición de 100 tareas de investigación profunda del benchmark DRACO, el panel superó de forma consistente a los modelos individuales
  • La fusión de Fable 5 + GPT-5.5 logró 69.0%, superando a todos los modelos individuales, incluido Fable 5 por sí solo (65.3%)
  • Un panel económico (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) se acercó a menos de 1% de la puntuación de Fable 5 con 50% del costo, y superó a GPT-5.5 y Opus 4.8
• El prompt se envía en paralelo a los modelos del panel; el judge analiza consensos, contradicciones, insights únicos y puntos ciegos, y el modelo invocado redacta la respuesta final con base en ello
• Todo el pipeline se ejecuta del lado del servidor (server-side), por lo que puede usarse igual que una llamada individual a un modelo
• Incluso al fusionar Opus 4.8 consigo mismo, obtuvo 65.5% frente a 58.8% por sí solo, una mejora de 6.7 puntos que confirma el efecto de la etapa de síntesis
• Se detectó un riesgo de contaminación cuando los modelos del panel encontraban en línea la rúbrica de evaluación; esto se bloqueó aplicando en una sola línea una lista de exclusión para web search y web fetch
• Hay 4 formas de uso: Chatroom (sin código), Model slug (reemplazo de cadena), Server tool (máximo nivel de control) y Plugin (especificación del panel)
• No es un reemplazo directo de Fable; no incluye las tareas de largo horizonte donde Fable destaca, y en programación se usa como herramienta de invocación selectiva

[GN⁺]

Comentarios de Hacker News

• Hace unos meses probé hacer Fusion con un MCP que usa OpenRouter. La idea era ofrecer un “panel de expertos” al que recurrir cuando Claude se quedaba bloqueado
  Después de muchas pruebas y benchmarks, vi que hacer que un modelo evalúe la respuesta de otro no daba realmente una mejor respuesta. Al final, es básicamente preguntarle “¿qué tan parecida es esta respuesta a la que tú habrías dado?”, y las rondas extra o las soluciones “obvias” que aparecen son, en la práctica, parecidas a subir la temperatura. Encontré una solución, pero el costo era absurdamente caro. Si este enfoque recibe más atención, quizá publique también lo mío

  • El prompt importa. Si quieres la opinión de otros modelos, lo lógico es hacer que generen desde el principio con el mismo prompt y luego sintetizar, aunque si quieres también se puede trabajar sobre una respuesta ya existente
    Yo les pido explícitamente que encuentren problemas por nivel de gravedad, luego paso esos problemas por un panel de modelos jueces y solo hago que corrijan la respuesta original si superan cierto umbral. Un hallazgo que mejoró mucho los resultados fue pedirles a los modelos jueces que evalúen por separado veracidad y el eje de “utilidad / si debe corregirse”. Si los fuerzas a encontrar problemas, al final aparecen críticas menores sin importancia, y el eje de veracidad también resultó mejor para evaluar modelos de detección de problemas adecuados a mi caso de uso. Esto se aplica en parte al generar explicaciones como esta: https://hanzirama.com/character/%E6%9D%A5#explain — ahora este sitio se volvió un pequeño subproducto lateral de mi sistema de evaluación de LLM. Si necesitas la máxima calidad, probablemente tengas que fijar el proveedor en OpenRouter. Solo con :exacto es difícil obtener resultados buenos y repetibles, especialmente con modelos de pesos abiertos
  • He visto que si le dices al modelo juez que la respuesta vino de un LLM local pequeño y débil, la destroza con mucha más severidad. Pero no lo hice de forma sistemática, así que no sé si eso se puede generalizar más allá de mi impresión
    Me da curiosidad si alguien más ha sentido que, si logras engañar a un LLM para que entre en modo “me siento superior”, puede portarse bastante mal
  • Hice una versión rudimentaria de esta idea en 2024[0], y sigue siendo interesante ver que el concepto continúa. Se podía configurar un umbral de calidad, pero no parecía cambiar mucho, y los modelos de frontera casi siempre estaban de acuerdo entre sí y daban puntuaciones altas a las respuestas
    El panorama cambió por completo respecto a hace dos años, así que vale la pena revisarlo de nuevo. [0] https://github.com/Ceroxylon/konsensis
  • Creo que depende de si la respuesta es verificable
    Probé dos modelos jueces en mi app. El primero era un modelo juez para un modelo de adaptación de currículums: comparaba el currículum resultante con el currículum original y con la oferta laboral, y calificaba compatibilidad y honestidad sobre 10; funcionó bien y fue útil. El segundo era un modelo de revisión para una plataforma de bots de trading con LLM, que revisaba las decisiones del modelo principal. Aquí, como el bot maneja ambigüedad, puede incluso ser perjudicial, salvo que detecte errores obvios como decidir con precios de velas incorrectos o marcar BUY cuando debería ser SELL. Primero, añade retraso en la decisión: con Gemma 4 31B, por ejemplo, 30 segundos pasan a ser 60. Además, como el modelo de revisión solo corre para decisiones BUY/SELL y no para HOLD, por el retraso y el costo el bot puede volverse demasiado cauteloso en vez de aumentar la cantidad de operaciones. Así que, si la respuesta no se puede verificar fácilmente, me parece mejor resolverlo de una sola vez con un modelo mejor que usar un modelo revisor. En ese caso, tampoco queda claro por qué se necesitaría un modelo juez ni por qué no dejar que el mismo agente se revise a sí mismo. Además, si lees el texto de razonamiento de modelos de razonamiento como Gemma 4, ya se están revisando solos. En cierto sentido ya están haciendo su mejor esfuerzo, así que una revisión extra no añade mucha información. Es un experimento interesante, pero hay que evaluarlo caso por caso
  • Mi experiencia fue la misma. Encontrar una respuesta objetivamente mejor fue más difícil de lo que parece, y además costaba dinero y era lento

• Hubo un tiempo en que usaba un prompt así solo con Claude Code
  Revisemos un problema de arquitectura. Lanza 10 agentes y haz que cada uno cree una persona, luego que revise _api.go y escriba su revisión en reviews/-review.md. Haz que cada agente vea el resumen al inicio de cada revisión y responda a 3 revisiones de su elección en round-robin, escribiendo en response/--response.md. Luego que escriba refutaciones a esas respuestas en rebuttals/-rebuttal.md. Por último, que cada agente vuelva a lanzar otro agente para revisar su propia revisión, respuestas y refutaciones, y que resuma el resultado en findings/-findings.md. Finalmente, otro agente combina los resultados y los escribe en review-findings.md, donde debe presentar una versión concisa. Esto funcionó bien tanto con modelos de frontera como con modelos alojados localmente. La última vez que lo usé fue con Qwen 3.5

  • No estoy acostumbrado a usar varios agentes dentro de un mismo flujo, así que me surgen algunas dudas
    Me pregunto si revisas todos los archivos generados para confirmar que no haya alucinaciones, o si solo ves el archivo final con los resultados resumidos. También me pregunto si la idea es que, al pasar por varios agentes, las alucinaciones se cancelen entre sí y al final quede solo la verdad. Me interesa saber si alguna vez viste errores graves en la versión final. El costo me preocupaba, aunque usando modelos alojados localmente eso debería pesar menos. Aun así, ¿los modelos alojados localmente no siguen teniendo problemas para ejecutar comandos locales o acceder a internet? Si es así, me pregunto si este método corre solo con el contexto de ese archivo, sin referenciar el resto del proyecto
  • Parece un mecanismo bastante complejo comparado con correr la misma revisión n veces y combinar los resultados. Me da curiosidad por qué llegaste a este diseño

• El contexto de fondo está aquí: Surpassing Frontier Performance with Fusion
  https://news.ycombinator.com/item?id=48525392
  El lugar con una UI un poco mejor es https://openrouter.ai/fusion. La Fusion API de OpenRouter envía una solicitud a varios modelos al mismo tiempo, y un modelo juez combina las respuestas para crear la respuesta final. Dicen que tarda más, pero mejora mucho el rendimiento. Al menos así fue en el benchmark de deep research que ellos probaron. El preset Budget está compuesto por 3 modelos más baratos, y en ese benchmark es más o menos similar a Fable mientras cuesta la mitad. El preset Quality está compuesto por 3 modelos caros, supera a Fable, pero cuesta el doble que Fable. Gráfico de Pareto: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost.... Curiosamente, incluso fusionar el mismo modelo consigo mismo mejoró el rendimiento. 2xOpus4.8 es más o menos similar a Fable en el benchmark, pero cuesta el doble que Fable. Mezclar modelos distintos da un beneficio adicional un poco mayor. Parece que la ganancia principal viene del cómputo en tiempo de prueba adicional. Me gustaría ver más investigación centrada en casos como fusionar modelos recientes y baratos, por ejemplo DSV4, consigo mismos o con Mimo, y también ver el intercambio entre la fusión como cómputo paralelo en tiempo de prueba frente a aumentar la inferencia o el número de turnos

  • Que “incluso fusionar el mismo modelo consigo mismo mejoró el rendimiento” era una técnica bastante común en la época en que se pasó de GPT-2 a GPT-3
    Básicamente es tomar más muestras del espacio de salidas posible. Si un modelo puede resolver una tarea con 60% de probabilidad, puedes sacar 5~10 muestras e implementar algo como voto mayoritario. Se dejó de usar tanto cuando subió la precisión del modelo en problemas donde combinar resultados es fácil, pero si tienes un juez más complejo, es decir, un LLM competente, todavía puedes mejorar el rendimiento simplemente muestreando más el espacio de salidas y eligiendo las partes buenas
  • Es interesante que el panel Fable 5 + GPT 5.5 supere bastante el rendimiento de frontera de cualquiera de los dos por separado, pero si le mezclas Gemini, el panel de tres modelos no mejora sino que empeora
    A mí eso me suena a que Gemini es más débil en esa tarea, pero mejor para convencer al modelo juez de su propia solución. Y también huele raro que el panel de dos Opus 4.8 esté casi exactamente al mismo nivel que un solo Fable 5. ¿Hay forma de saber si Anthropic no estará simplemente haciendo esto por detrás?
  • Da pena que casi no hayan tratado cuánto más tarda por la etapa de síntesis. En el benchmark de deep research quizá no importe mucho, pero tengo curiosidad de cómo aplicaría a tareas de programación
  • No sé si eso siga siendo cierto en los modelos actuales, pero hace algunas generaciones hubo una investigación de Microsoft donde hacer que el modelo repitiera N veces mejoraba mucho el rendimiento, y el punto óptimo era 4 repeticiones

• Corrí una evaluación rápida para ver en qué se diferencia cualitativamente de llamar directamente a Opus 4.7 o GPT 5.5
  Como era de esperarse, Fusion fue 7 veces más lento y costó 4 veces más. No lo digo para criticarlo; creo que Fusion cae en la categoría de “úsalo solo cuando haga falta”. https://3fpi5avcqq.evvl.io/

  • Fusion realmente se ve muy bien como objetivo de destilación
  • Gracias por compartirlo. Mi mayor preocupación era la velocidad, y ellos no mencionaron esa parte
  • Me da curiosidad qué modelos usaste por debajo. Si usaste el Quality predeterminado de la interfaz, entonces tiene sentido que cueste unas 4 veces más, porque usa 3 modelos de frontera y uno de ellos actúa como juez
    La idea clave probablemente sea usar Fusion con modelos más simples y baratos
  • Me parece bastante contraintuitivo. Probablemente no sea fácil encontrar el marco y la estructura correctos para que esto funcione bien. A los modelos realmente no les gusta jugar bien entre ellos
    Me pregunto cómo aguantará su versión en uso real

• He pensado mucho en este problema, y mi forma simplificada de entenderlo es ver cada modelo como una distribución en forma de campana sobre el conocimiento humano, y cada modelo tiene una distribución distinta
  Si usas varios modelos, puedes cambiar la distribución de otro modelo con texto que originalmente quedaba fuera de su curva. Pero pensándolo de nuevo, me pregunto si SFP y el aprendizaje por refuerzo ya alteran lo suficiente la distribución original del texto como para que las salidas combinadas de los modelos se vuelvan algo mejor y suficientemente diverso, o si simplemente se convierten en una cámara de eco. Todavía no tengo forma de demostrarlo, pero creo que no

• Como resultado anecdótico sobre Fusion, corrí en OpenRouter Fusion la misma consulta que había usado en Fable y el resultado fue peor
  Fable captó hasta cierto punto una capa muy profunda de conocimiento/inteligencia, y en vez de limitarse a dar una respuesta plausible, propuso priorizar ciertos elementos de la solución y hasta sugirió descartar algunos, lo cual me pareció bastante razonable. En cambio, Fusion se sintió como una ligera diversificación del mismo tipo de respuestas que daban los modelos SOTA anteriores a Fable, y en la prueba muy limitada que hice cuando tuve acceso a Fable, no alcanzó la misma profundidad a la que llegaba Fable

• El fin de semana, inspirado por el nuevo modelo OpenRouter Fusion, estuve trabajando para ver si podía correr esto en Claude Code y hacer que otras personas también pudieran probarlo fácilmente
  Lo que hice es claude-fusion-launcher — ejecuta Claude Code sobre un panel de modelos en lugar de un solo modelo. También muestra el costo. https://github.com/smorinlabs/claude-fusion-launcher

  • ¿No se vuelve caro enseguida? Los prompts sueltos que probé en el sitio me salieron casi 1 dólar por prompt

• Me pregunto si regenerar varias veces el mismo prompt con el mismo modelo, a una temperatura más alta, equivale a correr modelos distintos
  Sospecho que gran parte de la variabilidad que se percibe entre distintos modelos de frontera en realidad viene de la aleatoriedad con temperatura no cero. Los modelos parecen entrenados para devolver cantidades redondas y “bonitas” de elementos, como 5, 10, 15. Tal vez sea interferencia del entrenamiento con material de marketing. Además, en contextos grandes la recuperación está lejos de ser del 100%. Así que si en el código hay 27 bugs, ya sea usando varios modelos o llamando varias veces al mismo, en cada ejecución podrías encontrar 10 problemas distintos de esos 27

• Me pregunto si existe investigación formal en este campo. Yo también probé variaciones de este enfoque, pero me costaría decir con seguridad que los resultados fueron mejores.
  Me preocupa que sea parecido a preguntarle por separado a 2 o 3 consultores cuál es la estrategia óptima para un negocio. No tengo claro si al combinar las respuestas realmente sale algo sustancialmente mejor.

• También lancé una función similar en mi TrustedRouter como open source, incluso con cifrado de extremo a extremo: https://trustedrouter.com/

  • Está bueno ver una promesa real de privacidad. Paso demasiado tiempo leyendo interminablemente términos de proveedores evasivos y ambiguos.