Precios y comparativas · 2026-09-11
Precios de Sakana Fugu Max: tokens de orquestación y coste real
Sakana Fugu Max tiene tarifa plana: $2 de entrada, $6 de salida y $0.25 de lectura de caché por millón de tokens. Vea en qué se diferencian los tokens visibles de los facturados en un modelo multiagente, con cifras medidas y un ejemplo de cálculo.
Tres conceptos, una sola tarifa
Sakana Fugu Max tiene tres conceptos de precio y los tres son independientes de la longitud del contexto: $2 de entrada, $6 de salida y $0.25 de lectura de caché por millón de tokens. La tarjeta de precios del proveedor declara esta fila como tarifa plana, así que un prompt largo nunca lleva la solicitud a una banda más cara.
Esa es la primera diferencia estructural con Fugu Ultra, que pasa a una segunda banda de precios por encima de 272.000 tokens de entrada. Fugu Max no tiene ese umbral. En trabajos de contexto largo cuyo tamaño no se puede prever, eso mejora directamente la fiabilidad de una estimación de presupuesto.
LLMTR no modifica los precios de los modelos: la cifra del catálogo es la del proveedor. El margen de plataforma se aplica solo a la recarga de crédito y se muestra como una línea aparte en el pago.
| Métrica | Precio ($/1M tokens) |
|---|---|
| Entrada | $2 |
| Salida | $6 |
| Lectura de caché | $0.25 |
Tokens de orquestación: los tokens visibles no son los facturados
En un modelo multiagente, la conversación del orquestador con sus agentes expertos también consume tokens, y esos tokens se facturan a las tarifas estándar de entrada y salida. Sakana los informa en campos separados de usage: orchestration_input_tokens, orchestration_input_cached_tokens y orchestration_output_tokens.
Lo decisivo es que esos campos no se cuentan en el total. En una solicitud trivial medida contra fugu-ultra-v2.0 el 11 de septiembre de 2026, prompt_tokens fue 681, completion_tokens fue 32 y total_tokens fue 713. La igualdad 681 + 32 = 713 demuestra que los 1.260 tokens de entrada de orquestación informados en la misma respuesta quedan completamente fuera del total.
Por tanto, un código que calcule el coste a partir de total_tokens pierde toda la orquestación en un modelo multiagente. El cálculo correcto lee los campos uno a uno.
¿Cuánto puede llegar a ser la diferencia?
El mismo día de medición, una solicitud más pesada con un json_schema estricto informó lo siguiente en fugu-ultra-v2.0: 161 tokens de entrada visibles frente a 4.259 tokens de entrada de orquestación, y 361 tokens de salida visibles frente a 482 tokens de salida de orquestación.
Un cálculo que mire solo los tokens visibles daría 161 x $5 + 361 x $30, es decir, unos $0,0116 para esa solicitud. Calculado sobre el volumen real son 4.420 x $5 + 843 x $30, es decir, unos $0,0474. La cifra visible representa alrededor de una cuarta parte del coste en esa solicitud; la diferencia ronda el 75%.
Esa proporción no es fija. El volumen de orquestación crece con la dificultad del trabajo, de modo que la diferencia se amplía en tareas difíciles. Para su propia carga de trabajo, el único método fiable es medir.
En Fugu Max los campos de orquestación devuelven cero
La buena noticia aquí es lo contrario de lo que sugeriría el apartado anterior: en todas las solicitudes a Fugu Max que se midieron, los campos de orquestación devolvieron cero. Fugu Max integra el reparto entre agentes directamente en prompt_tokens.
Quedó demostrado con una medición: al enviar por segunda vez un prefijo de 4.314 tokens, prompt_tokens subió a 12.897 -un reparto entre tres agentes ya reflejado en el recuento de entrada visible- y los campos de orquestación seguían en cero. El número de tokens que ve en Fugu Max no se queda corto.
La consecuencia práctica es que en Fugu Max la estimación de coste puede hacerse directamente desde el bloque usage, mientras que en Fugu Ultra hay que sumar aparte los campos de orquestación. Las dos filas pertenecen a la misma familia, pero su contabilidad no es la misma, y trasladar una suposición de una a otra es un error.
Ejemplo de cálculo: la misma solicitud en dos modelos
Supongamos 20.000 tokens de entrada, de los cuales 8.000 se leen de caché y 12.000 se facturan como entrada normal, y una respuesta de 2.000 tokens de salida. Es un cálculo ilustrativo, no un resultado de rendimiento medido.
Fugu Max: 12.000 x $2 + 8.000 x $0,25 + 2.000 x $6, todo dividido entre un millón, da 0,024 + 0,002 + 0,012 = $0,038.
La misma solicitud en la banda estándar de Fugu Ultra: 12.000 x $5 + 8.000 x $0,50 + 2.000 x $30, es decir, 0,06 + 0,004 + 0,06 = $0,124. Son aproximadamente 3,3 veces más, y en esa cifra no están incluidos los tokens de orquestación que Fugu Ultra factura aparte.
No cuente dos veces los tokens en caché: la lectura de caché es un subconjunto de la entrada. Reste la parte cacheada del total de entrada y facture el resto a la tarifa de entrada normal.
Comparación con otras filas del catálogo
Todas las cifras siguientes proceden del catálogo de LLMTR y no de una comparativa del proveedor. Fugu Max tiene el precio de salida más bajo de esta tabla; en lectura de caché, Claude Sonnet 5 es más barato.
No haga la comparación mirando una sola columna. En una carga dominada por salidas largas manda el precio de salida; en una carga que reenvía repetidamente el mismo prefijo grande manda la fila de lectura de caché. Sin conocer su propia mezcla de entrada, salida y caché, la tabla no decide por usted.
| Modelo | Entrada | Salida | Lectura de caché | Contexto (tokens) |
|---|---|---|---|---|
| sakana/fugu-max | $2 | $6 | $0.25 | 1.000.000 |
| sakana/fugu-ultra | $5 | $30 | $0.50 | 1.000.000 |
| anthropic/claude-sonnet-5 | $2 | $10 | $0.20 | 1.000.000 |
| moonshot/kimi-k3 | $3 | $15 | $0.30 | 1.048.576 |
Construya el presupuesto a partir del uso medido
Registre la salida total facturada, el volumen de aciertos de caché y los reintentos en tareas representativas. El nivel de reasoning cambia cuánto trabajo puede realizar el modelo, así que presupueste la respuesta completa y no la longitud del texto visible.
La respuesta que muestra con más detalle el desglose de tokens de una solicitud es la de /v1/responses; la respuesta de Chat Completions se mantiene fiel al formato de OpenAI y por eso no lleva los campos de orquestación. La guía de integración muestra con un ejemplo cómo leerlos.
LLMTR no añade margen a los precios de los modelos. El margen de plataforma es del 8% y se aplica solo a la recarga de crédito: recargar 100 USD de saldo se cobra a 108,00 USD, y las tarifas de los modelos no cambian.
Frequently asked questions
¿Cuánto cuesta Sakana Fugu Max?
Por millón de tokens: $2 de entrada, $6 de salida y $0.25 de lectura de caché. Hay una sola tarifa y no cambia con la longitud del contexto.
¿Qué es un token de orquestación y se factura?
Es un token que el orquestador gasta hablando con sus agentes expertos, y se factura a las tarifas estándar de entrada y salida. Se informa en campos separados de usage y no se cuenta dentro de total_tokens.
¿Hay un coste de orquestación oculto en Fugu Max?
No. En todas las solicitudes a Fugu Max que se midieron, los campos de orquestación devolvieron cero; el modelo integra el reparto directamente en prompt_tokens. En Fugu Ultra esos campos devuelven valores por encima de cero y hay que sumarlos aparte.
¿Fugu Max es más caro con contexto largo?
No. Fugu Max tiene tarifa plana y la longitud del contexto no cambia el precio. Fugu Ultra pasa a una segunda banda de precios por encima de 272.000 tokens de entrada.
¿LLMTR añade un margen a estos precios?
No. Las tarifas de los modelos son las del proveedor y no se modifican. El margen de plataforma del 8% se aplica solo a la recarga de crédito y se muestra por separado en el pago.