OpenRouter ha lanzado Fusion, una API que recibe tu consulta, la envía a un panel de modelos en paralelo, evalúa las respuestas con un modelo juez aparte y devuelve una sola contestación combinada. La propuesta llega el 13 de junio de 2026, un día después de que el gobierno de EEUU ordene a Anthropic retirar Mythos 5 y Fable 5 a nivel global. El timing no es casualidad.
Contexto: por qué ahora
OpenRouter es la capa de routing más usada por empresas que quieren llamar a OpenAI, Anthropic, Google, DeepSeek, Mistral y otros con una sola API. Fusion es el siguiente paso lógico: en vez de elegir un solo modelo por llamada, mandas la consulta a varios y devuelves una respuesta consolidada.
La tesis que defiende su CEO Alex Atallah, citado en el blog del lanzamiento, es que la combinación de varios modelos especialistas puede igualar o superar al modelo individual más capaz, sin pagar el premium de ese modelo top. Esta semana esa tesis tiene argumento extra: si un modelo frontera puede desaparecer en 72 horas por orden gubernamental, depender de uno solo es un riesgo cuantificable.
Cómo funciona, técnico
El flujo tiene tres capas:
1. Panel de modelos. Por defecto un trio (configurable hasta 5 modelos por panel). Cada miembro recibe el prompt completo y devuelve su respuesta. Puede tener web search y web fetch activos durante esta fase. 2. Modelo juez. Recibe las respuestas del panel y produce un análisis estructurado: qué hay de consenso, dónde se contradicen, qué cubre solo uno de los miembros, qué insight único aporta cada respuesta, qué blind spots quedan. 3. Redacción final. El juez sintetiza una respuesta única usando ese análisis estructurado como base.
Accesible vía slug `openrouter/fusion`, la misma API compatible con OpenAI que el resto de OpenRouter. Si ya operas con ellos, es cambiar el modelo en la llamada y nada más.
Los números, con cautela
El benchmark que ha publicado OpenRouter en su blog: Fable 5 (Anthropic) + GPT-5.5 (OpenAI) fusionados puntúan 69,0% en su test interno, frente a Fable 5 solo a 65,3%. Es decir, una mejora de 3,7 puntos sobre el modelo individual más capaz.
La parte que hay que leer entera: el coste de Fusion no es la mitad del modelo top, es 4-5x el coste de una sola completion del mismo prompt. La cuenta sale igual porque combina modelos baratos y solo paga el juez como overhead, comparado contra el precio por token de Opus o GPT-5.5. Pero si tu baseline son llamadas a Haiku o Gemini Flash, Fusion va a ser más caro, no más barato.
Por qué importa para una empresa española
Si construyes sobre Claude API y la semana pasada perdiste el sueño con la orden de export control, Fusion es exactamente el patrón arquitectónico que recomendamos en la nota anterior: aislar la lógica del producto del modelo concreto detrás. La diferencia es que ahora no lo construyes, lo consumes como API gestionada.
Para founders que están eligiendo stack de IA por primera vez, también es señal de hacia dónde va el mercado: la era de elegir un modelo y casarte con él se está acabando. La capa de routing va a ser pieza estándar.
Qué hacer
- Cuándo probarlo: research interno, generación de documentos largos, análisis profundo, casos donde el coste de equivocarte supera el coste de varias completions extra. Compliance de banca, due diligence, análisis de contratos.
- Cuándo no usarlo: chatbots de cliente, copiloto en tiempo real, cualquier pipeline con SLA de latencia estrecho. Fusion añade overhead obvio: varias llamadas en paralelo más la síntesis del juez.
- Cómo evaluarlo en serio: pasa 20 prompts reales de tu backlog por Fusion y por tu modelo actual. Mide coste total, latencia y calidad subjetiva del output. Si Fusion gana en al menos 12 de los 20 a coste asumible, merece sitio en la rotación. Si no, sigue con lo que ya tienes.