jueves, 12 de noviembre de 2026
PortadaModelosNoticia y análisis

Fugu Max y Ultra v2: la IA que reparte el trabajo entre otros modelos

Sakana presenta dos variantes de Fugu para equilibrar coste y capacidad. Qué significa coordinar modelos y qué conviene comprobar antes de usarlo.

Gráfico conceptual de Texploto: una petición llega a un coordinador y se distribuye entre tres modelos antes de reunir la respuesta.
Gráfico conceptual original de Texploto, dibujado por código. No es una captura del producto.

La idea clave

Fugu presenta una interfaz única para un sistema que coordina distintos modelos. Max prioriza eficiencia y Ultra v2 se orienta a tareas complejas.

Cuando encargas una tarea a una IA, elegir un único modelo parece lo natural. Sakana propone que esa decisión forme parte del propio sistema: un coordinador reparte trabajo entre modelos y reúne sus aportaciones. El 11 de septiembre presentó Fugu Max y Fugu Ultra v2, dos variantes de esa arquitectura.

El interés de la propuesta está en el reparto del esfuerzo. Una tarea larga puede contener pasos sencillos y otros que requieren más razonamiento. Nuestra lectura es que la comparación útil debe mirar cuánto cuesta terminar bien el trabajo completo, además del precio anunciado por token.

Qué diferencia a Max de Ultra v2

Según el anuncio de Sakana, Max amplía su conjunto de modelos abiertos y especializados y busca reducir el coste. Ultra v2 prioriza capacidad en trabajos complejos de varios pasos. Ambos se ofrecen a través de su API compatible con OpenAI. Esa compatibilidad describe la interfaz; el proveedor del servicio es Sakana.

La empresa presenta resultados comparativos favorables. Deben leerse como evaluaciones comunicadas por el fabricante, no como una prueba independiente de que siempre supere a cualquier modelo. No hemos utilizado estas variantes en una evaluación propia.

Qué significa coordinar modelos

Un ejemplo editorial ayuda a verlo: imagina que quieres comparar tres propuestas de software. El trabajo incluye extraer requisitos, encontrar contradicciones y preparar una recomendación. Son subtareas con criterios distintos. El valor de coordinarlas dependería de que el sistema conserve los requisitos y detecte cuándo una respuesta parcial necesita revisión.

También puede ocurrir lo contrario: una interpretación errónea al principio puede propagarse a los siguientes pasos. Reunir varias respuestas no garantiza que sean independientes, que se contradigan cuando corresponde ni que la conclusión tenga fuentes suficientes.

Cómo se accede y qué conviene mirar

La documentación de inicio explica el acceso desde la consola y el uso de una API común para Fugu. Una API permite que un programa envíe peticiones al servicio; no equivale a descargar los modelos para ejecutarlos sin conexión.

Antes de integrarlo, comprueba en la consola la variante disponible, su facturación y el control de proveedores. La documentación describe un conjunto de proveedores por defecto y opciones para limitarlo en la configuración de Fugu. Verifica qué controles se aplican a tu modalidad concreta antes de enviar información de un proyecto.

Para una primera valoración, utiliza material público o ficticio y un encargo pequeño. Anota el criterio de éxito antes de ver la respuesta: así reduces la tentación de considerar buena cualquier salida que resulte convincente.

Una prueba que sí ayudaría a decidir

Evaluación propuesta

Entrega tres fichas ficticias: una herramienta cumple el presupuesto, otra ofrece una función imprescindible y la tercera tiene una condición incompatible. Pide una comparación que cite el fragmento que respalda cada conclusión y permita responder «ninguna cumple».

Comprueba si detecta la incompatibilidad, si inventa una opción ganadora y cuánto cuesta repetir el encargo. Cambia después una sola condición y observa si la recomendación se actualiza de manera coherente. No hemos realizado esta prueba; es un criterio de evaluación reutilizable.

Si te interesa organizar tareas que duren varias sesiones, nuestra explicación de Cursor Projects aborda otra pieza del problema: conservar el contexto del proyecto. Coordinar modelos y conservar contexto pueden complementarse, pero una función no acredita automáticamente la otra.