El informe técnico de Fugu, el nuevo sistema de Sakana AI, ha puesto sobre la mesa una pregunta incómoda para la industria de la Inteligencia Artificial: ¿el futuro está en modelos cada vez más grandes o en sistemas capaces de coordinar varios modelos especializados como si fueran un equipo? La respuesta todavía no está cerrada, pero el avance de la compañía japonesa sugiere que la segunda vía empieza a tener argumentos muy serios.
Fugu no es un modelo tradicional en el sentido clásico. Sakana AI lo define como una familia de modelos orquestadores que reciben una consulta, deciden qué agentes o modelos deben intervenir, diseñan una estructura de trabajo y sintetizan una respuesta final. En lugar de apostar todo a un único “cerebro” monolítico, el sistema usa una capa de coordinación que aprovecha las fortalezas de varios modelos de frontera, entre ellos Claude Opus 4.8, GPT-5.5 y Gemini 3.1 Pro, según el informe técnico publicado por la compañía.
El dato que ha encendido el debate
La cifra que más ruido ha generado es el 73,7 % de Fugu-Ultra en SWE-Bench Pro, un benchmark orientado a tareas de ingeniería de software de largo recorrido. En la tabla de resultados del informe, Claude Opus 4.8 aparece con un 69,2 %, GPT-5.5 con un 58,6 % y Gemini 3.1 con un 54,2 %. En Terminal Bench 2.1, Fugu-Ultra alcanza el 82,1 %, frente al 78,2 % de GPT-5.5 y el 74,6 % de Claude Opus 4.8. También empata o lidera en pruebas como GPQA Diamond, donde Fugu y Fugu-Ultra aparecen con un 95,5 %.
Estos resultados deben leerse con cuidado. Sakana AI compara sus modelos con puntuaciones reportadas por proveedores o recogidas de leaderboards, y Fugu se apoya precisamente en algunos de esos modelos como trabajadores dentro de su sistema. No es que un modelo pequeño japonés haya “derrotado” por sí solo a Claude, GPT o Gemini. Lo relevante es distinto: una arquitectura de orquestación ha logrado superar a modelos individuales al decidir cuándo usar a cada uno.
| Benchmark | Fugu-Ultra | Fugu | Claude Opus 4.8 | Gemini 3.1 | GPT-5.5 |
|---|---|---|---|---|---|
| SWE-Bench Pro | 73,7 | 59,0 | 69,2 | 54,2 | 58,6 |
| Terminal Bench 2.1 | 82,1 | 80,2 | 74,6 | 70,3 | 78,2 |
| LiveCodeBench Pro | 90,8 | 87,8 | 84,8 | 82,9 | 88,4 |
| GPQA Diamond | 95,5 | 95,5 | 92,0 | 94,3 | 93,6 |
| CharXiv Reasoning | 86,6 | 85,1 | 84,2 | 83,3 | 84,1 |
El informe también afirma que Fugu-Ultra se sitúa cerca o por encima de resultados atribuidos a Fable 5 y Mythos Preview en algunas pruebas. Sakana AI deja claro que esos modelos no forman parte de su pool de agentes porque no son accesibles públicamente. Ese detalle es importante: Fugu no está usando Mythos por debajo, sino intentando acercarse a ese nivel mediante coordinación de modelos disponibles.
Orquestar puede ser otra forma de escalar
La tesis fuerte de Fugu es que la capacidad no depende solo del tamaño del modelo base. También depende del andamiaje que lo rodea: herramientas, memoria, feedback del entorno, llamadas a funciones, validadores, debate entre agentes y selección dinámica del modelo adecuado para cada fase.
En la versión Fugu, el sistema busca equilibrar rendimiento y latencia. El orquestador decide qué modelo trabajador debe responder a una consulta concreta, sin generar una gran conversación interna. En Fugu-Ultra, el enfoque es más ambicioso: se diseñan flujos de varios pasos con distintos agentes, roles, comunicación entre ellos y síntesis final. Esa versión sacrifica velocidad para ganar calidad en tareas complejas.
El informe describe casos donde el sistema alterna entre modelos según la tarea. En algunos problemas de Terminal Bench, por ejemplo, Fugu usa GPT-5.5 como constructor principal y recurre a Claude Opus 4.8 en puntos críticos de depuración. En tareas científicas, Sakana AI observa que el sistema tiende a recurrir a GPT para matemáticas y física, y a Gemini para ciertas preguntas de ciencia y conocimiento especializado. La novedad no es usar varios modelos, algo que ya se hace en arquitecturas multiagente, sino entrenar un orquestador para decidir esa combinación de forma adaptativa.
Esta idea golpea una narrativa muy instalada en el mercado: que el progreso pasa necesariamente por entrenar modelos cada vez más grandes, caros y cerrados. Fugu sugiere que puede haber otro eje de mejora: coordinar mejor modelos ya existentes.
La caja negra de los modelos cerrados
La parte más polémica del debate llega cuando se mira hacia los modelos propietarios. ¿Hasta qué punto los modelos de frontera que se venden como una única API son realmente un único modelo actuando solo? La respuesta pública es limitada, porque proveedores como Anthropic, OpenAI o Google no revelan toda la arquitectura de inferencia, enrutamiento, herramientas internas, verificadores o sistemas de apoyo que puedan estar usando.
No hay pruebas públicas de que Claude Mythos funcione exactamente como Fugu ni de que Anthropic o cualquier otro proveedor oculte deliberadamente un “swarm” de agentes para proteger su modelo de negocio. Esa afirmación debe tratarse como hipótesis, no como hecho. Pero la sospecha nace de una realidad técnica evidente: el rendimiento final de un sistema de IA moderno ya no depende únicamente del modelo base.
Claude Code, Codex y otros entornos agénticos muestran que una parte importante de la capacidad aparece cuando el modelo trabaja dentro de un sistema con herramientas, ejecución de comandos, edición de archivos, pruebas, memoria y feedback. El propio informe de Fugu insiste en que la capacidad práctica de un LLM depende de cómo interactúa con el entorno, no solo de sus pesos.
Por eso la pregunta razonable no es si los proveedores “mienten” al hablar de modelos. La pregunta es qué parte del rendimiento procede del modelo base y qué parte procede de la capa de sistema: prompts internos, herramientas, agentes auxiliares, validadores, enrutamiento, recuperación de contexto o mecanismos de reflexión. Esa distinción importa porque afecta al coste, a la transparencia, a la reproducibilidad y a la capacidad de las empresas para construir alternativas propias.
Qué cambia para empresas y desarrolladores
Si Fugu apunta en la dirección correcta, la industria puede entrar en una etapa menos dependiente del modelo único. Las empresas podrían construir sistemas competitivos combinando modelos especializados, algunos cerrados y otros abiertos, con capas propias de enrutamiento, validación y memoria. Esto no elimina la ventaja de los grandes laboratorios, pero reduce la distancia para casos concretos.
La idea encaja con lo que ya están haciendo muchos equipos técnicos en producción. Arquitecturas con LangGraph, CrewAI, AutoGen, workflows MCP, validadores, modelos pequeños afinados, RAG especializado y agentes locales permiten resolver tareas complejas sin enviar todo a un único modelo premium. La diferencia es que Fugu intenta empaquetar esa lógica en un sistema aprendido y medible.
También cambia la economía. Si el rendimiento depende del enrutamiento y no solo del tamaño, pagar siempre por el modelo más caro deja de tener sentido. Un sistema puede usar un modelo rápido para clasificación, otro para planificación, uno especializado en código, otro para revisión crítica y un último para síntesis. El coste por tarea puede bajar si la orquestación es buena.
La contrapartida es la complejidad. Orquestar modelos no es gratis. Añade latencia, costes de varias llamadas, problemas de trazabilidad, dependencia de proveedores, gestión de contexto y riesgos de que los agentes se contradigan o arrastren errores. Fugu-Ultra obtiene mejores resultados, pero lo hace con flujos más profundos y más lentos. Para muchos productos, esa latencia puede ser inaceptable.
El avance de Sakana AI no demuestra que los grandes modelos monolíticos hayan quedado obsoletos. Sí demuestra que el monopolio conceptual del “modelo gigante que lo hace todo” empieza a resquebrajarse. En tareas difíciles, combinar especialistas puede ser más eficaz que pedirle a un único modelo que razone, programe, depure, recuerde, contraste y sintetice al mismo tiempo.
La Inteligencia Artificial de frontera puede acabar pareciéndose menos a un oráculo y más a un equipo técnico bien coordinado. Algunos proveedores lo mostrarán de forma transparente en informes y papers. Otros lo ocultarán detrás de una API simple porque el cliente empresarial no quiere ver la maquinaria, solo el resultado. La diferencia será cada vez más importante para quienes quieran controlar costes, datos y dependencia tecnológica.
Fugu no cierra el debate. Lo abre con fuerza. Si un orquestador entrenado puede extraer rendimiento superior de modelos ya disponibles, la próxima ventaja competitiva quizá no esté solo en tener el modelo más grande, sino en saber cuándo llamar a cada modelo, qué pedirle y cómo verificar su trabajo.
Preguntas frecuentes
¿Fugu supera realmente a Claude Opus 4.8?
En algunos benchmarks publicados por Sakana AI, Fugu-Ultra supera a Claude Opus 4.8, especialmente en SWE-Bench Pro y Terminal Bench 2.1. Pero no es una comparación de modelo único contra modelo único: Fugu-Ultra orquesta varios modelos, incluido Opus 4.8.
¿Fugu usa Mythos o Fable 5 por debajo?
No según el informe técnico. Sakana AI indica que Fable 5 y Mythos Preview no forman parte del pool de Fugu porque no son modelos accesibles públicamente.
¿Significa esto que los modelos gigantes ya no importan?
No. Fugu depende de modelos de frontera potentes como trabajadores. Lo que muestra es que la orquestación puede amplificar sus capacidades y convertirse en otro eje de mejora junto al escalado del modelo base.
¿Puede una empresa replicar esta idea con modelos abiertos?
Puede aproximarse usando modelos especializados, enrutadores, agentes, RAG, validadores y workflows propios. Pero alcanzar resultados como los de Fugu exige entrenamiento del orquestador, evaluación rigurosa, buenos modelos trabajadores y mucha ingeniería de sistema.
Fuentes:
Sakana AI, Sakana Fugu Technical Report, arXiv:2606.21228v1.
