Sakana AI, based in Tokyo, shipped Fugu Max and Fugu Ultra v2 on September 11, 2026, and the interesting part isn't the benchmark numbers — it's the architecture. Fugu Ultra v2 is exposed through a single OpenAI-compatible API, priced at $5/$30 per million input/output tokens with a 1M-token context window, but under that API it isn't one model. It's an orchestration engine: a model trained to route a task across a fixed pool of open-weight and specialized models, and to recursively call instances of itself to break a problem into sub-tasks.
That's a genuinely different design point from "one bigger transformer," and it's worth understanding the tradeoff before deciding whether it changes anything for a project that already has its own multi-model routing logic.
What "orchestration as a model" actually means
Most teams doing multi-model routing today build it themselves: a thin router that classifies an incoming request, sends visual reasoning to one model, code generation to another, and cheap classification tasks to a small fast model, then stitches the results together. Fugu Ultra v2 packages that pattern behind a single API call — you send one request, and the routing, sub-task decomposition, and recursive delegation to specialist models happen behind the endpoint rather than in your own code.
The reported benchmark result that got attention is on Chartography, a visual reasoning and data-interpretation benchmark, where Fugu Ultra v2 scored 48.3 against 27.3 for Opus 5 and 29.5 for Fable 5. That gap is plausible precisely because it's not a fair comparison of raw model capability — it's a comparison of "one model doing everything" against "a routing layer that hands the visual-reasoning sub-task to whichever pool model is actually good at it." An orchestration layer can beat a monolithic model on tasks that decompose well into specialist sub-tasks, without needing a bigger or smarter base model.
Where the build-vs-buy line actually sits
If your team already maintains a router like this:
def route_request(request):
task_type = classify(request) # cheap, fast model
if task_type == "visual_reasoning":
return call_model("vision-specialist", request)
elif task_type == "code_generation":
return call_model("code-specialist", request)
else:
return call_model("general-purpose", request)Fugu Ultra v2 is a bet that this routing logic, plus the harder parts (recursive decomposition, sub-task result aggregation, failure handling when a pool model errors out) are worth buying as a managed capability instead of maintaining as in-house infrastructure:
response = client.chat.completions.create(
model="sakana/fugu-ultra-v2",
messages=[{"role": "user", "content": complex_multi_part_task}],
tools=tool_definitions,
)The API surface looks identical to calling any single model. The actual value proposition is that Sakana owns the pool composition, the routing logic, and the recursive-call budget, so you're not maintaining that layer yourself. The cost, correspondingly, is that you don't control which specialist models are in the pool, how routing decisions get made, or how a routing mistake gets debugged when the orchestration layer picks the wrong specialist for a sub-task.
What to actually check before adopting this pattern
- Cost behavior under recursion. A model that can call itself recursively to decompose a task has a cost profile that's harder to predict than a single-call model — a task that decomposes into an unexpectedly large number of sub-tasks can multiply cost in ways a flat per-request budget doesn't anticipate. Test against your actual task distribution, not the advertised per-token price, before committing to it in a cost-sensitive pipeline.
- Latency from orchestration hops. Routing to a specialist model, then recursively routing a sub-task to another, adds round-trips that a single-model call doesn't have. For latency-sensitive interactive use cases, measure end-to-end response time against your current setup, not just throughput.
- Debuggability when routing goes wrong. If your own router misroutes a request, you can inspect and fix the classification logic directly. If Fugu Ultra v2's internal routing sends a sub-task to the wrong specialist, you're debugging a black box you don't control the internals of.
- Where it plausibly wins. Tasks that genuinely decompose into distinct specialist sub-problems — visual/data interpretation combined with reasoning, multi-format document analysis — are the class of workload where an orchestration-native model has a real structural advantage over a single general-purpose model. General chat or single-domain coding tasks are less likely to benefit from the orchestration overhead.
Our take
Fugu Ultra v2 is best understood as a data point in a broader shift: as base model capability differences compress, the interesting competition is moving to the orchestration layer above the model — how tasks get decomposed, routed, and recombined. Whether to adopt an orchestration-as-a-product model instead of maintaining your own routing layer depends on whether your actual workload decomposes well into specialist sub-tasks, and whether you're willing to trade routing control and debuggability for infrastructure you don't have to maintain. Benchmark it against your own task distribution and cost profile before treating the published numbers as representative of your use case.
References: Sakana AI Launches Fugu Max and Fugu Ultra v2 — MarkTechPost, Fugu Ultra v2 — API Pricing & Providers (OpenRouter), Sakana AI Ships Fugu Ultra v2.0 (The Robotics Media)