Integration guides · 2026-09-11

How to Use the Sakana Fugu Max API Through LLMTR

Send your first Sakana Fugu Max request through LLMTR: Chat Completions and Responses examples, choosing a supported reasoning level, tool calling, structured output, image input, and reading token usage.

Integration diagram showing the request, routing and response steps of an API call reaching Sakana Fugu Max through the LLMTR gateway.

Prepare the model and credentials

Fugu Max is called on LLMTR as sakana/fugu-max and runs over two OpenAI-compatible endpoints: /v1/chat/completions and /v1/responses. You can keep your existing OpenAI client; what typically changes is the base URL and the model identifier.

You need a funded account, an LLMTR API key and the service origin. Store the key in LLMTR_API_KEY in the process environment; do not write it into source code, version control or browser JavaScript. The examples below assume LLMTR_BASE_URL and LLMTR_API_KEY are both set.

First request: Chat Completions

Start with one small, non-sensitive task. The :high suffix on the model identifier makes the requested reasoning level explicit.

LLMTR Chat Completions — environment variables required

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
  }'

Choose a supported reasoning level

Fugu Max accepts only two reasoning levels: high and xhigh. low, medium, minimal and none are not valid on this model and are rejected with 400. max is not a separate level but a compatibility alias for xhigh.

Pick one way to express the setting. If several forms are sent, LLMTR's documented precedence is reasoning_effort, then reasoning.effort, then the model suffix, so an old explicit setting can override a suffix you just changed.

Sakana Fugu Max reasoning levels, 11 September 2026
LevelModel suffixNote
high:highDeep reasoning
xhigh:xhighThe highest level
max:maxA compatibility alias for xhigh, not a separate level

Tool calling

Function calling is supported and the tools and tool_choice fields work as they do on OpenAI. This was exercised with tool_choice: required on 11 September 2026 and returned a well-formed tool_calls array.

On a multi-agent model, the moment a tool call comes back is the moment the orchestrator has finished talking to its agents; sending the tool result back starts a second turn, and that turn is billed too. Put an upper bound on the tool loop in your application.

Chat Completions body — function calling

{
  "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"
}

Structured output and image input

Fugu Max supports both json_schema and json_object, and a strict schema parses as exactly the requested object. This is where it diverges from Fugu Ultra, which accepts a json_object request without an error but may wrap the answer in a fenced code block, so it cannot be parsed directly. Use json_schema for structured output on Fugu Ultra.

Image input is accepted on both models; on Chat Completions you use the OpenAI-compatible image_url part. The example below combines the two: it extracts a schema-shaped object from a screenshot.

Chat Completions body — image input with a strict json_schema

{
  "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
      }
    }
  }
}

Read the token usage

The response that shows a request's token breakdown in most detail is /v1/responses. The usage block on a Chat Completions response stays faithful to the OpenAI shape and does not carry the orchestration fields; billing is identical on both paths, only visibility differs.

On Fugu Max the orchestration fields return zero, because the model folds its agent fan-out straight into input_tokens. On Fugu Ultra the same fields return above zero and have to be added to the cost calculation separately. The body below shows the typical breakdown of a Fugu Max response.

LLMTR Responses — a request that returns usage values

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
  }'

The usage block in the response

Four fields matter in the returned usage block: input_tokens, output_tokens, input_tokens_details.cached_tokens and the orchestration fields. Compute cost from those, not from total_tokens.

On an error, do not resend the request unchanged. For an authentication failure check the key and the service origin, for insufficient credit check the account balance, and for an invalid parameter check the body. Every retry can create new billable work, so define a bounded retry policy in your application.

Responses response — Fugu Max usage breakdown

{
  "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
    }
  }
}

Before increasing volume

Compare a representative set of outputs with your acceptance criteria and review actual token usage before you raise traffic. Keep the model identifier and the reasoning setting explicit so the configuration can be reproduced later.

If quality is not sufficient on long multi-step problems, calculate the cost difference before moving to the sakana/fugu-ultra row: input costs 2.5 times more, output 5 times more, and orchestration tokens are billed on top.

First request to Sakana Fugu Max through LLMTR

The steps for sending a first OpenAI-compatible request to Sakana Fugu Max with an LLMTR account and verifying the usage values that come back.

  1. Create an API key. Create an API key in the LLMTR dashboard and store it in LLMTR_API_KEY in the process environment. Do not write the key into source code or version control.
  2. Set the service origin. Set LLMTR_BASE_URL to the LLMTR service origin. Keep your existing OpenAI client and change only the base URL and the model identifier.
  3. Choose the model and reasoning level. Use sakana/fugu-max as the model identifier. Choose high or xhigh as the reasoning level; low, medium and none are not valid on this model.
  4. Send the first request. Send one small, non-sensitive task to /v1/chat/completions or /v1/responses and set an explicit output budget.
  5. Verify the usage values. Read input_tokens, output_tokens, cached_tokens and the orchestration fields in the response usage block. Compute cost from those fields, not from total_tokens.

Frequently asked questions

Do I need to rewrite my OpenAI SDK code?

Usually no. Keeping the client and changing the base URL plus the model identifier is enough. Fugu Max works on both /v1/chat/completions and /v1/responses.

Which reasoning levels does Fugu Max accept?

Only high and xhigh. max is an alias for xhigh. low, medium, minimal and none are not valid on this model and are rejected with 400.

Can I get JSON output from Fugu Max?

Yes. Fugu Max supports both json_object and strict json_schema and returns plain JSON. On Fugu Ultra only json_schema is reliable.

Where can I see the orchestration tokens?

In the input_tokens_details and output_tokens_details fields of a /v1/responses response. The Chat Completions response stays faithful to the OpenAI shape and does not carry them.

Related posts