Sakana Fugu Review: Versions, Orchestration Tokens and Cost

Sakana Fugu is worth evaluating as an orchestration service, not judging from a chart of other models. This review uses two actual Fugu entries already in our archive and separates them from the current direct-API contract. Both archived configurations scored 9/9 on small Python tasks, but their derived costs differed sharply. That does not answer whether either is better at complex Agent work.

Pick a Fugu version before comparing results

The current Sakana model documentation includes Fugu, Ultra, Max, and Cyber. Its direct API maps fugu-ultra to fugu-ultra-v2.0 and fugu-max to fugu-max-v1.0. Use an explicit version for a reproducible evaluation, and distinguish these direct IDs from an intermediary's model names.

Those are provider descriptions, not independently established rankings. Contact the provider about required data or pool constraints instead of assuming every Fugu variant supports the same exclusions.

Current direct prices are not the historical OpenRouter bill

As checked October 12, Sakana publishes these USD rates per million tokens. Ultra's higher rate applies when context exceeds 272K; Max's listed rate does not change with context length. Sakana pricing

Sakana also lists separate Max tool-call charges. Read the rate applicable to the route and operation you select; a direct rate table is not a quote for a gateway account or proof of a completed request's charge.

Orchestration is additional billable work

For Ultra and Cyber, Sakana exposes fields for orchestration input, cached orchestration input, and orchestration output alongside user-visible input and final output. These are chargeable work, not annotations that can be discarded when estimating cost. Usage field documentation

For a new request, retain the complete usage object and provider statement. Check which cached counts are subsets before subtracting them, and do not add total_tokens to its component counts. Missing categories should be investigated rather than silently treated as zero.

One important limit is easy to misread: for Ultra, the documented final-output ceiling does not cap the orchestrator's token use. A small max_output_tokens is therefore not an all-in spending limit. Apply an approved request budget and deadline through the controls actually supported by the provider and your application. A client timeout is not proof that provider-side processing or billing stopped.

Our two archived Fugu runs

The published archive records two OpenRouter configurations on September 16, using September 15 captured prices:

Each cost is reported token usage multiplied by the stored historical rates and normalized from nine tasks. These are not invoices for 1,000 executions. The exact intermediary IDs, dates, scores, token counts, and stored display costs are preserved; this revision did not call either model.

Ultra's recorded input count is much larger in this sample. That observation does not identify which internal agent read which material. Nor can today's direct-API usage categories be retroactively inserted into an old intermediary record. Preserve the original schema instead of claiming a reconstruction that the archive cannot support.

The token-accounting finding survives the consolidation

The separate Fugu benchmark page used these same September records. For Ultra, the input component is 60,645 x $5 / 1,000,000 = $0.303225 for nine tasks; output is 7,011 x $30 / 1,000,000 = $0.210330. Their sum, normalized from nine tasks, is $57.061666.... This is why a cheap input rate can still be the larger cost component.

The old page also reported visible reasoning-token fields. A small exposed reasoning count cannot establish how much internal deliberation or orchestration occurred. The retained input total is an endpoint report; it does not identify system prompts, hidden agents or retry billing. Those unsupported causal claims are not carried into the merged review.

What the equal score cannot answer

Nine short Python functions are not research orchestration, repository maintenance, or a sustained tool loop. Both variants passed this small set. The score is saturated and does not rank their capabilities above that level.

The sample supports a narrow cost observation under dated settings. It does not establish that orchestration is universally wasted, that Max is always superior, or that a fixed percentage of work should use a cheaper model. The previous article's unsupported 80/20 rule and unrelated model chart are no longer the evidence for this review.

The shared methodology and coding benchmark describe the harness. They do not replace a complex-task Fugu comparison.

Distinguish orchestration from routing control

A gateway can translate or route requests, while an application can coordinate its own sequence of model and tool calls. Fugu performs coordination within the service. These arrangements put routing decisions, data handling, and observability in different places; they are not interchangeable products.

Do not assume every gateway exposes all underlying routing or that every Fugu plan permits the same steering. For the intended route, ask what is visible, which data reaches other agents, which exclusions are enforceable, and which usage fields support reconciliation. See the orchestrator-executor explanation for the application-layer design.

Evaluate a hard task with explicit stopping conditions

Pick a task where a strong single-model baseline has a documented failure or limitation. Fix the inputs and acceptance criteria first. Then compare that baseline with the exact Fugu version under an approved spending and time budget.

Retain the final answer, checks, full usage, tool fees, retries, elapsed time, and review effort. Stop on an exceeded budget, a forbidden operation, a loop without progress, or an output that cannot be independently checked. Do not give the orchestrated configuration extra attempts without recording their cost.

This is an evaluation proposal. No new complex Fugu workflow, access application, security task, or production deployment was performed for this revision. For an operational failover rather than a quality comparison, the routing guide addresses a separate problem.

Conclusion: evaluate the whole request

The useful Sakana Fugu review question is whether accepted work justifies total billable coordination on the selected version. Our two dated small-task records show why final-answer size and list rates are not enough. They leave complex-task value unmeasured.

FAQ

Did DataLLM Lab actually test Fugu?

The published archive includes September 16 Max and Ultra v2 small-task runs. This revision uses those existing records; it did not perform a new model or Agent test.

Does a short final-output limit cap the whole Fugu bill?

Not for Ultra under the documented contract. Its orchestration work is separate from the final-output ceiling. Use actual supported budget controls and reconcile the full usage.

Does the 9/9 tie prove the variants are equally capable?

No. It establishes completion on nine short functions, not research, long-context reliability, or production Agent quality.