Prueba de 20 tareas para un router económico como Fugu Max

Ejecuta el lote de 20 tareas antes de mover el tráfico

Tu pipeline de agentes ya está pagando por tokens, y un router más barato puede parecer una mejora gratuita hasta que la factura muestre el trabajo interno del router. En OpenRouter, los tokens de enrutamiento interno de Fugu Max se facturan como tokens de entrada o salida ordinarios. Mantén esta prueba: ejecuta las mismas 20 tareas a través de tu modelo actual y el router, mide el gasto de tokens de salida, el tiempo real y las comprobaciones de fallo, y luego decide según el uso asíncrono o interactivo.

Fugu Max es el router que hay que probar. Sakana AI lanzó Fugu Max v1.0 y Fugu Ultra v2.0 el 11 de septiembre de 2026. Se lista a $2.00 por millón de tokens de entrada y $6.00 por millón de tokens de salida, y Sakana afirma que eso lo sitúa un 40-60% por debajo de Sonnet 5 y GPT-5.6 Terra.

La arquitectura cambia la factura. Fugu Max es un sistema de orquestación multiagente aprendido: enruta tareas a través de un pool fijo de modelos de pesos abiertos y especializados, incluida la familia NVIDIA Nemotron bajo una colaboración con NVIDIA. Cuando Fugu Max distribuye una solicitud a tres o cuatro modelos, la solicitud puede consumir sustancialmente más tokens que una llamada directa a un solo modelo, por lo que la tarifa de $6.00 por millón de tokens de salida por sí sola no garantiza una factura baja por respuesta. En el caso de Fugu Max, la factura crece con el uso total de tokens, y la orquestación aumenta el uso total de tokens, por lo que los tokens por respuesta, no la tarifa de etiqueta, es la medida de presupuesto relevante.

Construye el lote antes de la primera llamada a la API

• Elige 20 tareas de trabajo real reciente de agentes. El estado final es una hoja de cálculo con el nombre de la tarea, el prompt de entrada, la forma de salida esperada, la comprobación de éxito/fallo y el caso de uso donde se ejecuta. Mantén los prompts congelados. Cuando una tarea necesite un archivo, una llamada a herramienta o un segundo paso, anótalo en la hoja para que la segunda ejecución no se desvíe.
• Haz que el lote sea representativo de la carga de trabajo que realmente moverías. Estás listo cuando la mezcla incluye búsquedas cortas, llamadas a herramientas de varios pasos, síntesis extensa y una tarea que suele fallar. Si tu tráfico de producción es principalmente resúmenes por lotes, no pruebes con un conjunto trivial de preguntas de trivia.
• Registra la línea base del modelo actual. Termina con el recuento de tokens de salida, el tiempo real y el éxito/fallo de cada tarea. Mantén el mismo timeout, el mismo límite de reintentos y la misma temperatura. Cuando la línea base sea ruidosa, ejecútala dos veces y conserva la mediana.
• Ejecuta las mismas 20 tareas a través del router sin cambiar prompts, reintentos ni configuraciones de timeout. La segunda hoja de cálculo debe tener las mismas columnas. No limpies los prompts para el router. La prueba es el cambio, por lo que el conjunto de prompts permanece fijo.
• Mide el gasto de tokens de salida y el gasto total de tokens, y luego el tiempo real. En OpenRouter, el tiempo de respuesta mediano de Fugu Max fue de aproximadamente 5.4 segundos. Finalmente, ejecuta las mismas comprobaciones de fallo. La columna de éxito/fallo debe coincidir con la línea base tarea por tarea.

Evalúa el tiempo real según quién está esperando

Para trabajo asíncrono, el pipeline marca la pauta. El tiempo real aceptable es el tiempo que puede absorber sin romper un plazo aguas abajo; un lote nocturno puede usar un router más lento si termina antes de que comience el siguiente trabajo.

Para trabajo interactivo, la persona marca la pauta: el router debe mantenerse dentro del tiempo que una persona puede esperar sin abandonar la tarea. Cuando hace esperar al usuario notablemente más que el modelo actual, el ahorro de costos puede no compensar la demora.

Coloca una columna de tiempo real junto a la columna de tokens de salida, para que la decisión no sea una intuición sobre la velocidad.

Toma la decisión a partir de las dos hojas de cálculo

Trata el router como un candidato para un caso de uso, no como un reemplazo para cada modelo de tu stack. Un pipeline nocturno puede calificar incluso cuando el router es más lento que un modelo directo, porque el tiempo real es un problema de programación, no un problema de experiencia. El trabajo interactivo tiene una barra más alta: un humano está esperando, y unos segundos extra pueden convertir un ahorro de costos en un impuesto al flujo de trabajo.

Usa las dos hojas de cálculo para decidir: si el router muestra un menor gasto de tokens de salida, un tiempo real aceptable y sin nuevos fallos, cambia primero el caso de uso asíncrono. Mantén el modelo actual para el trabajo interactivo cuando falle alguna de esas comprobaciones, y vuelve a revisarlo solo cuando el lote cambie.