🧪 El examen: 38 tareas, 4 waves, calificadas por código
Antes de ver los números, definamos la escala. La prueba de campo (2026-06-22) puso 38 tareas divididas en 4 waves de dificultad creciente, sumando 334 llamadas evaluadas. «Evaluada por código» significa que cada respuesta pasó por pruebas ocultas — un solver independiente comprobó la clave antes de cualquier llamada pagada. Sin juez humano ni conjeturas: o pasó la prueba o no.
El prompt fue idéntico en ambos lados (Fugu y Opus), con 3 a 7 ejecuciones por tarea para medir la consistencia, y partial credit en las tareas de múltiples reglas (ganas en proporción al número de reglas cumplidas). Esta es la base que le da peso a todo lo que viene después.
🆕 ¿Nuevo por aquí? Tres términos
- Evaluado por código: la calificación viene de pruebas automatizadas, no de opiniones: elimina el sesgo del evaluador.
- Pruebas ocultas: los casos de evaluación no se le muestran al modelo, para que no «memorice» la respuesta.
- Crédito parcial: en tareas con varias reglas, acertar 4 de 5 vale 4/5, no cero.
🌊 Las 4 waves
| Wave | Tareas | Carácter |
|---|---|---|
| Wave 1 | 14 | acertijos «textbook-hard» (el límite básico ya es alto) |
| Wave 2 | 11 | "designed traps" (trampas diseñadas) |
| Wave 3 | 6 | "dense multi-rule specs" (especificaciones densas, con múltiples reglas) |
| Wave 4 | 7 | "failure frontier" (hechas para hacer fallar a 1 modelo) |
Total: 14 + 11 + 6 + 7 = 38 tareas. Cada wave es más difícil que la anterior: la Wave 4 se diseñó para encontrar dónde se atasca un modelo en solitario.
🎯 Quién fue más preciso
El puntaje de corrección, sumando las 38 tareas: 36 empates · 2 victorias del soloist (Opus) · 0 victorias del equipo (Fugu). Al leer wave por wave, el equipo oculto nunca encontró una respuesta que el modelo solo no encontrara. En palabras de la prueba de campo: "ni 1 vez de 38".
🏁 Corrección por wave (Fugu / Opus / empate)
| Wave | Victorias de Fugu | Victorias de Opus | Empates |
|---|---|---|---|
| Wave 1 | 0 | 1 | 13 |
| Wave 2 | 0 | 0 | 11 |
| Wave 3 | 0 | 1 | 5 |
| Wave 4 | 0 | 0 | 7 |
| Total | 0 | 2 | 36 |
Las 2 victorias de Opus llegaron en Wave 1 y Wave 3 (detalladas en el tema 5). El equipo no ganó ninguna, en ninguna wave.
⚠️ La lectura en bruto
Más modelos no produjeron más aciertos. La promesa «combina varios y supera el límite de uno solo» (Ruta 1) no se confirmó en este examen: el techo del modelo individual ya era suficiente para empatar en casi todo, y el beneficio marginal del equipo fue exactamente cero en corrección.
⏱️ El reloj: 4.5× más lento
Si hubo empate en precisión, no lo hubo en tiempo. En total, en el examen, Fugu tardó 357 minutos contra 80 minutos del Opus — alrededor de 4.5× más lento. En código simple, el contraste es brutal: Opus respondía en 3–6 segundos, Fugu en 2–7 minutos — para la misma respuesta.
Latencia media por tarea, Fugu (azul) vs. Opus (cian). En todas las waves, el equipo es considerablemente más lento: el precio de esperar a que termine todo el fan-out.
📊 Latencia media por tarea (segundos)
| Wave | Fugu | Opus | Razón aprox. |
|---|---|---|---|
| Wave 1 | 205s | 40s | ~5× |
| Wave 2 | 110s | 19s | ~6× |
| Wave 3 | 161s | 6s | ~27× |
| Wave 4 | 97s | 15s | ~6× |
| Total | 357 min | 80 min | 4.5× |
Wave 3 (especificaciones densas) fue la más desproporcionada: Opus resolvía en 6s lo que a Fugu le tomaba ~161s; misma respuesta, ~27× el tiempo.
💸 La cuenta: 5× más caro
La cuenta final del examen: US$ 53,60 (Fugu, 163 calls) contra US$ 10,66 (Opus, 171 calls) — cerca de 5× más caro. Fíjate: Fugu hizo hasta menos llamadas externas, pero costó mucho más. El motivo es el costo oculto de la Ruta 1, ahora con factura: la mayor parte del gasto de Fugu está en las orchestration tokens — lo que el equipo privado lee y escribe por dentro, todo facturado.
Costo promedio por tarea, Fugu (azul) vs. Opus (cian). La Wave 3 es la más desigual: ~$0.358 vs. ~$0.014: el equipo cuesta ~26× para empatar.
📊 Costo promedio por tarea (US$)
| Wave | Fugu | Opus | Razón aprox. |
|---|---|---|---|
| Wave 1 | $0.389 | $0.100 | ~4× |
| Wave 2 | $0.297 | $0.046 | ~6× |
| Wave 3 | $0.358 | $0.014 | ~26× |
| Wave 4 | $0.276 | $0.037 | ~7× |
| Total | $53.60 (163 calls) | $10.66 (171 calls) | 5× |
Más caro con menos llamadas: el costo no está en la cantidad de llamadas, sino en los tokens internos del equipo. Pagas por todo el pool, no solo por la respuesta final.
🥈 Las 2 derrotas del equipo
De las 38 tareas, solo 2 no empataron, y en ambas fue el en solitario que ganó. El equipo no solo no ganó nada: donde hubo diferencias, perdió. Coordinar no te inmuniza contra los errores; a veces añade puntos de falla.
Wave 3 — "corrige todos los bugs del módulo de estadísticas"
El módulo tenía 6 errores. Opus detectó los 6 en cada ejecución (100%). Fugu, una y otra vez, pasó por alto 1: quedó en 80% (5/6). La misma tarea, y el equipo dejó pasar un bug de manera sistemática.
Wave 1 — "validación estricta de números romanos"
La regla era rechazar formas inválidas como «IIII». Opus hizo 5/5; Fugu hizo 4/5 — falló una vez, al aceptar lo que debería rechazar.
📊 Las 2 derrotas, lado a lado
| Tarea | Fugu | Opus | Ganador |
|---|---|---|---|
| Stats: 6 bugs | 80% (5/6) | 100% (6/6) | Opus |
| Romano estricto | 4/5 | 5/5 | Opus |
⚠️ La lección
Cuando la ganancia de combinar modelos es cero (corrección) y el equipo aún se equivoca en lo que el modelo solo acierta, la relación costo × beneficio se inclina con fuerza hacia el modelo único, justo lo que formaliza el ladder del siguiente tema.
🪜 La escalera de decisión + configuración en Claude Code
El veredicto no es «el orquestador es malo», sino «usa el criterio correcto». La prueba de campo propone un escalera de decisión: una escalera de 3 preguntas que indica, para cada tarea, si el orquestador justifica su lugar o si un modelo potente por sí solo es la mejor compra.
La escalera: solo en el último escalón gana el orquestador. En este examen, todas las tareas "cayeron por arriba": un modelo potente ya empataba, más rápido y barato.
🪜 Los 3 escalones
- 1.¿Un modelo potente ya lo resuelve? → SÍ: usa 1 modelo (más rápido, barato y empata).
- 2.NO → quieres 1 endpoint + hedge de vendor, e ¿la espera y el costo no importan? → NO: 1 modelo sigue siendo la mejor compra.
- 3.SÍ → entonces el orquestador sí se gana su lugar.
✓ Cuándo elegir Fugu
- ✓Quieres cero código de orquestación + 1 endpoint
- ✓Quieres protegerte contra el lock-in con 1 proveedor
- ✓El costo y la espera no importan en tu caso
✗ Cuándo quedarse con 1 modelo potente
- ✗Un modelo top ya resuelve la tarea
- ✗Te importa la velocidad (el equipo suma minutos)
- ✗Te importa el costo (pagas al equipo oculto)
🛠️ Práctico: configuración conceptual de Fugu en Claude Code
La idea, a nivel conceptual, es apuntar Claude Code al endpoint de Fugu usando tu API key: el mismo patrón de «base URL + API key» que usas con cualquier proveedor compatible. Primero, honestidad: los pasos exactos (endpoint correcto, nombre de las variables, billing) vienen de la documentación oficial de Sakana (sakana.ai) y del markdown de configuración del autor. La prueba de campo indica que la configuración de Fugu no es trivial — no es solo «cambiar endpoint + key» como en un provider común compatible con OpenAI. Trata el ejemplo de abajo como un esqueleto, no como una receta literal.
# Esqueleto conceitual — substitua pelos valores reais da doc da Sakana. # NÃO é um endpoint garantido; confirme em sakana.ai e no .md do autor. export ANTHROPIC_BASE_URL="<base-url-da-sakana>" # ex.: a URL do gateway Fugu export ANTHROPIC_API_KEY="<sua-api-key>" # sua chave do Fugu # depois, no Claude Code, você apontaria a sessão para esse provider # e usaria o modelo "fugu-ultra" conforme a doc indicar. claude --model fugu-ultra "resuma este repositório e aponte 3 riscos"
Facturación: hay dos formas — suscripción (plan mensual, como el autor que agotó el límite de 5h del plan de US$ 200/mes) o pay-as-you-go via API (pagas por token utilizado). Para experimentar sin comprometerte con un plan, pay-as-you-go suele ser la opción — pero recuerda el costo oculto: pagas los orchestration tokens del equipo. Confirma los valores y los endpoints en sakana.ai antes de ejecutar.
Repaso rápido (opcional): en la prueba de campo, ¿cuál fue el resultado principal?
✅ Resumen del módulo
Siguiente ruta:
Ruta 3 — OpenRouter Fusion: el ensemble (mismo prompt, N modelos, un juez)