Guías de integración · 2026-09-11

Cómo usar la API de Sakana Fugu Max con LLMTR

Envíe su primera solicitud a Sakana Fugu Max a través de LLMTR: ejemplos con Chat Completions y Responses, elección del nivel de reasoning, llamada a funciones, salida estructurada, entrada de imagen y lectura del uso de tokens.

Diagrama de integración que muestra los pasos de solicitud, enrutado y respuesta de una llamada a la API que llega a Sakana Fugu Max a través de la pasarela LLMTR.

Preparar el modelo y las credenciales

En LLMTR, Fugu Max se llama con el identificador sakana/fugu-max y funciona sobre dos endpoints compatibles con OpenAI: /v1/chat/completions y /v1/responses. Puede conservar su cliente de OpenAI actual; lo que suele cambiar es la URL base y el identificador del modelo.

Necesita una cuenta con saldo, una clave de API de LLMTR y el origen del servicio. Guarde la clave en la variable LLMTR_API_KEY del entorno del proceso; no la escriba en el código fuente, en el control de versiones ni en JavaScript de navegador. Los ejemplos siguientes dan por hecho que LLMTR_BASE_URL y LLMTR_API_KEY están definidas.

Primera solicitud: Chat Completions

Empiece con una tarea pequeña y sin datos sensibles. El sufijo :high en el identificador del modelo hace explícito el nivel de reasoning solicitado.

Chat Completions de LLMTR — requiere las variables de entorno

curl --fail-with-body "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $LLMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "sakana/fugu-max:high",
    "messages": [
      { "role": "user", "content": "Review this service for concurrency risks." }
    ],
    "max_tokens": 1200
  }'

Elegir un nivel de reasoning admitido

Fugu Max solo acepta dos niveles de reasoning: high y xhigh. low, medium, minimal y none no son válidos en este modelo y se rechazan con 400. max no es un nivel aparte, sino un alias de compatibilidad de xhigh.

Elija una sola forma de indicar el ajuste. Si se envían varias, la precedencia documentada de LLMTR es reasoning_effort, después reasoning.effort y después el sufijo del modelo, de modo que un ajuste explícito antiguo puede anular el sufijo que acaba de cambiar.

Niveles de reasoning de Sakana Fugu Max, 11 de septiembre de 2026
NivelSufijo del modeloNota
high:highRazonamiento profundo
xhigh:xhighEl nivel más alto
max:maxAlias de compatibilidad de xhigh, no un nivel aparte

Llamada a funciones

La llamada a funciones es compatible y los campos tools y tool_choice se usan igual que en OpenAI. Se probó con tool_choice: required el 11 de septiembre de 2026 y devolvió un array tool_calls bien formado.

En un modelo multiagente, el momento en que llega una llamada a herramienta es el momento en que el orquestador ha terminado de hablar con sus agentes; al devolver el resultado de la herramienta empieza un segundo turno, y ese turno también se factura. Ponga un límite superior al bucle de herramientas en su aplicación.

Cuerpo de Chat Completions — llamada a funciones

{
  "model": "sakana/fugu-max",
  "messages": [{ "role": "user", "content": "What is the weather in Istanbul?" }],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "parameters": {
          "type": "object",
          "properties": { "city": { "type": "string" } },
          "required": ["city"]
        }
      }
    }
  ],
  "tool_choice": "auto"
}

Salida estructurada y entrada de imagen

Fugu Max admite tanto json_schema como json_object, y con un esquema estricto devuelve exactamente el objeto pedido. Aquí es donde se separa de Fugu Ultra, que acepta una petición json_object sin error pero puede envolver la respuesta en un bloque de código, de modo que no se puede analizar directamente. En Fugu Ultra, use json_schema para la salida estructurada.

Ambos modelos aceptan entrada de imagen; en Chat Completions se usa la parte image_url compatible con OpenAI. El ejemplo siguiente combina las dos cosas: extrae de una captura de pantalla un objeto con la forma del esquema.

Cuerpo de Chat Completions — entrada de imagen con json_schema estricto

{
  "model": "sakana/fugu-max",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Extract the error code and the failing step." },
        {
          "type": "image_url",
          "image_url": { "url": "data:image/png;base64,<base64>" }
        }
      ]
    }
  ],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "incident",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "error_code": { "type": "string" },
          "failing_step": { "type": "string" }
        },
        "required": ["error_code", "failing_step"],
        "additionalProperties": false
      }
    }
  }
}

Leer el uso de tokens

La respuesta que muestra con más detalle el desglose de tokens de una solicitud es la de /v1/responses. El bloque usage de una respuesta de Chat Completions se mantiene fiel al formato de OpenAI y no lleva los campos de orquestación; la facturación es idéntica en ambas rutas, lo único que cambia es la visibilidad.

En Fugu Max los campos de orquestación devuelven cero, porque el modelo integra el reparto entre agentes directamente en input_tokens. En Fugu Ultra esos mismos campos devuelven valores por encima de cero y hay que sumarlos aparte al cálculo del coste. El cuerpo siguiente muestra el desglose típico de una respuesta de Fugu Max.

Responses de LLMTR — solicitud que devuelve valores de uso

curl --fail-with-body "$LLMTR_BASE_URL/v1/responses" \
  -H "Authorization: Bearer $LLMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "sakana/fugu-max",
    "input": "Summarise the trade-offs of this migration plan.",
    "reasoning": { "effort": "xhigh" },
    "max_output_tokens": 2048
  }'

El bloque usage de la respuesta

En el bloque usage devuelto hay cuatro campos que importan: input_tokens, output_tokens, input_tokens_details.cached_tokens y los campos de orquestación. Calcule el coste a partir de ellos y no de total_tokens.

Ante un error, no reenvíe la solicitud sin cambios. Si falla la autenticación, revise la clave y el origen del servicio; si falta saldo, revise el saldo de la cuenta; si un parámetro no es válido, revise el cuerpo. Cada reintento puede generar trabajo facturable, así que defina una política de reintentos acotada en su aplicación.

Respuesta de Responses — desglose de uso de Fugu Max

{
  "usage": {
    "input_tokens": 161,
    "output_tokens": 361,
    "total_tokens": 522,
    "input_tokens_details": {
      "cached_tokens": 0,
      "orchestration_input_tokens": 0,
      "orchestration_input_cached_tokens": 0
    },
    "output_tokens_details": {
      "orchestration_output_tokens": 0
    }
  }
}

Antes de aumentar el volumen

Compare un conjunto representativo de salidas con sus criterios de aceptación y revise el uso real de tokens antes de subir el tráfico. Mantenga explícitos el identificador del modelo y el ajuste de reasoning para poder reproducir la configuración más adelante.

Si la calidad no basta en problemas largos de varios pasos, calcule la diferencia de coste antes de pasar a la fila sakana/fugu-ultra: la entrada cuesta 2,5 veces más, la salida 5 veces más, y los tokens de orquestación se facturan aparte.

Primera solicitud a Sakana Fugu Max con LLMTR

Los pasos para enviar una primera solicitud compatible con OpenAI a Sakana Fugu Max desde una cuenta de LLMTR y verificar los valores de uso devueltos.

  1. Cree una clave de API. Cree una clave de API en el panel de LLMTR y guárdela en la variable LLMTR_API_KEY del entorno del proceso. No escriba la clave en el código fuente ni en el control de versiones.
  2. Defina el origen del servicio. Defina LLMTR_BASE_URL con el origen del servicio de LLMTR. Conserve su cliente de OpenAI actual y cambie solo la URL base y el identificador del modelo.
  3. Elija el modelo y el nivel de reasoning. Use sakana/fugu-max como identificador de modelo. Elija high o xhigh como nivel de reasoning; low, medium y none no son válidos en este modelo.
  4. Envíe la primera solicitud. Envíe una tarea pequeña y sin datos sensibles a /v1/chat/completions o a /v1/responses y fije un presupuesto de salida explícito.
  5. Verifique los valores de uso. Lea input_tokens, output_tokens, cached_tokens y los campos de orquestación en el bloque usage de la respuesta. Calcule el coste a partir de esos campos y no de total_tokens.

Frequently asked questions

¿Tengo que reescribir mi código del SDK de OpenAI?

Normalmente no. Basta con conservar el cliente y cambiar la URL base y el identificador del modelo. Fugu Max funciona tanto en /v1/chat/completions como en /v1/responses.

¿Qué niveles de reasoning acepta Fugu Max?

Solo high y xhigh. max es un alias de xhigh. low, medium, minimal y none no son válidos en este modelo y se rechazan con 400.

¿Puedo obtener salida JSON de Fugu Max?

Sí. Fugu Max admite json_object y json_schema estricto y devuelve JSON puro. En Fugu Ultra solo json_schema es fiable.

¿Dónde puedo ver los tokens de orquestación?

En los campos input_tokens_details y output_tokens_details de una respuesta de /v1/responses. La respuesta de Chat Completions se mantiene fiel al formato de OpenAI y no los incluye.

Artículos relacionados