API de OpenRouter Fusion Flash: estado, configuración y soluciones para errores 400

Si estás buscando la API de OpenRouter Fusion Flash, probablemente quieres aprovechar el preset rápido de Fusion o solucionar un error HTTP 400. El problema es que la documentación oficial muestra openrouter/fusion-flash, mientras que el catálogo en tiempo real puede no incluirlo. Antes de integrarlo, comprueba que el alias esté disponible en tu cuenta.

¿Está disponible realmente OpenRouter Fusion Flash?

La documentación oficial de Fusion Router incluye openrouter/fusion-flash como un slug de modelo independiente. Según la guía, este alias utiliza Fusion con el preset general-fast seleccionado por defecto. Está pensado para interacciones rápidas y con agentes, y emplea un panel elegido para ofrecer una latencia más homogénea.

La misma guía oficial explica que Fusion ejecuta en paralelo los modelos del panel, hace que un analista compare consensos y discrepancias, y deja que un modelo externo redacte la respuesta final. Fusion Flash es el preset rápido de ese enrutador compuesto, no un modelo individual de un proveedor.

El catálogo de modelos de OpenRouter consultado para esta guía el 11 de septiembre de 2026 incluía openrouter/fusion, pero no mostraba un registro independiente para openrouter/fusion-flash. Un usuario describió exactamente este problema en X:

“the docs say openrouter/fusion-flash is a separately listed model with its own /api/v1/models entry, but API calls currently return a 400 error: fusion-flash is not a valid model ID.” — @PeterDaveHello

Se trata de un informe de usuario, no de una confirmación de OpenRouter. La documentación oficial de OpenRouter describe Fusion, pero no se encontró ningún anuncio oficial que confirmara para esta guía el lanzamiento o la retirada de Fusion Flash como alias independiente. La conclusión más prudente es: está documentado, pero hay que comprobar su disponibilidad en tiempo real antes de integrarlo.

Qué comprobar antes de culpar al código

Consulta el catálogo de modelos con la misma clave y en el mismo entorno que utiliza tu aplicación:

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

Busca en el JSON la cadena exacta openrouter/fusion-flash. No des por hecho que está disponible porque aparezca en una página de modelo, en el autocompletado de un SDK o en una integración almacenada en caché. La documentación de modelos de OpenRouter considera el catálogo la fuente de referencia para conocer los identificadores actuales y los parámetros compatibles.

También conviene revisar la página de estado oficial, aunque un estado general en verde no demuestra que un alias concreto del enrutador esté operativo. El panel informa sobre componentes amplios, como Chat API y Data API; puede existir un problema de alias o configuración mientras Chat API sigue funcionando con normalidad.

Configuración mínima de OpenRouter Fusion Flash API

Empieza por la petición más sencilla posible a Chat Completions. Así eliminas del primer diagnóstico los adaptadores del SDK, los esquemas de herramientas, el streaming y los ajustes personalizados de Fusion.

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

El ejemplo deja claros el endpoint y las cabeceras. Mantén stream: false en esta primera prueba para poder leer con facilidad el cuerpo completo de cualquier error.

Si el alias aparece en /api/v1/models y la petición funciona, añade después los campos de tu aplicación uno por uno. Si el alias no aparece, no pierdas tiempo cambiando prompts ni repitiendo la misma petición. Como diagnóstico, prueba el equivalente documentado:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

Esta alternativa permite comprobar si la ruta de Fusion y el preset rápido son accesibles, pero no demuestra que el alias y la configuración explícita sean idénticos en todos los detalles internos del backend.

Cómo aislar los errores 400 de OpenRouter Fusion Flash API

Un 400 suele indicar un rechazo de la petición o del proveedor, aunque la causa exacta depende del cuerpo de la respuesta. No es lo mismo que una caída con error 500 ni que una respuesta HTTP 200 cuyo proceso interno de Fusion haya fallado. Sigue este orden para que cada prueba responda a una sola pregunta.

1. Lee el cuerpo completo del error

Guarda la respuesta en lugar de registrar únicamente 400 Bad Request:

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

Busca el código y el mensaje del error, el proveedor, el ID de la petición o de la generación y cualquier metadato adicional. El mensaje “fusion-flash is not a valid model ID” apunta a un desfase en el descubrimiento del modelo o en el despliegue del alias. “Provider returned error” indica que la petición llegó a una ruta del proveedor, pero fue rechazada allí. Si el 400 no aporta detalles, revisa el registro de Activity de OpenRouter en lugar de intentar adivinar.

2. Confirma el ID exacto del modelo

Los identificadores de modelo son cadenas sensibles a mayúsculas y minúsculas. Compara el valor de tu petición con la respuesta actual de /api/v1/models, incluidos la puntuación y el carácter de barra. Elimina de la configuración de la aplicación los alias obsoletos y no sustituyas silenciosamente el valor por un nombre inventado de Gemini u otro modelo Flash.

Esta matriz de diagnóstico puede ayudarte:

Prueba	Resultado	Siguiente paso más probable
`openrouter/fusion-flash` no aparece en `/api/v1/models`	400 o error de modelo no válido	Usa Fusion estándar con `general-fast` o espera a que aparezca el alias; la documentación no sustituye al descubrimiento en tiempo real.
El alias aparece, pero falla la petición mínima	400 antes de añadir complejidad de la aplicación	Revisa el cuerpo completo del error y los metadatos de Activity; podría tratarse de un problema de cuenta, enrutador o despliegue.
La petición mínima funciona, pero las herramientas fallan	400 al añadir las herramientas	Valida los esquemas de las herramientas y prueba con una sola herramienta o sin herramientas.
La petición mínima funciona, pero falla el streaming	La petición sin streaming funciona	Comprueba por separado el adaptador de streaming del cliente y la compatibilidad con Fusion.
Falla un modelo personalizado del panel	Otras configuraciones del panel funcionan	Elimina o sustituye ese modelo y revisa los metadatos específicos del proveedor.
La respuesta HTTP 200 contiene un fallo interno de Fusion	El transporte externo se completó correctamente	Trátalo como un fallo interno del panel o del analista, no como un 400 de nivel superior.

3. Elimina los campos no compatibles

Envía únicamente model, messages, stream: false y las dos cabeceras obligatorias. Después, vuelve a introducir los campos en este orden:

temperature o los ajustes de razonamiento.
plugins y el preset de Fusion.
analysis_models personalizado o el model del analista.
tools y tool_choice.
Streaming y opciones de respuesta específicas del framework.

La guía de Fusion de OpenRouter documenta analysis_models, model, preset, max_tool_calls, max_completion_tokens, reasoning y temperature. Que un campo esté documentado para un endpoint o una familia de modelos no significa que sea válido automáticamente para cualquier modelo de origen. Consulta la referencia de modelos de OpenRouter y los metadatos de parámetros compatibles del modelo concreto.

4. Reduce la complejidad de las herramientas y del historial

Los clientes con herramientas pueden provocar errores 400 difíciles de interpretar porque el payload final puede incluir un JSON Schema no válido, un parámetro de herramienta no compatible o una secuencia incompleta de mensajes assistant/tool. Un informe público de Hermes Agent documentó errores 400 de OpenRouter en la versión 0.10.0 con las herramientas activadas en varios modelos probados; el informe sospechaba de sus 28 herramientas predeterminadas, pero no incluía una prueba de control exitosa con las herramientas desactivadas ni confirmaba la causa raíz. Consulta el issue #13927 como pista para reproducir el problema, no como prueba de que todos los errores 400 de Fusion Flash se deban a las herramientas.

Para aislarlo, prueba estas tres variantes:

Envía el mismo prompt sin tools.
Envía una única herramienta con un esquema de objeto sencillo.
Inicia una conversación nueva, sin llamadas a herramientas ni resultados de herramientas anteriores.

Si la petición de texto mínima funciona y la petición con la herramienta reducida también, vuelve a añadir las herramientas una por una. Si falla un historial largo de uso de herramientas mientras una petición nueva funciona, recorta o resume el historial antes de investigar el modelo.

5. Distingue los fallos del alias, del enrutador y del proveedor

Fusion puede implicar modelos del panel, un modelo analista y un modelo que redacta la respuesta final. Por eso, un fallo en una llamada interna puede no parecerse al error habitual de un modelo individual. La documentación de OpenRouter recomienda revisar los datos de generación y Activity para comprobar qué se ejecutó realmente. El campo de respuesta model puede identificar el modelo externo concreto, pero por sí solo no demuestra que Fusion se haya utilizado o no.

En una ejecución correcta de Fusion, los metadatos de generación documentados incluyen:

{
  "router": "openrouter/fusion"
}

Si proporcionas analysis_models personalizados, elimínalos y vuelve a probar el preset. Si el preset funciona pero falla un modelo concreto, lo más probable es que el problema esté relacionado con los parámetros de ese modelo, la disponibilidad del proveedor o los límites de contexto. Si todos los modelos fallan únicamente al usar un SDK, compara el payload real del SDK con el payload de cURL que sí funciona. Los clientes compatibles con OpenAI pueden añadir herramientas, flags de streaming, formatos de respuesta o transformaciones de mensajes que no se ven en el código de la aplicación.

Cuándo dejar de reintentar

Los reintentos automáticos no solucionan un ID de modelo inválido ni un rechazo determinista del esquema. Si el 400 aparece marcado como no reintentable, define una ruta de fallback clara:

El alias no aparece en el descubrimiento de modelos: dirige la petición a openrouter/fusion con general-fast o utiliza un modelo normal conocido mientras supervisas el catálogo.
El 400 depende del payload: conserva la petición mínima como prueba de regresión y corrige el primer campo que provoca el fallo.
El 400 es específico del proveedor: elimina el modelo afectado del panel o utiliza un fallback configurado; guarda la respuesta del proveedor.
Hay una incidencia general en Chat API: revisa la página de estado de OpenRouter y pausa el despliegue en lugar de cambiar la lógica de la aplicación.
Hay un HTTP 200 con un fallo interno: registra los fallos del panel y decide si un resultado parcial es aceptable; no lo clasifiques como un error de autenticación.

La documentación oficial de Fusion Router calcula que su panel predeterminado de tres modelos cuesta aproximadamente entre 4 y 5 veces una única completion; el importe exacto depende de las llamadas subyacentes. Por eso, un fallback protege tanto la fiabilidad como el gasto mientras la disponibilidad del alias siga siendo incierta.

Preguntas frecuentes sobre OpenRouter Fusion Flash API

¿Cuál es el ID correcto del modelo OpenRouter Fusion Flash?

La documentación oficial muestra openrouter/fusion-flash. Comprueba esa cadena exacta en GET /api/v1/models antes de desplegar, porque la documentación y el descubrimiento en tiempo real pueden divergir temporalmente.

¿Fusion Flash es un modelo rápido normal?

No. Está documentado como Fusion utilizando el preset general-fast. Aun así, puede realizar varias llamadas internas a modelos, así que “Flash” describe el objetivo de latencia del preset, no una ejecución de una sola llamada.

¿Qué endpoint debo utilizar?

Usa https://openrouter.ai/api/v1/chat/completions con autenticación Bearer y un cuerpo JSON. No inventes una ruta específica para Fusion.

¿Puedo obligar a Fusion a ejecutarse?

La documentación de Fusion admite tool_choice: "required". Si Fusion es la única herramienta disponible, esto fuerza en la práctica una llamada a la herramienta. Si hay otras herramientas presentes, required significa que debe llamarse alguna, no necesariamente Fusion.

¿Por qué la página de estado de OpenRouter puede estar en verde mientras Fusion Flash devuelve un 400?

La página de estado informa sobre componentes generales del servicio. Un alias ausente, una configuración de enrutador inválida o un rechazo específico del proveedor pueden afectar a una sola ruta mientras Chat API sigue operativa.

¿Fusion Flash es gratis?

No lo des por hecho. La página del modelo Fusion de OpenRouter explica que las completions del panel y del analista subyacentes se incluyen en la factura, aunque el alias del enrutador no muestre un precio de tokens independiente. Revisa Activity y las tarifas de los modelos seleccionados antes de utilizarlo en producción.

Usa el preset rápido únicamente cuando el descubrimiento en tiempo real y una petición mínima confirmen lo mismo. En caso contrario, vuelve a Fusion estándar o a un modelo conocido y conserva el payload que falla en lugar de reintentarlo a ciegas.