Sakana Fugu Ultra v2 Explained: The Orchestrator That Beats Frontier Models It's Not Even Allowed to Use

On September 11, 2026, Sakana AI shipped two new members of its Fugu family, Fugu Max and Fugu Ultra v2.0, and buried inside the release notes was one of the stranger sentences you will read in an AI model announcement this year: Claude Fable 5, Claude Fable 5.1, and GPT-6 Astra are explicitly not in Fugu Ultra v2's model pool [1]. Not "underperforms them." Not "was not tested against them." Not in the pool at all, by design, stated outright with no further explanation. And yet on the same release page, Sakana reports Fugu Ultra v2 scoring 48.3 on a benchmark called Chartography, ahead of Claude Opus 5's 27.3 and Claude Fable 5's 29.5, plus best-or-joint-best results on GDP.pdf, SWEFish, DeepSWE, and Toolathon, using nothing but open-weight models, specialist models, and its own routing intelligence [1] [9].

That combination is the real story here, and it is worth taking seriously as a technical question rather than a marketing curiosity. Fugu is not a single trained foundation model competing on the usual leaderboard terms. It is a trained coordinator, a comparatively small model whose entire job is deciding which of dozens of other models should handle each piece of an incoming task, then stitching their outputs back into one answer, delivered to the developer through a single OpenAI-compatible API that looks exactly like calling any other chat completion endpoint [2]. The pool it draws from includes open-weight models and specialist models, including NVIDIA's Nemotron family through a direct collaboration with NVIDIA [2], and pointedly excludes three of the most capable closed frontier models on the market. Sakana is making a very specific bet: that an orchestration layer sitting on top of a swappable pool of smaller, open, and specialist models can match or beat monolithic frontier models on real work, purely through learned routing, role assignment, and result synthesis, without needing the biggest single brain in the room.

This post is a deep technical look at what Fugu Max and Fugu Ultra v2 actually are, how the underlying orchestration research works, what the benchmark numbers do and do not show, why the pool exclusion probably exists, and what building on top of a system like this actually means in production. Miraflow covers a lot of individual frontier model launches on this blog; this one is different because the interesting engineering decision is not inside a bigger transformer, it is in the layer that decides which transformer gets the call.

What Fugu Actually Is: Orchestration as a Foundation Model

Every other major model release in 2026 has been a story about scale, more parameters, more training compute, a longer context window, a new architecture trick inside one network. Fugu's story is structurally different. Sakana's own framing is that Fugu is "a multi-agent system, delivered as one model" [2], meaning the product you call through the API is not itself the thing doing the reasoning end to end. It is a dispatcher.

The two papers underneath the product

Fugu did not appear out of nowhere. It sits on top of two pieces of published research from Sakana AI, both accepted at ICLR 2026, and understanding them is the fastest way to understand why Fugu behaves the way it does.

The first is TRINITY, described in the paper "TRINITY: An Evolved LLM Coordinator" [5]. TRINITY is a genuinely small coordinator, roughly a 0.6 billion parameter language model paired with a lightweight routing head of around 10,000 additional parameters, trained not through ordinary gradient descent on a loss function but evolved using a black-box optimization method called sep-CMA-ES (a separable variant of Covariance Matrix Adaptation Evolution Strategy). What that coordinator learns to do is orchestrate a pool of much larger external LLMs across multiple turns, assigning each participating model one of three roles for that turn: Thinker, Worker, or Verifier. A Thinker breaks a problem down or proposes an approach. A Worker executes a concrete piece of it, writing code, running a calculation, drafting a section of an answer. A Verifier checks the Worker's output for correctness before it gets folded into the final response. TRINITY's authors report state-of-the-art results on LiveCodeBench (86.2 percent) and consistent gains over both individual frontier models and prior coordination methods on coding, math, reasoning, and domain-knowledge tasks, along with reasonable generalization to task types the coordinator was never explicitly trained on [5].

The second is Conductor, from the paper "Learning to Orchestrate Agents in Natural Language with the Conductor" [6]. Where TRINITY assigns fixed roles, Conductor goes a step further: it is trained with reinforcement learning to discover its own coordination strategies from scratch, including designing the actual communication topology between agents (who talks to whom, in what order) and writing the natural-language instructions that get each worker model to lean into its own strengths. A roughly 7 billion parameter Conductor model reportedly achieves state-of-the-art results on LiveCodeBench and GPQA by orchestrating a pool of worker models that, individually, score well below it [6] [22]. One of the more interesting reported behaviors is that Conductor learned task-adaptive scaling on its own: for a simple factual question it might resolve the whole thing with one model or a two-agent exchange, while for a hard, multi-file coding problem it builds out a four-agent workflow with dedicated planning, implementation, and verification phases, without anyone hand-coding that escalation rule [6].

Fugu, as a shipped product, builds directly on both lines of work, described in Sakana's own technical report as production-oriented engineering on top of TRINITY and Conductor's research foundations [8]. That lineage matters for how you should think about Fugu: it is not a wrapper script calling an LLM API in a loop, it is itself a trained model, optimized end to end to get good at the specific skill of knowing which other model to call, in what order, with what instructions, and how to combine the results into a single coherent answer.

Why orchestration, and why now

The pitch only makes sense once you accept a premise that has become much harder to dismiss over the last year: no single model is best at everything, and the gap between "good at math," "good at long-horizon coding," "good at short factual lookups," and "good at visual reasoning" has not closed as fast as raw parameter counts have grown. A frontier lab training one enormous model has to make that model generalist by necessity, because it is the only tool in the box. An orchestration layer does not have that constraint. It can send a five-line factual question to a small, cheap model that answers it in 200 milliseconds, and send a genuinely hard multi-file refactor to a much larger reasoning-tuned model, and send a chart-reading task to a vision specialist, all inside the same customer-facing request, without the customer needing to know or care that three different models just did the work.

This is also why NVIDIA shows up inside Fugu's pool specifically, rather than Fugu training its own specialist models from scratch for every category. NVIDIA's Nemotron family already ships purpose-built variants for reasoning, tool use, and long-context agentic work, and licensing that specialization into a pool is a faster path to broad capability than retraining equivalents in-house [2]. The pool composition itself is not fully published; Sakana does not list every model inside it or expose per-request routing decisions to the caller, which is a deliberate design choice this post comes back to in the production section below, because it has real consequences for anyone trying to build a stable evaluation pipeline on top of Fugu.

A Short History: From Fugu Beta to Ultra v2

It helps to place Fugu Ultra v2 on a timeline, because "v2" language can make a release sound like a bigger architectural leap than it actually is here. Sakana's original Fugu shipped as a beta around April 2026, moved to general availability with the first Fugu Ultra roughly two months later in June 2026, and Fugu Ultra v2 followed in September 2026, about eleven weeks after that GA launch [3] [4] [1]. Eleven weeks is not enough time to retrain a foundation model's core weights from scratch in any meaningful sense. What it is enough time for is what Sakana actually describes: retuning the coordinator against the current generation of frontier and open models, refreshing the pool's composition, and re-optimizing the routing policy, with a coordinator training cutoff dated August 28, 2026 [1].

That distinction matters when you read marketing copy that leans on the word "new." Fugu Ultra v2 is best understood as a point-refresh of an existing orchestration architecture, not a new architecture. The core mechanism, an evolved or RL-trained coordinator dispatching Thinker, Worker, and Verifier roles across a pool, is the same one described in TRINITY and Conductor back in the ICLR 2026 papers [5] [6]. What changed by September is the pool's membership, the coordinator's tuning against newer competing models, and, as covered below, the pricing structure and the split into two distinct product tiers.

Fugu Max vs Fugu Ultra v2: Two Different Bets

Sakana did not just release one bigger model. It released two products aimed at genuinely different points on the cost-capability curve, and the difference is not cosmetic naming, it is a real routing-policy difference baked into the coordinator itself.

Fugu Max is priced at $2 per million input tokens and $6 per million output tokens, with $0.25 per million cached input tokens reported by some secondary coverage, though that cached figure should be treated as reported rather than fully confirmed pending Sakana's own published rate card [1] [11]. Its coordinator is tuned to lean harder into the cheaper end of the pool, routing more work toward open-weight and Nemotron-family models and reserving the most expensive calls for cases where the coordinator judges a cheaper model genuinely cannot do the job. Secondary reporting frames Fugu Max's pricing as 40 to 60 percent lower than Claude Sonnet 5, GPT-5.6 Terra and Sol, and Kimi K3, though that specific range is an outside estimate from coverage rather than a number Sakana states directly, so treat it as a directional claim rather than an audited figure [9].

Fugu Ultra v2 sits at the opposite end: $5 per million input tokens and $30 per million output tokens, with a separate, higher rate reported by secondary sources at $10 and $45 per million tokens respectively once a request's context climbs above 272,000 tokens, plus a cached-input rate around $0.50 per million tokens [12] [13]. Sakana's own materials describe this surcharge threshold as effectively unpublished in detail, so the exact numbers above come from independent reporting rather than an official rate card, and it is worth double-checking Sakana's live pricing page before budgeting a production workload around them. Ultra v2's coordinator, in contrast to Max's, is tuned to prioritize routing capacity toward complex reasoning, tool use, coding, and visual tasks, meaning it is more willing to reach for the pool's most capable and most expensive specialist models when the task actually calls for it.

Both products share the same headline infrastructure specs: a 1,000,000 token context window and a maximum output of 128,000 tokens per request [12] [13]. That is a large enough window to hand the coordinator an entire mid-sized repository, a lengthy contract, or a full research paper's supporting material in one call, though it is worth remembering that a 1 million token context window on an orchestration system does not necessarily mean every sub-model in the pool sees the full window on every hop; how much of that context gets passed to which worker on which turn is exactly the kind of routing decision the coordinator is trained to make and does not expose to the caller.

Both are also available immediately through the same OpenAI-compatible API that the original Fugu Ultra used, and Sakana describes the upgrade path for existing Fugu Ultra v1 customers as a one-line change, swapping the model identifier in an existing request without touching SDK code, authentication, or request shape [1]. That is a meaningful practical detail for anyone already integrated: this is not a new platform to onboard onto, it is a parameter change in an existing integration.

The Benchmark Numbers, and What They Actually Show

Benchmark claims from any lab are easy to skim past, so it is worth walking through exactly what Sakana reported for each product and being precise about what each number does and does not establish.

Fugu Ultra v2's reported scores

On Chartography, a benchmark focused on structured chart and document reasoning, Fugu Ultra v2 scored 48.3, ahead of Claude Opus 5's reported 27.3 and Claude Fable 5's reported 29.5 [1] [9]. On DeepSWE, a software-engineering benchmark, it scored 74.3 [1]. Sakana also reports Fugu Ultra v2 landing best or joint-best on GDP.pdf, SWEFish, and Toolathon, and one piece of independent coverage summarizes the overall picture as Fugu Ultra v2 placing among the top two systems on seven of eight tested benchmarks [1] [9]. On cost, secondary reporting frames Ultra v2's DeepSWE result as coming in at roughly three to five times cheaper per token than the systems it is compared against on that benchmark [9].

Fugu Max's reported scores

Fugu Max, the cheaper tier, led on six of ten tested benchmarks, including Terminal Bench 2.1, GPQA Diamond, AA-LCR, GDP.pdf, AutomationBench, and SWEFish, and is described in Sakana's own materials as extending the reported cost-performance Pareto frontier on seven of ten benchmarks, meaning that for a given price point, no other tested system reportedly beat it on those seven [1] [9].

What this actually proves, and what it does not

Here is the part that deserves genuine scrutiny rather than either uncritical acceptance or reflexive dismissal. The Chartography comparison is the single most interesting number in the whole release, because it directly outscores two models, Opus 5 and Fable 5, that are named competitors of the very lab, Sakana, publishing the comparison, using a benchmark methodology Sakana itself is running. That does not make the number false, and Chartography is a real, named benchmark rather than an invented one, but it does mean the comparison was not run as a live, identical-conditions shootout where all three systems answered the same prompts inside the same evaluation harness on the same day. Opus 5's and Fable 5's scores almost certainly come from those labs' own published benchmark results, reproduced by Sakana as a point of comparison, a completely standard practice in ML benchmarking, but one that always leaves room for differences in prompt formatting, scoring rubric interpretation, and evaluation harness version to shift a few points in either direction.

The more defensible reading of "top two on seven of eight" or "led on six of ten" is narrower than "Fugu beats every frontier model at everything," and it is a more interesting claim precisely because it is narrower: on a specific, named set of technical benchmarks, an orchestration system built from open and specialist models, with a training and routing budget almost certainly smaller than what goes into training a frontier model like Fable 5 or GPT-6 Astra from scratch, is landing in the same tier as those models on several evaluations. That is a genuine data point in favor of the orchestration thesis. It is not proof that orchestration has made single frontier models obsolete, and a careful reader should notice that Sakana reports being second-best, not best, on a meaningful share of the benchmarks it discloses, which is honestly a more credible signal than a lab claiming a clean sweep would be.

The Pool Exclusion: Why Fable 5, Fable 5.1, and GPT-6 Astra Aren't in the Pool

This is the detail that makes the release genuinely newsworthy rather than a routine model refresh, so it deserves the most careful treatment in this post. Sakana states, without elaboration, that Claude Fable 5, Claude Fable 5.1, and GPT-6 Astra are not in Fugu Ultra v2's model pool [1]. No reason is given on the release page. That silence has produced a fair amount of speculation across secondary coverage, some of it more careful than others, so it is worth separating what is actually documented from what is reasonable inference.

The real event this traces back to

There is a concrete, verifiable event that almost certainly shaped the original framing here, even if it does not fully explain the September 2026 exclusion on its own. On June 12, 2026, the US Department of Commerce's Bureau of Industry and Security ordered Anthropic to suspend access to Claude Fable 5 and Claude Mythos 5 for foreign nationals, citing national security and diversion-risk concerns, reportedly raised in part by concerns about jailbreak vulnerabilities [15]. Because Anthropic could not reliably screen users by nationality at the API layer, it disabled both models globally rather than risk violating the order, an eighteen-day period during which no one outside a narrow compliance path could use either model [14]. Sakana's original Fugu shipped its general-availability release with Fugu Ultra v1 in the middle of that same window, in June 2026 [3], and Sakana's marketing language from that period leaned directly into the moment, describing Fugu Ultra as standing "shoulder-to-shoulder with leading models like Anthropic's Fable 5 and Mythos Preview... while delivering frontier capability without the risk of export controls," language that reads very differently once you know it was written days after a real regulator had, in fact, just switched off access to those exact two models for a large share of the world [1].

Here is the detail that most of the SEO-farm coverage repeating that quote misses, and it is worth stating precisely because getting it right actually changes the analysis: the export control order was lifted on June 30, 2026. In a letter to Anthropic, Commerce Secretary Howard Lutnick stated that a license was "no longer required for the export, reexport, or in-country transfer... of the Mythos or Fable models," ending the eighteen-day restriction entirely [14] [16]. By the time Fugu Ultra v2 shipped on September 11, 2026, more than two months after the controls were lifted, Fable 5 and its successor Fable 5.1 were fully available worldwide through Anthropic's ordinary commercial API, with no export license required. That means the specific "no risk of export controls" framing, taken literally and applied to September 2026, is describing a regulatory situation that no longer existed by the time Fugu Ultra v2's pool exclusion was announced. The messaging appears to have outlived the event that originally justified it, which is a genuinely useful thing to flag for a technical reader evaluating Sakana's claims rather than repeating them.

What actually plausibly explains the exclusion now

If the original export-control episode does not fully explain a September exclusion, what does? None of this is confirmed by Sakana, and this section is explicitly analysis rather than a reported fact, but a few threads are worth pulling on.

First, GPT-6 Astra's own restrictions are a different kind of story entirely, and conflating it with the Fable 5 export-control episode is a mistake some coverage makes. GPT-6 Astra was released with OpenAI itself flagging that the model crossed a "Critical" capability threshold under its Preparedness Framework specifically for cybersecurity, meaning the publicly available version ships with restricted behavior around certain prompt categories tied to exploit development, not an export license requirement in the traditional sense [17]. Miraflow has covered GPT-6 Astra's cybersecurity threshold classification and what it actually restricts in detail in a separate post; the short version relevant here is that a model shipping under those kinds of self-imposed behavioral restrictions is an awkward fit for a general-purpose orchestration pool that wants predictable, unrestricted delegation across arbitrary task types, independent of any formal export control question.

Second, and probably the more mundane and more durable explanation, is straightforward API economics and philosophical positioning rather than any single regulatory event. Fable 5, Fable 5.1, and GPT-6 Astra are all closed, proprietary, metered APIs controlled entirely by their respective labs, with pricing, rate limits, and terms of service that can change unilaterally and with no guarantee of continued access. Sakana's own stated design philosophy for Fugu is explicit on this point, describing the pool's purpose as protecting users "from vendor lock-in, API revocations, geopolitical turbulence, and sudden service cutoffs" and stating plainly that "a swappable pool of agents guarantees supply chain resilience by design" [1]. A pool built around that philosophy has a structural reason to prefer open-weight models and specialist models Sakana can host, swap, or replace on its own timeline over models that live entirely inside a competing lab's commercial API and could be pulled, repriced, or throttled without warning, exactly what happened, however briefly, to Fable 5 in June. In that reading, the exclusion is not really about any one competitor being bad, it is a structural preference for supplier diversity and independence that happens to rule out any closed frontier lab's flagship model on principle, whether or not that specific model is currently under any regulatory cloud.

Third, it is worth taking seriously that Sakana simply has no commercial or technical reason to route paid customer traffic through a direct competitor's metered API even when there is no barrier stopping it, since doing so would mean Sakana paying Anthropic or OpenAI for every token routed to their models while also handing those labs visibility into Sakana's own customer workloads. A pool of open-weight and licensed specialist models avoids that dependency entirely.

The framing problem this creates

None of these explanations require Sakana to be acting in bad faith, but they do create a real framing tension worth naming directly. Sakana simultaneously claims Fugu Ultra v2 performs competitively with Fable 5 on named benchmarks while confirming Fable 5 was never actually part of the system being tested. That is not a contradiction, a system does not need to include a model in order to be benchmarked against that model's published scores, but it does mean the comparison is closer to "we compared our system's scores to their publicly reported scores" than "we ran a live match and won." Readers evaluating Fugu Ultra v2 for a real workload should treat every "matches" or "outperforms Fable 5" claim in Sakana's own marketing with exactly that caveat in mind, and should look for independent, same-harness benchmarking before making a purchasing decision based on Sakana's comparison numbers alone.

How This Compares to Mixture-of-Experts and to Single-Model Routing

Fugu is easy to misclassify if you only have two mental buckets for "how AI systems combine multiple models," a single dense model and a routing wrapper someone glued together. It sits in a third category that is worth defining precisely, because it borrows ideas from both without being either.

Mixture-of-Experts inside one model

Mixture-of-Experts, or MoE, architectures solve a related but genuinely different problem: how do you make one trained model behave as if it has many specialized sub-networks, without paying the full compute cost of running all of them on every token. The Switch Transformer paper, one of the foundational works in this space, introduced top-1 routing, where a lightweight router inside the model picks exactly one expert feedforward network out of many for each token, achieving up to a 7x pretraining speedup for the same compute budget compared to a dense model of similar quality [18]. Mixtral of Experts extended this with top-2 routing, activating two experts per token instead of one, trading a bit more compute for better quality per activated parameter [19]. DeepSeek-MoE pushed the idea further still with a much larger and finer-grained pool, activating a small number of experts, commonly cited as 8 out of 256 in DeepSeek's later architectures, and adding always-on shared experts that every token passes through alongside its routed specialists, aiming for tighter expert specialization than earlier top-1 or top-2 designs achieved [20].

The critical distinction: every expert inside a Switch Transformer, Mixtral, or DeepSeek-MoE model was trained together, inside the same model, sharing the same tokenizer, the same weight space, and the same training run. The router itself is also just another small trained component inside that same network. You cannot swap DeepSeek-MoE's experts for a different lab's experts without retraining the whole system, because the routing decisions and the expert weights co-evolved together during training. This makes MoE extremely efficient at inference time but architecturally rigid, the pool of experts is fixed the moment training finishes.

Fugu as inter-model orchestration

Fugu inverts that constraint. Its "experts" are not internal feedforward blocks trained jointly with the router, they are entire separate models, potentially built by entirely different organizations, exposed through entirely different APIs, with no shared training run, no shared tokenizer, and no shared weight space. What Fugu's coordinator learns is not how to route tokens between internal sub-networks, it is how to route entire sub-tasks, expressed in natural language, between independent black-box systems, and how to combine their independently generated outputs into one coherent response [5] [6]. This is a much harder coordination problem in some respects, since natural-language task decomposition and output synthesis are fuzzier and less controllable than routing a numeric activation vector to a matrix multiply, but it is also far more flexible: Sakana can add, remove, or swap a model in the pool at any time without retraining a single shared network, since the coordinator only needs to learn how to prompt and use whatever is currently available, not how to be structurally wired into it.

Single-model routing tools

The third category, and the one Fugu is most directly adjacent to conceptually, is the routing-layer pattern that has become common infrastructure in 2026: a lightweight router that picks which single frontier or open model should handle an entire incoming request, without any multi-agent decomposition inside that request. NVIDIA's NeMo Switchyard and Runway's Model Router both shipped in August 2026 as examples of this pattern, letting a developer route each step of an agent's workflow, or each generation request in a creative pipeline, to whichever specific model actually fits that step's cost, latency, and quality requirements, an idea Miraflow covered in detail in How to Route AI Requests to the Right Model Like NVIDIA NeMo Switchyard and Runway's Model Router. That pattern picks one model per request and hands the whole request to it. Fugu goes a level deeper: within a single request, its coordinator can decompose the task into multiple sub-steps and route each sub-step to a different model, with intermediate outputs from a Thinker or Worker model feeding into a subsequent Verifier or synthesis step, all before the caller sees a single response back. A NeMo Switchyard-style router answers "which model should handle this whole request." Fugu's coordinator answers "which models should handle each piece of this request, in what order, and how do their pieces combine."

It is worth being honest that this added flexibility comes with added latency and coordination overhead. A single-model router adds one routing decision to a request's total latency. A multi-agent orchestrator like Fugu can add several sequential or parallel model calls before returning an answer, which is part of why Sakana's pricing separates a comparatively fast, cheap Fugu Max tier from a more capability-forward, more expensive Ultra v2 tier tuned to accept more coordination overhead in exchange for harder task capability.

A Hypothetical Walkthrough: Routing a Complex Task Through Fugu Ultra v2

It helps to walk through a concrete, if hypothetical, example of what a single request to Fugu Ultra v2 might actually trigger under the hood, based on how TRINITY and Conductor describe their own coordination behavior [5] [6], since Sakana does not expose real routing traces to customers.

Imagine a developer sends Fugu Ultra v2 a single request: audit a 40,000-line monorepo for a subtle intermittent race condition in a background job queue, propose a fix, and write a regression test that reliably reproduces the original bug. This is exactly the kind of multi-step, ambiguous, high-stakes task the coordinator is trained to decompose rather than hand wholesale to one model.

A plausible routing sequence, consistent with the Thinker, Worker, Verifier framing from TRINITY [5], might look like this. First, the coordinator assigns a Thinker role to a strong reasoning-oriented model in the pool, tasked only with narrowing down which subsystems are plausible sources of a race condition based on the code structure and any provided logs, without yet writing any code. That narrowing step is cheap relative to the alternative of feeding the entire 40,000-line codebase into every subsequent step. Second, once a small number of candidate files are identified, the coordinator assigns a Worker role, likely a coding-specialist model tuned for exactly this kind of task, possibly a Nemotron-family model given Sakana's stated collaboration with NVIDIA [2], to actually trace the suspect code paths and draft a fix. Third, rather than trusting that fix blindly, the coordinator assigns a Verifier role to a separate model instance, whose only job is to check the proposed fix against the original bug report and flag anything that looks like it papers over the symptom rather than the cause, mirroring Conductor's reported four-agent workflow for hard coding problems, with dedicated planning, implementation, and verification phases [6]. Fourth, a final synthesis step, likely handled by the coordinator itself rather than another pool member, assembles the verified fix, a plain-language explanation of the root cause, and the requested regression test into the single response the developer actually receives.

The developer experiences none of this directly. They sent one request to one API endpoint and got back one coherent answer, with no visibility into how many separate models were actually involved, what roles they played, or how many tokens each one consumed internally versus how many showed up on the final bill. That opacity is a deliberate design choice, not an oversight, and it is exactly the tradeoff worth understanding before building anything serious on top of this kind of system, covered in detail in the next section.

A Wan-style cinematic animation, clean flat-color vector motion graphics rather than live-action or photoreal 3D, depicting an overhead air traffic control tower scene. The camera holds a steady top-down angle over a terminal gate map. A small glowing airplane icon labeled TASK enters from the top of the frame and travels along an animated dashed path toward a lit control tower console. From the console, a bright directional beam animates outward and splits into three thinner beams, each traveling to a different open gate labeled OPEN-WEIGHT MODEL, NEMOTRON SPECIALIST, and REASONING MODEL, each gate lighting up in sequence as its beam arrives. Meanwhile three gates near the edge of the frame remain dim and are crossed with animated caution tape, each labeled FABLE 5, FABLE 5.1, and GPT-6 ASTRA with NOT IN POOL beneath each. The three lit gates each emit a small returning beam back toward the control tower, which merges into a single beam traveling back out to the original TASK icon, now labeled RESPONSE, exiting the top of the frame. Smooth, even camera-locked motion, no camera shake, clean vector linework throughout with a thin technical-diagram border staying visible the whole time, no garbled or illegible text, no watermark or logo, no people.

Production Considerations: What "Pool Can Change Without Notice" Actually Means for You

This is the section a lot of coverage of Fugu skips past in favor of the more exciting benchmark numbers, and it is arguably the most important one for anyone actually planning to build a product on top of Fugu Max or Fugu Ultra v2 rather than just reading about it.

The pool is not disclosed, and routing decisions are not exposed

Sakana does not publish a complete list of every model inside Fugu's pool, and it does not expose per-request routing decisions to the customer. You cannot ask a Fugu Ultra v2 response which underlying model or models actually produced it, and Sakana's own documentation confirms the pool's composition "can change without notification" [12]. For most everyday use, that opacity is invisible and harmless, you get a good answer and move on. For a handful of real production scenarios, it is a genuine engineering and compliance risk that deserves upfront planning rather than a surprise discovery months into a deployment.

Regression testing gets harder

If your team maintains a suite of golden-output regression tests against a model API, a common and reasonable practice for anything customer-facing, those tests implicitly assume the thing answering your prompts today is roughly the same thing that will answer them next month. With Fugu, that assumption does not hold. The coordinator itself might get retuned, and independent of that, the pool it draws from can be reshuffled, a model added, removed, or replaced with a newer version, at any time, without a version bump you can pin against. A prompt that reliably produced a certain style, format, or level of caveats last week might route to a different underlying specialist next week and come back meaningfully different, even though your code called the exact same model identifier both times. Teams building anything sensitive to output consistency should build evaluation suites that check for acceptable output properties and ranges rather than exact-match or narrow-similarity comparisons, and should re-run their full eval suite on some regular cadence rather than assuming a stable baseline.

Compliance and data handling questions get harder to answer

If a customer, an auditor, or a regulator asks "which specific model or vendor processed this data," the honest answer for a Fugu-routed request may be "we do not know, and Sakana does not tell us," since the coordinator's routing decisions are internal and undisclosed [12]. For workloads touching regulated data, healthcare records, financial data, anything under a specific data residency or sub-processor disclosure requirement, that opacity can be a genuine blocker, not a minor inconvenience, and it is worth confirming Sakana's own data processing terms and sub-processor list directly rather than assuming standard API terms cover this correctly. This sits alongside a separate, simpler restriction worth flagging early: neither Fugu Max nor Fugu Ultra v2 is currently available in the EU or the EEA while Sakana works toward GDPR compliance [12] [13], which rules the product out entirely for teams building for that region regardless of how the routing-transparency question ultimately resolves.

Cost estimation is workload-shape dependent, not a flat discount

The 40 to 60 percent cost claims for Fugu Max and the three to five times cheaper DeepSWE claim for Ultra v2 are real, reported figures, but they describe specific benchmark workloads, not a flat discount you should assume applies uniformly to your own traffic [9]. A workload made up mostly of simple, short requests will see the coordinator route heavily toward the pool's cheapest models, capturing most of the advertised savings. A workload that consistently demands the hardest end of the coordinator's judgment, long documents, multi-step agentic tool use, hard reasoning, will see the coordinator reach for the pool's most capable, and therefore most expensive, members far more often, eroding the headline discount. Budgeting for Fugu in production means running your own representative traffic through it and measuring actual routing behavior, not extrapolating from Sakana's published benchmark cost ratios.

The 272,000 token surcharge threshold is easy to trip accidentally

Because the reported long-context surcharge kicks in above 272,000 input tokens on Fugu Ultra v2 [12], any workflow that concatenates several documents, a large retrieved context window, or a long conversation history into one request can cross that threshold without anyone deliberately choosing to send a "long context" request. Teams working with the full 1,000,000 token window should track where their typical request sizes actually land relative to that 272,000 token line rather than assuming standard pricing applies throughout the entire advertised window.

Where This Fits: Real Tools and the Broader Orchestration Trend

Fugu is not happening in isolation. It sits inside a broader 2026 pattern where more of the industry is questioning whether the next competitive edge comes from a bigger single model or a smarter layer deciding which of several existing models to use. NVIDIA's NeMo Switchyard and Runway's Model Router represent the single-model-per-request end of that pattern, useful when you know in advance which model fits which step of your pipeline and mostly need an efficient way to dispatch to it, a pattern Miraflow's earlier post on the topic walks through with real production architecture examples. Open-weight Mixture-of-Experts releases like NVIDIA's own Nemotron 3 Ultra, a 550 billion parameter hybrid Mamba-Attention MoE model, and Tencent's Hy4 Preview, a 770 billion parameter open-weight model, represent the internal-routing end, packing specialization inside one set of weights you can download and run yourself. Fugu occupies the space between those two patterns, external multi-model orchestration with learned, task-adaptive decomposition, closer in spirit to what a well-run engineering team building a genuine multi-agent system by hand would do, except trained end to end as a product rather than assembled as custom infrastructure.

The same underlying philosophy, route each piece of work to whichever specialized tool actually fits it rather than forcing one generalist system to do everything, shows up well outside of pure text and code generation too. Creative AI tooling increasingly works the same way under the hood: a platform generating a finished piece of content typically pipes the script, the visuals, the video, and the audio through separate, purpose-built generation pipelines rather than asking one model to handle every modality equally well. Miraflow's own browser-based content workflow reflects that same idea, generating a script, scene visuals, a cinematic video clip, a thumbnail, and a soundtrack through distinct specialized stages rather than one generalist pass, whether that is turning a topic into a finished short in Text2Shorts, building a cinematic clip through the AI video generator, producing artwork and thumbnails through the AI image generator, or scoring the result through the AI music generator. It is the same core engineering intuition Sakana is betting on at a much larger, more general scale: specialization plus smart routing tends to beat forcing one system to be good at everything at once.

Common Mistakes When Evaluating or Building on Fugu

A handful of specific misreadings come up repeatedly in early coverage and early adopter discussion of Fugu Max and Fugu Ultra v2, and they are worth naming individually rather than lumping into one generic warning, since each one leads to a different bad decision.

Treating "beats Fable 5 on Chartography" as a same-conditions head-to-head result. As covered above, Fable 5's and Opus 5's scores in Sakana's comparison table almost certainly come from those labs' own separately published benchmark runs, not a live, identical-harness shootout against Fugu Ultra v2 on the same day. That does not make the comparison meaningless, but it does mean you should look for independent, same-harness benchmarking before making a purchasing decision purely on Sakana's own comparison table.

Assuming the pool exclusion is a permanent, stable competitive fact. Because pool composition is undisclosed and can change without notice, there is no guarantee that a model excluded today stays excluded next quarter, or that a model included today stays included. Building a competitive analysis or a vendor selection document around "Fugu never uses Fable 5" is building on a fact that Sakana has given itself explicit latitude to change.

Assuming the advertised cost savings apply uniformly to your workload. As detailed in the production section above, the headline discount figures describe specific benchmark workloads. A workload that is mostly simple requests will see much larger savings than a workload that consistently demands the coordinator's most expensive routing decisions.

Building regression tests that assume a stable model identity behind a stable model name. A prompt that returns consistent output today can route to a different pool member next month with no version signal indicating the change happened, since the coordinator's internal routing is not exposed. Evaluation suites need to check for acceptable output ranges, not exact continuity, when testing against Fugu.

Reading "top two on seven of eight benchmarks" as "wins everything." Sakana's own disclosed numbers show it landing second-best on a meaningful share of tested benchmarks, not first on all of them. Treating this as a categorical claim that orchestration has made frontier single models obsolete overstates what the actual disclosed numbers say.

Ignoring the EU and EEA availability gap during vendor selection. Teams evaluating Fugu for a product with European users or European data residency requirements need to confirm regional availability and compliance status directly with Sakana before committing engineering time to an integration, since neither product currently serves that region [12].

Repeating the "no risk of export controls" framing as a current, active fact rather than a reference to a specific regulatory episode that was resolved in June 2026, well before Fugu Ultra v2 shipped. Understanding that timeline matters for accurately assessing why the pool exclusion exists today rather than accepting outdated messaging at face value.

Conclusion

Fugu Ultra v2 and Fugu Max are worth paying attention to for a reason that has little to do with any single benchmark score and everything to do with a structural question the whole industry is quietly working through: does the next real gain in AI capability come from training one bigger model, or from getting smarter about combining the capable models that already exist. Sakana's answer, backed by real published research in TRINITY and Conductor and now shipped as a commercial product with genuinely competitive benchmark numbers on several named evaluations, is a serious, well-evidenced argument for the second path, at least for a meaningful slice of real-world tasks. The explicit exclusion of Claude Fable 5, Claude Fable 5.1, and GPT-6 Astra from the pool is the most quotable detail in the release, and tracing it back to a real regulatory episode from June 2026 rather than accepting the vendor-lock-in framing at face value is exactly the kind of scrutiny a claim like this deserves. None of that undermines the more durable, structural argument Sakana is actually making, that a swappable pool of open and specialist models avoids a real and repeatedly demonstrated risk, a single vendor's API disappearing without warning, that closed frontier models have already shown themselves capable of doing, however briefly, in the same year this product shipped. Whether orchestration keeps pace with frontier single models as both approaches keep improving is a genuinely open question, and one worth revisiting the next time either side publishes a real, independently verified head-to-head result.

Frequently Asked Questions

What is Sakana Fugu, in one sentence? Fugu is a multi-agent orchestration system, a trained coordinator model, delivered to developers through a single OpenAI-compatible API as if it were one ordinary language model, that actually dispatches sub-tasks across a swappable pool of open-weight and specialist models, including NVIDIA's Nemotron family, and synthesizes their outputs into one response [2].

Is Fugu Ultra v2 a new base model, or a refresh of the original Fugu Ultra? It is best understood as a point-refresh rather than a new architecture. The coordinator's core mechanism traces back to the TRINITY and Conductor research from earlier in 2026, and Fugu Ultra v2 shipped roughly eleven weeks after the original Fugu Ultra's June 2026 general availability launch, with a retuned coordinator, a training cutoff of August 28, 2026, and a refreshed pool composition, rather than a wholesale architectural change [1] [3].

Why are Claude Fable 5, Claude Fable 5.1, and GPT-6 Astra excluded from Fugu Ultra v2's pool? Sakana does not give an official reason. The most defensible explanation, based on available evidence, combines a real regulatory episode, a June 2026 US export control order that briefly disabled Fable 5 and Mythos 5 for foreign nationals, later lifted on June 30, 2026, with a more durable structural preference: Sakana's stated design philosophy explicitly favors a swappable pool of open and licensable models to avoid vendor lock-in and sudden API cutoffs, which structurally disfavors including any closed competitor's flagship model regardless of its current regulatory status [1] [14].

Does the exclusion mean Fugu Ultra v2 cannot actually outperform those models? Not necessarily, and Sakana's disclosed benchmark numbers show Fugu Ultra v2 outscoring Claude Opus 5 and Claude Fable 5's reported scores on the Chartography benchmark specifically [1]. But the comparison uses those models' own separately published scores rather than a live, same-harness test against a version of those models actually running inside the evaluation, so it should be read as a benchmark-score comparison rather than a head-to-head match.

What's the actual difference between Fugu Max and Fugu Ultra v2? Pricing and routing priority. Fugu Max costs $2 per million input tokens and $6 per million output tokens, with a coordinator tuned to lean toward cheaper pool members. Fugu Ultra v2 costs $5 per million input tokens and $30 per million output tokens, plus a reported higher rate above 272,000 tokens of context, with a coordinator tuned to prioritize routing toward the pool's most capable models for complex reasoning, coding, tool use, and visual tasks [1] [12].

Can I see which underlying model actually answered my request? No. Fugu's routing decisions and full pool composition are not exposed to the caller, and Sakana's documentation states the pool can change without notification [12]. This is a deliberate design choice, not a missing feature, and it has real implications for regression testing and compliance documentation covered in the production considerations section above.

Is Fugu available in the EU? No, as of the September 2026 release neither Fugu Max nor Fugu Ultra v2 is available in the EU or EEA, while Sakana works toward GDPR compliance [12] [13].

How is this different from building my own model router with something like NeMo Switchyard? A tool like NeMo Switchyard or Runway's Model Router typically picks one model to handle an entire incoming request based on rules or a lightweight classifier you configure yourself. Fugu's coordinator can decompose a single request into multiple sub-steps and route each one to a different model, with intermediate results feeding into later steps, entirely automatically and without you designing that decomposition logic, at the cost of losing visibility into exactly how that decomposition happened. Miraflow's guide to routing AI requests like NeMo Switchyard and Runway's Model Router covers how to build the simpler, single-model-per-request version of this pattern yourself.

References

1. Sakana AI, "Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier" — sakana.ai/fugu-max-release
2. Sakana AI, "Fugu — A Multi-Agent System, Delivered as One Model" — sakana.ai/fugu
3. Sakana AI, "Sakana Fugu: One Model to Command Them All" — sakana.ai/fugu-release
4. Sakana AI, Fugu beta announcement — sakana.ai/fugu-beta
5. Sakana AI et al., "TRINITY: An Evolved LLM Coordinator," arXiv:2512.04695 — arxiv.org/abs/2512.04695
6. Sakana AI et al., "Learning to Orchestrate Agents in Natural Language with the Conductor," arXiv:2512.04388, ICLR 2026 — arxiv.org/abs/2512.04388
7. Sakana AI, "Learning to Orchestrate" (blog summary of the Conductor paper) — sakana.ai/learning-to-orchestrate
8. Sakana AI, Fugu Technical Report, arXiv:2606.21228 — arxiv.org/abs/2606.21228
9. AlphaSignal, "Sakana AI Splits Fugu into Max and Ultra v2 to Cut Costs 60%" — alphasignal.ai/news/sakana-ai-splits-fugu-into-max-and-ultra-v2-to-cut-costs-60
10. MarkTechPost, "Sakana AI Launches Fugu Max and Fugu Ultra v2 for Cheaper, Stronger Multi-Agent Orchestration" — marktechpost.com
11. DataNorth AI, "Sakana AI Launches Fugu Max and Fugu Ultra v2" — datanorth.ai/news/sakana-ai-launches-fugu-max-and-fugu-ultra-v2
12. OrcaRouter, "Sakana Fugu Ultra v2: A Smaller Pool, a Higher Score" — orcarouter.ai/blog/fugu-ultra-v2-explained
13. The Robotics Media, "Sakana AI Ships Fugu Ultra v2.0, a 1M-Token Multi-Agent Orchestration Model" — theroboticsmedia.com
14. CNBC, "Anthropic Says Trump Admin Has Lifted Export Controls on Claude Fable 5 and Mythos 5" — cnbc.com
15. Forbes, "Anthropic Disabled Fable 5 and Mythos 5 After a U.S. Export-Control Order. Here's What Happened" — forbes.com
16. Forbes, "Anthropic Wins as Commerce Lifts Fable 5 and Mythos 5 Export Controls" — forbes.com
17. OpenAI, "GPT-6 Astra: The Next Generation in Intelligence for Work" — openai.com
18. Fedus, Zoph, Shazeer, "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity," arXiv:2101.03961 — arxiv.org/abs/2101.03961
19. Jiang et al., "Mixtral of Experts," arXiv:2401.04088 — arxiv.org/abs/2401.04088
20. Dai et al., "DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models," arXiv:2401.06066 — arxiv.org/abs/2401.06066
21. NVIDIA Developer Blog, "Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard" — developer.nvidia.com
22. VentureBeat, "How Sakana Trained a 7B Model to Orchestrate GPT, Claude and Gemini LLMs" — venturebeat.com