Pricing and benchmarks · 2026-09-11

Sakana Fugu Max Pricing: Orchestration Tokens and Real Cost

Sakana Fugu Max is flat-rated at $2 input, $6 output and $0.25 cache read per million tokens. See how visible tokens and billed tokens differ on a multi-agent model, with measured figures and a worked example.

Cost breakdown diagram separating ordinary input, cache reads, output and orchestration tokens for a single Sakana Fugu Max request.

Three line items, one rate

Sakana Fugu Max carries three price line items and all three are independent of context length: $2 input, $6 output and $0.25 cache read, per million tokens. The vendor's price card states this row is flat-rated, so a long prompt never moves the request into a more expensive band.

That is the first structural difference from Fugu Ultra, which moves into a second price band above 272,000 input tokens. Fugu Max has no such threshold. On long-context work whose size cannot be predicted in advance, that directly improves how reliable a budget estimate is.

LLMTR does not change model prices: the figure in the catalog is the provider's figure. The platform margin applies only to credit top-up and is shown as a separate line at checkout.

Sakana Fugu Max rate card — USD per 1M tokens, 11 September 2026
MetricPrice ($/1M tokens)
Input$2
Output$6
Cache read$0.25

Orchestration tokens: visible tokens are not billed tokens

On a multi-agent model the orchestrator's conversation with its expert agents also consumes tokens, and those tokens are billed at the standard input and output rates. Sakana reports them in separate usage fields: orchestration_input_tokens, orchestration_input_cached_tokens and orchestration_output_tokens.

The critical part is that these fields are not counted in the total. On a trivial request measured against fugu-ultra-v2.0 on 11 September 2026, prompt_tokens was 681, completion_tokens was 32 and total_tokens was 713. The identity 681 + 32 = 713 shows that the 1,260 orchestration input tokens reported in the same response sit entirely outside the total.

Code that computes cost from total_tokens therefore misses orchestration completely on a multi-agent model. The correct calculation reads the individual fields.

How large can the gap get?

On the same measurement day, a heavier request using a strict json_schema reported this on fugu-ultra-v2.0: 161 visible input tokens against 4,259 orchestration input tokens, and 361 visible output tokens against 482 orchestration output tokens.

A calculation that looks only at visible tokens would produce 161 x $5 + 361 x $30, roughly $0.0116 for that request. Computed over the real volume it is 4,420 x $5 + 843 x $30, roughly $0.0474. The visible figure accounts for about a quarter of the cost on that request; the gap is around 75%.

That ratio is not fixed. Orchestration volume grows with the difficulty of the work, so the gap widens on hard tasks. For your own workload the only reliable method is to measure.

On Fugu Max the orchestration fields return zero

The good news here is the opposite of what the heading above would suggest: on every Fugu Max request measured, the orchestration fields came back zero. Fugu Max folds its agent fan-out straight into prompt_tokens.

This was shown by measurement: when a 4,314-token prefix was sent a second time, prompt_tokens rose to 12,897 - a three-agent fan-out already reflected in the visible input count - and the orchestration fields were still zero. The token count you see on Fugu Max is not missing anything.

The practical consequence is that on Fugu Max a cost estimate can be made straight from the usage block, while on Fugu Ultra the orchestration fields have to be added separately. The two rows are in the same family, but their accounting is not the same, and carrying an assumption from one to the other is a mistake.

Worked example: the same request on two models

Assume 20,000 input tokens, of which 8,000 are read from cache and 12,000 are billed as ordinary input, and a response of 2,000 output tokens. This is an illustrative calculation, not a measured performance result.

Fugu Max: 12,000 x $2 + 8,000 x $0.25 + 2,000 x $6, all divided by one million, gives 0.024 + 0.002 + 0.012 = $0.038.

The same request in Fugu Ultra's standard band: 12,000 x $5 + 8,000 x $0.50 + 2,000 x $30, giving 0.06 + 0.004 + 0.06 = $0.124. That is roughly 3.3 times more, and it does not include the orchestration tokens Fugu Ultra bills on top.

Do not count cached tokens twice: cache reads are a subset of input. Subtract the cached portion from total input and charge the remainder at the ordinary input rate.

Comparison with other catalog rows

Every figure below comes from the LLMTR catalog rather than from a vendor comparison. Fugu Max has the lowest output price in this table; on cache reads, Claude Sonnet 5 is cheaper.

Do not make the comparison by looking at a single column. On a workload dominated by long outputs the output price decides it; on a workload that resends the same large prefix repeatedly the cache-read row takes over. Without knowing your own input, output and cache mix, the table does not make the decision for you.

Selected rows from the LLMTR catalog — USD per 1M tokens, 11 September 2026
ModelInputOutputCache readContext (tokens)
sakana/fugu-max$2$6$0.251,000,000
sakana/fugu-ultra$5$30$0.501,000,000
anthropic/claude-sonnet-5$2$10$0.201,000,000
moonshot/kimi-k3$3$15$0.301,048,576

Build the budget from measured usage

Record total billed output, cache-hit volume and retries across representative tasks. The reasoning level changes how much work the model may perform, so budget for the whole response rather than the length of the visible prose.

The response that shows a request's token breakdown in most detail is /v1/responses; the Chat Completions response stays faithful to the OpenAI shape and therefore does not carry the orchestration fields. The integration guide shows how to read them with an example.

LLMTR adds no margin to model prices. The platform margin is 8% and applies only to credit top-up: topping up 100 USD of credit is charged at 108.00 USD, and model rates are unchanged.

Frequently asked questions

How much does Sakana Fugu Max cost?

Per million tokens: $2 input, $6 output and $0.25 cache read. There is one rate and it does not change with context length.

What is an orchestration token, and is it billed?

It is a token the orchestrator spends talking to its expert agents, and it is billed at the standard input and output rates. It is reported in separate usage fields and is not counted inside total_tokens.

Is there a hidden orchestration cost on Fugu Max?

No. On every Fugu Max request measured, the orchestration fields came back zero; the model folds its fan-out straight into prompt_tokens. On Fugu Ultra those fields return above zero and have to be added separately.

Is Fugu Max more expensive at long context?

No. Fugu Max is flat-rated and context length does not change the price. Fugu Ultra moves into a second price band above 272,000 input tokens.

Does LLMTR add a margin to these prices?

No. Model rates are the provider's rates and are not changed. The 8% platform margin applies only to credit top-up and is shown separately at checkout.

Related posts