AIREITERUna petición a Fusion puede parecer gratuita en la página del modelo de OpenRouter y, aun así, costar varias veces más que una respuesta normal. La explicación es sencilla: el precio de OpenRouter Fusion suma varias llamadas a modelos subyacentes; no existe una tarifa independiente por token. El tamaño del panel y el volumen de tokens determinan si ese análisis adicional compensa el gasto.
Precios de OpenRouter Fusion: una decisión rápida
En general, OpenRouter Fusion sale más caro que llamar una sola vez a un modelo comparable. La documentación del Fusion Router de OpenRouter describe un panel predeterminado de tres modelos y una llamada al analista, con un coste aproximado de entre 4 y 5 veces el de una respuesta individual con el mismo prompt.
Un panel económico puede superar a un modelo premium si la mejora de calidad reduce el trabajo de revisión. Pero Fusion es, ante todo, una decisión entre coste y verificación; no una forma automática de pagar menos por el modelo.
| Situación | Opción predeterminada más adecuada |
|---|---|
| Petición breve, rutinaria y de bajo riesgo | Un modelo |
| Investigación con evidencias contrapuestas | Fusion, de forma selectiva |
| Mucho volumen o tráfico sensible a la latencia | Un modelo o una escalada puntual |
| Error costoso o revisión humana | Probar Fusion y medir el ahorro |
La unidad de facturación es una cadena de llamadas, no un token de Fusion
La página de la API de Fusion de OpenRouter presenta Fusion como un router y muestra un precio de cero para prompts y respuestas del alias del router. Eso significa que Fusion no tiene una tarifa independiente; no que la inferencia subyacente sea gratuita.
El flujo documentado es el siguiente:
- El prompt se envía a cada modelo seleccionado del panel.
- Un modelo analista o juez compara las respuestas del panel.
- El modelo externo genera la respuesta final.
Para hacer una previsión de costes, utiliza esta ecuación:
Fusion cost = sum(panel model costs)
+ analyst/judge cost
+ any final outer-model cost shown for your integrationLa contabilidad exacta depende de si invocas Fusion como alias de modelo openrouter/fusion o como herramienta de servidor openrouter:fusion. No deduzcas el importe final de la línea $0 que muestra el router. Comprueba la generación real y el registro correspondiente en OpenRouter Activity.
La documentación de OpenRouter admite entre 1 y 8 modelos de análisis. El panel predeterminado tiene tres. Entre las configuraciones Quality, Budget y las personalizadas, no existe un precio universal de Fusion por millón de tokens.
El tamaño del panel aumenta la factura de forma lineal… hasta que crece el coste del juez
Si todos los modelos del panel reciben el mismo prompt y generan una cantidad similar de texto, añadir un miembro equivale aproximadamente a sumar otra llamada. OpenRouter afirma explícitamente que el coste crece de forma lineal con el tamaño del panel.
Contar llamadas, sin embargo, se queda corto al estimar el coste del juez, porque su entrada crece con las respuestas del panel:
C(n) = n × Cp + Cj(n) + CoAquí, n es el número de modelos del panel, Cp es el coste medio de cada respuesta del panel, Cj(n) es el coste del juez, incluida su entrada creciente, y Co es el coste de la respuesta externa cuando corresponda.
| Tamaño del panel | Llamadas al panel | Llamadas al analista | Cadena simplificada antes de la respuesta externa |
|---|---|---|---|
| 1 | 1 | 1 | 2 llamadas |
| 2 | 2 | 1 | 3 llamadas |
| 3 (predeterminado) | 3 | 1 | 4 llamadas |
| 4 | 4 | 1 | 5 llamadas |
| 5 | 5 | 1 | 6 llamadas |
| 8 (máximo) | 8 | 1 | 9 llamadas |
Por eso, para planificar conviene tomar como referencia la estimación de 4–5 veces el coste de una respuesta individual con el panel predeterminado de tres modelos, y no la línea $0 del router. El multiplicador puede aumentar si el juez es caro, las respuestas son largas o el modelo externo añade otra generación facturable.
Ejemplo práctico con tarifas editables
Utiliza esta plantilla con las tarifas actuales de los modelos que elijas. Las cifras son orientativas, no precios de OpenRouter: supongamos 10.000 tokens de entrada, 2.000 tokens de salida por respuesta del panel, 6.000 tokens de entrada para el juez y 1.000 tokens de salida del juez.
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 outputSi la referencia de un solo modelo procesa los mismos 10.000 tokens de entrada y 2.000 de salida, compara directamente su coste total con el de esta plantilla. En un panel de tres modelos, el prompt se factura tres veces y, en este ejemplo, el juez lee además un contexto independiente de 6.000 tokens. Ajusta las hipótesis si tus prompts o respuestas son más largos.
Con una hipótesis simplificada de costes iguales, la estructura según el número de llamadas es la siguiente:
| Configuración | Subtotal del panel | Analista | Total normalizado |
|---|---|---|---|
| Un modelo | — | — | 1× |
| Fusion, 1 modelo en el panel | 1× | 1× | 2× |
| Fusion, 3 modelos en el panel | 3× | 1× | 4× |
| Fusion, 5 modelos en el panel | 5× | 1× | 6× |
| Fusion, 8 modelos en el panel | 8× | 1× | 9× |
No son precios de OpenRouter. La tabla muestra por qué el número de modelos del panel importa incluso antes de tener en cuenta que las tarifas sean distintas. Un juez caro puede dominar el coste de un panel económico; con modelos de vanguardia en el panel, puede ocurrir justo lo contrario.
El uso de tokens cambia la comparación por dos vías
El uso de tokens afecta más a Fusion que a una llamada única porque el prompt se procesa varias veces y el juez recibe las respuestas generadas por el panel.
1. Los tokens de entrada se duplican en el panel
Sea I el número de tokens del prompt y Pi el precio de entrada del modelo i del panel:
Panel input cost = I × (P1 + P2 + ... + Pn)Un prompt de 10.000 tokens enviado a tres modelos del panel genera tres cargos de entrada subyacentes, posiblemente con tres tarifas distintas.
2. Los tokens de salida también se multiplican
Si cada modelo del panel produce O tokens de salida, el panel generará aproximadamente n × O tokens. Los tokens de razonamiento facturados pueden ampliar aún más la diferencia respecto a la longitud visible de la respuesta.
Después, el juez lee esas respuestas:
Judge input ≈ original prompt + n × panel output + orchestration overheadPor tanto, una respuesta más larga puede encarecer la petición tanto por cada generación del panel como por el contexto de entrada del juez.
| Tipo de carga | Presión sobre el coste de Fusion | Implicación práctica |
|---|---|---|
| Prompt breve y respuesta breve | Domina el número de llamadas al panel | Mantén pequeño el panel salvo que la mejora de calidad esté demostrada |
| Prompt largo y respuesta breve | Domina la repetición de la entrada | Compara con cuidado las tarifas de entrada |
| Prompt breve y respuestas largas del panel | La entrada del juez crece rápidamente | Limita los presupuestos de respuesta y razonamiento |
| Prompt de investigación largo y respuestas largas | Ambos efectos se acumulan | Usa Fusion solo si el ahorro en revisión lo justifica |
| Tareas idénticas de gran volumen | La cadena completa se repite en cada petición | Un solo modelo suele ser la referencia económica |
Una estimación mensual útil es:
Total monthly cost ≈ requests × (panel input + panel output
+ judge input + judge output
+ outer response)Usa las tarifas actuales de los identificadores concretos de modelos que formen tu panel. “Budget” es una etiqueta de configuración, no una garantía de que el coste total vaya a ser inferior al de cualquier modelo individual.
¿Budget, Quality o un solo modelo?
Elige un solo modelo cuando la velocidad, la consistencia y una facturación predecible importen más que la revisión independiente. Es una opción adecuada para dar formato, extraer datos, autocompletar, reescribir de forma rutinaria y muchas tareas de programación corrientes.
Elige Fusion cuando pasar por alto un problema pueda salir caro: investigación con muchas fuentes, crítica experta, due diligence o decisiones con evidencias contrapuestas. Empieza con el panel más pequeño capaz de responder a la pregunta. Tres modelos es el valor predeterminado documentado; ocho es el máximo, no una recomendación.
La comparación que importa es:
incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposureEl anuncio independiente de benchmarks de OpenRouter recoge una evaluación DRACO de 100 tareas, con un resultado del 69,0 % para una configuración Fusion de vanguardia y del 64,7 % para un panel económico. Esas cifras respaldan el uso en investigación profunda, pero no son una tasa de acierto aplicable a cualquier prompt ni demuestran que un panel más grande sea más rentable.
Comprueba el coste antes de escalar
Considera el primer despliegue de Fusion como un ejercicio de medición. Registra:
- Los identificadores de los modelos del panel y del juez.
- El uso de tokens de entrada, salida y razonamiento cuando esté disponible.
- Los metadatos del router que confirmen si Fusion se ejecutó.
- El coste total y la latencia.
- Si la respuesta final redujo las correcciones humanas.
La documentación de Fusion indica que los metadatos de generación pueden incluir "router": "openrouter/fusion". El campo model convencional identifica el modelo concreto que gestiona la petición, pero no basta para demostrar que Fusion se haya ejecutado.
Un informe de usuario muestra el riesgo de una configuración inesperada:
“this \"Fusion\" still calls Opus 4.8 as a judge. I see no way to disable it.” — @teortaxesTex en X
Es un informe de usuario, no una regla de precios de OpenRouter. Sirve para ilustrar que un panel económico no garantiza una ejecución barata si el juez es caro o la configuración no coincide con lo que esperabas.
En producción, fija el panel y el juez cuando la API lo permita, establece límites de presupuesto y convierte Fusion en una vía de escalada explícita, en lugar de exponerlo a todas las peticiones autónomas.
Preguntas frecuentes sobre los precios de OpenRouter Fusion
¿Fusion es más barato que usar un solo modelo?
Normalmente no frente a un modelo individual de precio similar. Puede salir más barato que un modelo premium si un panel económico ofrece suficiente calidad, pero el resultado depende de las tarifas del panel, el coste del juez y el uso de tokens.
¿OpenRouter Fusion es gratuito?
El alias del router puede mostrar $0 en sus campos de prompt y respuesta. OpenRouter indica por separado que las respuestas subyacentes del panel y del juez se facturan, así que no debes asumir que una petición normal a Fusion cuesta cero.
¿Cuántas llamadas realiza una petición a Fusion?
El proceso documentado utiliza N llamadas a los modelos del panel más una llamada al analista, mientras que la respuesta externa final depende de la integración. La configuración predeterminada de tres modelos se describe como un coste aproximado de 4–5 veces el de una respuesta comparable.
¿Un panel más grande siempre ofrece mejor relación calidad-precio?
No. Más modelos pueden ampliar la cobertura, pero también añaden cargos del panel, más tokens de entrada para el juez, latencia y errores correlacionados. Aumenta el tamaño del panel solo si las pruebas con un conjunto de validación demuestran que la mejora compensa el coste.
¿Cómo puedo calcular el coste de OpenRouter Fusion?
Enumera todas las llamadas subyacentes, multiplica las tarifas actuales de entrada y salida por los tokens previstos, incluye la entrada del juez con las respuestas del panel y verifica el resultado en Activity después de realizar una petición real. Una calculadora de terceros puede servir para probar escenarios, pero las tarifas activas de OpenRouter y tu registro de Activity son la referencia definitiva.
La recomendación práctica
Usa un solo modelo como referencia. Ejecuta un conjunto de 20–50 prompts de validación con ese modelo y con un panel pequeño de Fusion. Conserva Fusion únicamente si la reducción de correcciones factuales, de evidencias omitidas o de horas de revisión compensa los tokens adicionales del panel y del juez.
Para la mayoría de los equipos, el despliegue con mejor control de costes es un solo modelo para el tráfico rutinario, Fusion con un panel pequeño para decisiones inciertas o de alto coste, y paneles más grandes únicamente cuando la mejora medida siga compensando la factura.