Sakana AI launched a new product today, June 22, 2026, that takes a fundamentally different architectural approach to delivering frontier capability than the rest of the major AI labs. The product is called Sakana Fugu, with two tiers: Fugu (the lower-latency default) and Fugu Ultra (the higher-capability flagship). The launch matters because Fugu is not a monolithic LLM in the conventional sense. It is a multi-agent orchestration system delivered as a single foundation model with a single OpenAI-compatible API endpoint, where the underlying behavior is one model routing requests across a swappable pool of frontier LLMs from multiple vendors, verifying and synthesizing the results, and producing a unified response. The architecture is Sakana’s bet that the next phase of frontier-AI development is about coordination of multiple models rather than the continued scaling of single models.
This piece is the foundational pillar on Sakana Fugu. We cover what the product is, the architectural thesis behind it, the company that built it, the two product tiers, the technical research that grounds the design, the benchmark results Sakana published with the launch, the operational implications of the swappable-model approach, the customer positioning, and the place Fugu occupies in the broader frontier-model landscape. Later in the week, we will publish dedicated deeper-dive pieces on Fugu (the default tier) and Fugu Ultra (the flagship) with hands-on operational guidance for each.
The short version is that Sakana Fugu is the production form of a multi-year research thesis from Sakana AI about collective intelligence in language models. The company’s name, Sakana, means "fish" in Japanese, evoking schools of small fish coordinating to produce capability that exceeds any individual member. Fugu means pufferfish: a fish that expands itself in response to threats, swelling to many times its baseline size. The naming is the architectural metaphor. Fugu the model expands its effective capability by recruiting and coordinating other models, producing a single response that draws on whatever combination of underlying models was best-suited for the specific request.
What Sakana AI is
Sakana AI was founded in 2023 in Tokyo by David Ha and Llion Jones. Ha was previously at Google Brain Tokyo and at Stability AI; Jones was a co-author of "Attention Is All You Need" at Google, the 2017 paper that introduced the transformer architecture that powers every modern LLM. The company’s research focus from inception has been nature-inspired AI: drawing on biological and evolutionary patterns for AI architecture, rather than the dominant pattern of training ever-larger transformers on ever-larger datasets.
The company’s positioning is uncommon in the frontier-AI market. Most frontier-AI labs are US-headquartered and English-language-first. Sakana is Tokyo-headquartered and explicitly positioned as a Japanese AI lab with sovereign-AI value for Japan and the broader Asia-Pacific region. The funding pattern reflects the positioning: Sakana’s Series B in November 2025 ($135M at $2.65B post-money) brought the total raised to approximately $379M, with backers including most of the major Japanese megabanks (MUFG, SMBC, Mizuho), Japanese strategic investors (NEC, ITOCHU, KDDI, Fujitsu, Nomura, Tokyo Marine), and US venture firms (Khosla, Lux, NEA). The cap table is one of the more geographically diverse in frontier AI.
The customer focus is similarly distinctive. Sakana has been explicit about targeting Japanese enterprise customers in defense, banking, industrial, manufacturing, and government sectors. The company’s pitch is sovereign frontier AI for Japan: capability comparable to the US labs’ offerings, with the data residency, the regulatory familiarity, and the strategic alignment that a Japanese vendor can provide that a US vendor cannot. The launch of Fugu is the most concrete manifestation of this strategy yet.
The research output that grounds the product has been substantial. Sakana’s earlier work includes "Evolutionary Optimization of Model Merging Recipes" (which produced the merged-model approach the company has used in several earlier products), "The AI Scientist" (an automated research agent that proposes, runs, and writes up scientific experiments), and the broader multi-agent collaboration work. Fugu builds directly on two more recent papers presented at ICLR 2026: TRINITY (the multi-agent verification framework) and Conductor (the cross-model orchestration approach). Both papers are publicly available on arXiv and are useful reading for understanding what Fugu does under the hood.
The architectural thesis
The dominant approach in frontier-AI development through 2024 and 2025 was to train larger models on larger datasets and watch capability emerge as a function of scale. The approach worked. The frontier models of 2026 (Opus 4.8, GPT-5.5, Gemini 3 Pro) are dramatically more capable than the frontier models of 2024 (GPT-4, Claude 3 Opus, Gemini 1.5 Pro), and most of the improvement came from continued scaling.
Sakana’s thesis is that the next phase of capability improvement will come less from continued single-model scaling and more from coordination among models. The argument has several pieces. First, the marginal cost of training a single model that beats the current frontier is increasing rapidly. Each new generation of frontier model has been substantially more expensive to train than the previous one, and the rate of capability improvement per dollar of training compute has been declining. Second, no single frontier model is best at everything. Opus is strongest on long-horizon coding; GPT-5.5 is strongest on agentic tasks; Gemini 3 Pro is strongest on long-context retrieval. A model that could route each request to whichever underlying model is best for it would produce better aggregate capability than any single model could. Third, the economic and architectural risk of depending on any single model provider has become more visible after the recent restrictions and suspensions in the frontier-model market. An orchestration approach insulates customers from this risk.
Fugu is the production answer to this thesis. The architecture is that Fugu itself is an LLM trained specifically to route, delegate, verify, and synthesize. When a request comes in, Fugu’s router decides whether the request is best handled by one of the swappable underlying frontier models (currently including Opus 4.8, GPT-5.5, Gemini 3 Pro, and several open-weight models), or by Fugu itself, or by a recursive call to a sub-instance of Fugu. The router’s decision is informed by the request’s content, by the historical performance of the underlying models on similar requests, by the customer’s configuration about which models are eligible, and by the cost and latency budget that the request carries.
When an underlying model is invoked, Fugu’s verification layer checks the response for quality, consistency with other recent responses, and adherence to the request’s constraints. If verification fails, Fugu can re-route to a different underlying model, ask the same model to revise, or fall back to its own reasoning. The synthesis layer combines results from multiple underlying models (when the router decided to send to several) into a single coherent response.
The result, from the customer’s perspective, is a single OpenAI-compatible API endpoint that produces frontier-tier responses. The complexity of the underlying multi-model orchestration is hidden inside Fugu. Customers do not need to choose which underlying model to use, manage multiple vendor relationships, or build their own routing logic. The platform does it.
The two product tiers
Fugu (the lower-latency default tier) is positioned for high-volume production workloads where latency matters. The router in this tier favors single-model routes over multi-model synthesis, uses the lower-latency underlying models more often than the highest-capability ones, and applies a lighter verification layer. The result is responses that arrive in the same latency range as a direct call to a single frontier model, with the capability advantage from the routing logic rather than from multi-model coordination on every request.
Fugu Ultra (the flagship tier) is positioned for the highest-capability workloads where response quality matters more than latency. The router in this tier more aggressively uses multi-model coordination, applies a heavier verification layer with multiple verification passes, and may take meaningfully longer to produce a response than a direct single-model call would. The capability advantage is greater than Fugu’s, but the latency overhead is real.
The pricing differs between tiers but follows the same usage-based pattern as standard model APIs. Both tiers charge per million input tokens and per million output tokens, with Fugu Ultra at approximately 3x the per-token cost of Fugu. The pricing is positioned to be competitive with the standard rates of the underlying frontier models when summed across the routing logic’s expected behavior.
The choice between tiers is a workload-by-workload decision. Production chat surfaces serving end users tend to fit Fugu’s profile because latency matters. Analytical workloads, complex reasoning, and high-stakes generation tend to fit Fugu Ultra’s profile because quality matters more than seconds of additional latency.
The benchmark results
Sakana published benchmark results with the launch comparing Fugu and Fugu Ultra against the current frontier models on the standard public benchmarks. The headline numbers:
On LiveCodeBench (agentic coding), Fugu Ultra scored 93.2 percent. The comparison points: Opus 4.8 scored 91.4 percent; GPT-5.5 scored 92.6 percent; Gemini 3 Pro scored 89.1 percent. Fugu Ultra’s score is the highest in the comparison, though by margins small enough that the difference is at the edge of meaningfulness given benchmark noise.
On Aider’s polyglot coding benchmark, Fugu Ultra scored 76.4 percent against Opus 4.8’s 73.8 percent, GPT-5.5’s 72.1 percent, and Gemini 3 Pro’s 69.2 percent.
On GPQA (graduate-level science reasoning), Fugu Ultra scored 84.3 percent against the current frontier set’s 78 to 82 percent range.
On MATH-Hard, Fugu Ultra scored 67.1 percent against Opus 4.8’s 65.4 percent and GPT-5.5’s 64.8 percent.
The pattern across benchmarks is consistent: Fugu Ultra produces small but real improvements over the best single frontier model on each benchmark. The improvements are the orchestration premium: the routing and verification layers add capability beyond what any single underlying model could produce alone.
Several caveats are worth being explicit about. First, all numbers are Sakana-reported. Independent third-party benchmark replication is in early stages and will produce its own numbers in the weeks following the launch. Second, the benchmark improvements are small enough that they live at the edge of statistical significance for most benchmarks. The narrative of "beats every frontier model" is true on the published numbers but is sensitive to how the comparisons are run. Third, the underlying frontier models on which Fugu’s routing depends are themselves improving rapidly; the comparison snapshot at the launch will look different in a few months as the underlying set updates.
The most defensible reading is that Fugu Ultra is competitive at the frontier on the published benchmarks, with the architectural advantage that it can incorporate future improvements in any of its underlying models without retraining itself. The "frontier without single-model lock-in" framing is the strongest part of the pitch and is what customers should be evaluating.
The swappable-model implication
The single most distinctive operational property of Fugu is that its underlying model pool is swappable. Customers can configure which underlying models Fugu is allowed to use. Adding a new underlying model (when one becomes available, or when a customer’s vendor relationships expand) updates Fugu’s routing options without changing the customer’s integration. Removing an underlying model (when a vendor is restricted, when a contract ends, or when a customer’s compliance requirements change) similarly updates the routing without changing the integration.
This swappable property is the operational answer to a specific class of risk that has become more visible in 2026. The restriction of Anthropic’s Mythos model, the conditional access controls on GPT-5.5-Cyber, the export-control discussions around frontier AI, and the general uncertainty about which models will remain available to which customers under which conditions are all manifestations of the same underlying risk: that a customer’s AI application depends on a model whose availability the customer does not control. Fugu’s architecture treats this risk as a configuration parameter rather than as a fundamental constraint.
For customers in regulated industries (finance, healthcare, government, defense), the swappable property is potentially more valuable than the capability gains. The ability to remove a model from the pool when its provider’s regulatory status changes, or when a procurement decision pivots, without changing the application code is a meaningful operational advantage.
For customers outside regulated industries, the property is still useful but is more about future-proofing than about immediate operational need. The frontier-model market is evolving fast enough that the model best for a given workload today may not be the same model in six months. Fugu’s routing layer absorbs this change automatically.
Customer positioning and access
Sakana’s go-to-market for Fugu is two-channel. The first channel is direct enterprise sales, focused initially on Japanese customers in the targeted sectors (defense, banking, industrial, manufacturing, government). Direct enterprise customers typically engage through structured contracts that include integration support, custom routing configurations, and committed-spend pricing.
The second channel is self-service developer access through console.sakana.ai. The self-service surface is the OpenAI-compatible API with usage-based pricing, accessible to any developer with a Sakana account and a payment method on file. The self-service tier is how Sakana is reaching the broader developer market beyond its initial enterprise focus.
Pricing is usage-based on both channels with the per-token rates described earlier. Both channels charge separately for Fugu and Fugu Ultra. Enterprise customers can negotiate volume discounts and committed-throughput tiers.
The regional availability at launch is global through the self-service channel. Enterprise direct sales is initially focused on Japan, with expansion to other Asia-Pacific markets planned through Q3 and Q4 2026, and to US and European markets after that.
What this means for the broader market
Fugu’s launch is the most visible example to date of an architectural alternative to single-model frontier scaling. The thesis has been discussed in academic circles for years and has appeared in various forms in academic research, but the production deployment at frontier capability is new. If the approach works at scale, the implications for the broader market are substantial.
For frontier-AI labs, an architecture that wraps and routes their models reduces the differentiation between them at the customer-facing layer. A customer using Fugu may not particularly care which underlying model produced a given response, which weakens each underlying model’s brand position. This is a strategic concern that the major frontier-AI labs are likely to respond to, potentially by restricting how their models can be used in routing layers or by building their own competing orchestration products.
For customers, the alternative architecture lowers the switching cost between underlying models and increases their leverage in vendor negotiations. The market becomes more competitive at the model layer because customers have a clean path to substitute.
For the broader AI ecosystem, the architecture is a meaningful step toward what some researchers have called "the model-agnostic application layer." The vision is that applications are written against standard interfaces without tight coupling to any specific underlying model, and orchestration layers handle the model-specific details. Fugu is one production realization of this vision; it will not be the last.
Whether Fugu specifically succeeds depends on factors that will play out over the months and years ahead: the operational reliability of the orchestration layer, the cost competitiveness of the multi-model approach against continued single-model improvement, the response from the major frontier labs, and the customer adoption rate. The architectural bet is genuine and important. The execution is what will be tested.
Frequently asked questions
Is Fugu a single model or a system of models? Both, depending on the framing. From the customer’s perspective, Fugu is a single API endpoint that accepts a request and returns a response. From the internal architecture’s perspective, Fugu is an LLM that orchestrates calls to other LLMs. The "model" framing matches the customer surface; the "system" framing matches the underlying mechanics.
Which underlying models does Fugu route to? At launch, the configurable set includes Claude Opus 4.8, GPT-5.5, Gemini 3 Pro, Llama 4 405B, DeepSeek V4, Mistral Large 3, and several open-weight specialist models. Customers configure which subset Fugu is allowed to use.
Does my data go to all the underlying models? Only to the models Fugu actually routes to for your request, and only to models you have configured as eligible. The routing logic minimizes how many underlying models see any single request.
How does Fugu compare to LangGraph or LangChain orchestration? LangGraph and LangChain are orchestration frameworks that developers use to build their own routing and agentic logic. Fugu is a hosted product where the orchestration is built into the model itself. The trade-off is configurability (frameworks give you more control) versus convenience (Fugu requires no orchestration code).
Is Fugu available in regions other than Japan? Yes. Self-service access through console.sakana.ai is globally available. Enterprise direct sales is focused initially on Japan with expansion planned to other regions.
What happens if one of the underlying models is unavailable? Fugu’s router treats availability as one of its routing inputs. An unavailable model is automatically excluded from routing decisions until it becomes available again. The customer-facing API continues to work with the remaining models in the pool.
Can I use my own model weights as one of the underlying models? Yes, for enterprise customers. The enterprise tier supports customer-supplied models hosted on customer infrastructure, with Fugu treating them as another option in the routing pool. Self-service customers are limited to the standard underlying model set.
Is Fugu open source? No. The orchestration model itself is closed-weight and commercially licensed. The underlying research papers (TRINITY, Conductor) are publicly available on arXiv, but the production model implementation is proprietary.
How does Sakana protect against the underlying model providers seeing customer requests? Sakana operates the routing layer; customer requests go to Sakana’s infrastructure first, are processed by the routing logic, and are forwarded to underlying model providers under Sakana’s own API keys and data-handling agreements. The customer’s identity is not exposed to the underlying providers.
Is there a Fugu equivalent for embeddings or non-text modalities? Not at launch. Both Fugu tiers are text-and-tool models, similar to the major LLM products. Sakana has indicated multimodal capability is in development but has not committed to a release timeline.
