Every Fugu account faces the same recurring decision: send this task to base Fugu, or pay up for Ultra? The honest answer is more interesting than “Ultra is better” — Sakana’s own benchmark table has base Fugu winning several tests, and the cost structures differ in kind, not just degree. This is the decision guide: trade-offs, scenarios, and the math. Facts verified against Sakana’s official pages on August 19, 2026.
The one-paragraph difference
Both are trained orchestrators over a pool of frontier models — that’s the family architecture. Fugu optimizes the balance of performance and latency: it routes each task to the best model in the pool and bills you that model’s standard rate (top-tier rate when several are involved, never stacked). Fugu Ultra optimizes answer quality on hard problems: it draws on a deeper pool of expert agents, routes between one and three of them per problem, bills fixed per-token rates — and meters its internal teamwork as billed orchestration usage.
The three trade-offs
Cost: two different kinds of unpredictability
Neither model gives you a fully predictable per-request price, but they’re unpredictable differently. Base Fugu’s rate itself varies — a routine request routed to a modest model is cheap; a hard one that pulls in a top-tier model bills at that model’s rate. Ultra’s rates are fixed ($5 in / $30 out per million as of August 2026, roughly doubling above 272K context), but its orchestration overhead varies with task difficulty, and no output cap can bound it. Rule of thumb: base Fugu’s cost risk lives in the routing; Ultra’s lives in the overhead. The calculator models Ultra’s side; base Fugu you learn by reading a pilot batch’s usage.
Latency: balance vs. deliberation
Base Fugu is explicitly tuned to balance performance and latency — it’s the model Sakana defaults you to in its own coding-agent integration. Ultra’s multi-agent turns can genuinely run long: Sakana advises raising client timeouts for it, and configures its own integration with a two-hour stream idle allowance. Anything interactive-by-the-second belongs on base Fugu.
Quality: where the gap is real — and where it isn’t
Sakana’s June 2026 evaluation shows the gap is task-shaped, not uniform. Ultra leads clearly on agentic software engineering — 73.7 vs 59.0 on SWE Bench Pro, the widest spread in the table — and on multi-needle long-context retrieval (93.6 vs 86.6 on MRCRv2). But the two are nearly tied on much of the rest (GPQA-Diamond: both 95.5; LiveCodeBench: 93.2 vs 92.9; TerminalBench: 82.1 vs 80.2), and base Fugu actually leads on SciCode (60.1 vs 58.7), τ³ Banking (21.7 vs 20.6), and long-context reasoning (74.7 vs 73.3). All vendor-reported, June 2026, against baselines from leading frontier models.
Read that table honestly and the lesson is: Ultra buys you the most on hard, verifiable, multi-step engineering work — and roughly nothing on tasks a single strong model already saturates. More agents isn’t automatically better; it’s better where teamwork helps.
Scenario table
| Scenario | Pick | Why |
|---|---|---|
| Everyday coding assistant | Fugu | Latency-balanced, near-Ultra on general coding benchmarks, cheaper by design |
| Gnarly production bug nobody can find | Ultra (xhigh/max) | The verify-heavy, multi-step case Ultra was built for |
| Large refactor across a codebase | Ultra | Agentic software engineering is Ultra’s widest reported lead |
| High-volume pipeline (classify, extract, summarize) | Fugu | Volume work can’t carry Ultra’s overhead; routing keeps easy tasks cheap |
| Research analysis with a checkable answer | Ultra | Reported Ultra use cases: competitions, paper reproduction, literature review |
| Long-document Q&A (within 272K) | Try Fugu first | Base Fugu leads Sakana’s long-context reasoning test |
| Needle-in-haystack over huge context | Ultra | Clear Ultra lead on multi-needle retrieval (MRCRv2) |
| Latency-sensitive user-facing feature | Fugu | Ultra’s turns can run minutes; base is tuned for the balance |
The escalation pattern (use both)
The choice isn’t account-level — it’s per request, and the best-run setups treat it that way. Default everything to base Fugu. Escalate to Ultra on defined triggers: a task type with a known Ultra edge, a failed first attempt worth a second opinion, or stakes that justify a verification pass. Within Ultra, escalate effort the same way — high by default, xhigh/max per problem. Every subscription plan includes both models, so for hands-on use the escalation costs you nothing extra; on pay-as-you-go, it’s exactly what the usage telemetry is for.
One wrinkle worth knowing if you route through OpenRouter: only Ultra (and Sakana Namazu) are listed there as of August 2026 — base Fugu requires the direct Sakana API. Details in the OpenRouter guide.
Is base Fugu always cheaper than Ultra?
Usually but not axiomatically — base Fugu bills the underlying model’s rate, so a hard request routed to a top-tier model bills accordingly. What base Fugu never has is Ultra’s separately-metered orchestration overhead. For sustained workloads, base Fugu almost always comes out well ahead.
Do Fugu and Fugu Ultra use the same model pool?
Sakana describes Ultra as drawing on a deeper pool of expert agents and routing between one and three per problem, versus base Fugu routing each task to the best model in the supported pool. Exact pool membership isn’t published for either.
Is Ultra actually better than base Fugu?
On Sakana’s own June 2026 numbers: decisively on agentic software engineering and multi-needle long-context retrieval, marginally or not at all on much else, and base Fugu leads a few tests outright. Match the model to the task rather than defaulting up.
Can I switch between them mid-project?
Yes — it’s a per-request model choice on the same API and the same key, and both are included in every subscription plan. The escalation pattern (default base, escalate on triggers) is the practical way to run it.
Deeper dives: Fugu Ultra explained, the full pricing guide, and the cost calculator for your own numbers. Feel the difference yourself in the playground.