Sakana Fugu Review: An Orchestration Hedge, Not Sovereign AI

Last updated: June 23, 2026

A document-and-architecture audit of what Sakana Fugu actually sells, the orchestration cost you cannot forecast before a run, and who should skip it.

Sakana Fugu is an OpenAI-compatible API from Sakana AI K.K. that runs a multi-agent orchestration system behind one endpoint. Rather than serving a single model, it routes work across a pool of external frontier models and, in Sakana’s own description, handles model selection, delegation, verification, and synthesis internally. Two variants ship, Fugu and Fugu Ultra, both through the same API. General availability began on June 22, 2026.

The timing is the whole pitch. Fugu went generally available ten days after Anthropic said a US export-control directive required it to cut off Fable 5 and Mythos 5 for any foreign national, inside the United States or outside it. To comply, Anthropic disabled both models worldwide. Its other models kept running. Sakana’s framing points straight at that: build on Fugu, the argument goes, and one vendor losing access does not take your whole stack down with it.

Read Sakana’s own Terms of Service, though, and the hedge gets narrower. The Terms describe Fugu as routing input to external machine learning models, and the examples they name are OpenAI, Anthropic, and Google. Every external provider Sakana names, and every public model it benchmarks against, is US-jurisdiction. The full active pool is not disclosed, and the per-request routing is, in Sakana’s own words, not exposed by design. The same Terms put US export-control and sanctions compliance on you, the user, and place anyone outside Japan under California law. So the hedge spreads your dependency across providers you cannot fully enumerate, in the same jurisdiction whose export-control reach produced the Fable suspension, governed by terms that hand the compliance risk back to you. The gap between the word sovereignty and what those documents describe is the seam this review is built on.

The buyer facts, ahead of the 48-hour pricing recheck Sakana’s volatile rates demand: subscriptions at $20, $100, and $200 a month, sold as relative usage multipliers with no published token cap; pay-as-you-go Fugu Ultra at $5 per million input tokens and $30 per million output; orchestration tokens billed into the final price; and routing that Sakana does not expose. Fugu is not available in the EU, the EEA, the UK, or Switzerland.

Briefing summary, June 2026

Review tier and disclosure

TL;DR

Quick start for developers

Fugu speaks the OpenAI wire format, so a one-line base-URL swap will move most existing OpenAI client code over. The catch is the custom token_details field. Standard cost-tracking tooling that expects only OpenAI-shaped usage objects may not read orchestration tokens correctly without adjustment. FSR flags that as a likely integration gap rather than a tested fact.

At a glance: key facts

What happened, and who it touches

Start with the trigger, because Fugu’s marketing depends on it. On June 12, 2026, Anthropic published a statement that the US government had issued an export-control directive, citing national security, to suspend all access to its Fable 5 and Mythos 5 models by any foreign national, whether inside or outside the United States, including Anthropic’s own foreign-national staff. Anthropic disabled both models for every customer to comply. The stated basis was an alleged Fable 5 capability, with Anthropic noting the same capability is available from other models and saying it disagreed with the recall while following it. The directive arrived at 5:21 pm ET, and access was cut off abruptly.

That is the event Sakana names. Fugu’s promise is that a single vendor going dark, the way Fable did, should not be able to take your application down, because the orchestration layer can route around the gap. For a buyer who watched a frontier model vanish in an afternoon, that is a real and rational fear to address.

Now the question that decides whether Fugu is for you at all.

Who it is relevant to. Builders of complex agentic systems: coding agents, multi-step research agents, and reasoning pipelines where you would otherwise stitch together several providers, write your own router, and maintain a verification layer. If you want that orchestration handled for you behind one endpoint, and your workload is not regulated or sensitive, Fugu is aimed squarely at you.

Who it is not relevant to. Three groups can stop reading after this paragraph. If you operate in the EU, EEA, UK, or Switzerland, Fugu is not available to you, full stop. If you handle regulated or personal data, Fugu’s own Terms forbid that input, so it is the wrong tool by design. And if your requirement is to know which model handled each request, to keep an audit trail, or to forecast cost precisely before a run, the product’s opacity is structural and will not suit you.

What the impact is, beyond the launch. The interesting part is not the model. It is the category. Fugu is one of the clearest signals yet that “orchestration” is becoming a product you buy rather than a system you build. The base model is no longer the unit of sale. The unit of sale is the routing, delegation, and verification layer on top of other people’s models. That shift moves the trust boundary. You are no longer trusting one model vendor with your prompt. You are trusting an intermediary to decide, invisibly, which vendors see it and how the work is split. That is a different procurement question, and most buyers have not adjusted to it yet.

What Fugu actually sells

It helps to be precise about the product, because the marketing word and the mechanism point in different directions.

Fugu does not sell you a new standalone frontier model. By Sakana’s own account, it sells managed orchestration over a pool of existing external models. The system selects which model handles a piece of work, delegates sub-tasks, runs a verification pass, and synthesizes a final answer. Sakana grounds this in two papers it published or co-authored, TRINITY and Conductor, both slated for ICLR 2026. The Conductor paper describes a 7 billion parameter reinforcement-learned conductor that decides delegation. Note the boundary carefully: that figure describes the research artifact, not the shipping product. Sakana has not published the conductor size inside the live Fugu service, so treating Fugu as “a 7B model” would be wrong.

The honest read is that the orchestration itself is a difficult engineering problem, and the public benchmark numbers (covered below) show it producing strong results against publicly available models. The product work is credible: model selection, delegation, verification, and synthesis are real engineering, not a wrapper. The problem is the second label Sakana puts on the box.

The sovereignty seam: the blind spot

Here is the part the launch-day discourse is mostly missing. The early argument splits between two camps. One asks whether Fugu beats Fable on benchmarks. The other asks whether it is “just a router.” Both miss the structural move, which is a quiet redefinition of one word.

Sakana borrows “sovereignty” from a moment of real supply shock. When buyers hear “AI sovereignty,” they tend to hear something specific: control over where their data goes, which legal jurisdiction governs it, and whether the system can be audited. Fugu delivers something narrower, and that narrower thing is real. If one frontier vendor is cut off, the endpoint keeps working because the orchestration layer can lean on others. Call that supply resilience, or availability resilience. It is a legitimate benefit.

Data sovereignty and jurisdictional independence are a different claim, and Fugu’s own documents do not support it. The Terms name OpenAI, Anthropic, and Google as examples of the external models the service routes to. All three are US-jurisdiction providers, as is every public model Sakana benchmarks against, and the full active pool is not disclosed. The same Terms place US export-control and trade-sanctions compliance on the user, prohibit use by sanctioned parties, and forbid submitting export-restricted content. The Privacy Policy says data is transferred internationally, including to Japan and the United States. Users outside Japan are governed by California law.

So follow the logic to its end. The event that made Fugu’s pitch compelling was an export-control action that reaches a US-jurisdiction capability accessed remotely. Every provider Fugu names sits inside that same jurisdiction, and Sakana does not disclose the rest of the pool. The hedge therefore addresses the symptom, not the cause. It protects against one vendor losing access, while the authority that can order such a loss still sits underneath the providers you can see and, for all a buyer can verify, the ones you cannot.

This is the FSR finding. Fugu reorganizes frontier-model dependency behind one endpoint. It may improve integration and availability resilience. It does not prove data sovereignty, jurisdictional independence, or per-request auditability, and on the last point it actively reduces what you can see.

Routing, opacity, and three consequences

The mechanism that makes the finding bite is one sentence in Sakana’s FAQ: the routing information is “not exposed by design.” Which underlying model handled a request, and how the work was coordinated, are treated as proprietary and are not surfaced to you.

For a buyer who wants one managed endpoint and nothing more, that may be acceptable. For a buyer with governance, cost, or verification requirements, it produces three distinct consequences.

Consequence one, the sovereignty consequence. If you cannot see which external model processed a request, you cannot make a clean data-residency or processor-audit claim about it. The opacity that makes the product convenient is the same opacity that undercuts the sovereignty framing.

Consequence two, the cost consequence. Because routing and the orchestration steps are hidden, you cannot easily predict how fast a real agentic workflow will consume a subscription, or how many orchestration tokens a given task will add. You see the result after the fact, not the shape of it before you run.

Consequence three, the verification consequence. A benchmark result is produced under Sakana’s routing. Your production call is produced under routing you cannot inspect. The gap between the two means a published score does not cleanly map onto your own workload. The numbers can be real and still not transferable.

There is one meaningful control here, and it is a governance difference worth naming. On the standard Fugu model, you can opt specific providers or models out through the console. On Fugu Ultra, the pool is fixed and there is no opt-out. Read that as an entitlement boundary, not a feature gap: the more you pay for maximum capability, the less control you keep over which providers touch your data.

The benchmark read

Sakana publishes a benchmark table comparing Fugu and Fugu Ultra against three named public baselines: Gemini 3.1 Pro (high), Opus 4.8 (max), and GPT 5.5 (xhigh). The scores below are reproduced from Sakana’s page. Baselines are provider-reported, marked with a dagger. SWE Bench Pro used mini-swe-agent scaffolding, marked with an asterisk.

What the table actually says, read straight:

Against the three public baselines, Fugu Ultra posts the top or tied-top score on most of the benchmarks Sakana lists, verified in June 2026. Sakana’s claim that the system surpasses publicly accessible frontier models is broadly true and checkable on coding and reasoning tasks, with the caveat that the table is a live page and the recheck schedule revisits it.

It is not a sweep. GPT 5.5 takes MRCRv2, at 94.8 to Fugu Ultra’s 93.6. And on several tasks (SciCode, the τ³ Banking agentic test, and Long Context Reasoning) the cheaper base Fugu actually outscores the flagship Fugu Ultra, with GPQA Diamond tied between the two. A buyer should notice that, because it means the most expensive option is not uniformly the strongest, and a workload weighted toward those tasks might be better served by the base model.

Then there is the headline that does not appear in this table. Sakana also describes Fugu Ultra as “shoulder to shoulder” with Fable 5 and Mythos 5. Treat that as an official claim, not a verified result. Those two models are export-suspended and not publicly accessible, the comparison is reported as a max-of-two aggregate, and it appears only as a chart image. No one outside Sakana can reproduce it. FSR reports the claim and neither endorses nor rebuts it with specific Fable numbers, because no trustworthy Fable numbers exist to cite.

What the independent research says

Step back from Sakana’s own materials and ask what the broader literature says about orchestration, because that is the only independent check available on the architecture itself.

The peer-reviewed and preprint record supports a conditional conclusion, not a blanket one. Multi-model orchestration can beat the best single model, but only under specific conditions: genuine diversity among the models, learned rather than naive routing, sensible task decomposition, and a verifier that is actually reliable. Where those hold, there are positive results. Lu and colleagues (2023) showed a learned router that beat the best single model on average and ranked first on a large minority of tasks. Wang and colleagues (2024) showed a mixture-of-agents approach outperforming a strong single model on several evaluations.

The cautionary half of the literature is just as load-bearing. Multi-agent debate often fails to beat simple baselines. Orchestration frameworks add real overhead, with one 2026 analysis reporting latency penalties ranging from modest to very large and a measurable drop in planning accuracy under some configurations. Another 2026 system beat its baselines but at roughly ninety seconds per question. And the verifier, the component everything depends on, is itself a known weak point: model-as-judge systems agree with humans well on subjective preference but perform poorly on objective correctness, and they exhibit self-preference bias.

Two things follow. First, the architecture Fugu uses is research-backed in principle, but only conditionally, and it tends to cost latency. Second, Fugu’s specific gains rest on vendor-authored preprints, TRINITY and Conductor, that have not been independently replicated, and no independent Fugu technical evaluation exists in the literature. Sakana’s broader heritage in model composition is real and peer-reviewed, including its 2024 work on evolutionary model merging. But the live product’s specific claims sit outside what independent research has yet validated. That is not an accusation. It is the current state of the evidence.

Cost structure and the orchestration tax

Pricing is where Fugu is simultaneously transparent and opaque, and the two need to be separated.

Transparent: the sticker prices are published. Subscriptions run $20, $100, and $200 per month, described as one times, ten times, and twenty times a baseline usage allowance. Pay-as-you-go Fugu Ultra is $5 per million input tokens, $30 per million output tokens, and $0.50 per million cached input tokens, with each figure roughly doubling once a request exceeds 272K of context. There is a launch promotion: subscribe before the end of July 2026 and get a free second month at your starting tier. One buyer-friendly design point deserves real credit here. For the standard Fugu model, running multiple agents does not stack separate fees. Sakana charges a single blended rate based on the top-tier model involved, rather than billing each agent separately.

Opaque: two things you would want before committing are missing. The subscription tiers give you a multiplier, not an absolute cap. You see “ten times” and “twenty times,” not a hard token, request, or job allowance, so you cannot calculate how much real work a plan buys before you buy it. And the standard Fugu per-token rate is not published at all; it is described only as the standard rate for whichever underlying model is used.

Then there is the orchestration tax. Fugu records orchestration tokens in the token_details field, bills them at the standard input and output rates, and counts them in the final price. Sakana is upfront that these are real token usage beyond the visible input and output, and that they reach your bill. That is the right disclosure to make. The practical problem is direction of visibility. Orchestration tokens are easy to audit after a request and hard to forecast before one. On a long agentic loop, where the orchestrator may fan out across multiple steps and models, that overhead could grow in ways the pricing page cannot tell you in advance. How large it grows on a real workload is exactly what a Tier B hands-on test needs to measure, and FSR has not measured it.

A note on the early social signal, kept in its lane. A visible Hacker News thread on launch day included first-hand reports of slow responses and a subscription allowance that ran down faster than expected, alongside comments comparing Fugu to OpenRouter-style routing and home-built multi-agent setups. FSR treats those as early user signals, not verified performance claims. They are useful only as a map of where buyers will test Fugu first: cost predictability, routing transparency, and whether managed orchestration actually beats a direct frontier call. None of it is stated here as fact about the product’s speed or value.

Privacy, training, and legal posture

This section is a procurement assessment, not a legal ruling. FSR is not making any compliance or violation finding. The point is to surface what the documents say and what they leave open.

The Privacy Policy lists what gets collected: prompts, uploaded content, outputs, feedback, session data, timestamps, and request identifiers. Personal data may be disclosed to vendors including the underlying LLM providers, cloud infrastructure, analytics, payment processing, and support. International transfer is stated, including to Japan and the United States. The service is for adults only, and a CCPA addendum exists for California. Retention is described as “as reasonably necessary,” with no fixed schedule published.

On training, the Terms are permissive. They allow the Company to use your content for training, evaluation, and service improvement, with a console opt-out for training use that is not retroactive: content already used may not be reversible. FSR did not confirm the console default state, which is a hands-on check, so treat whether the opt-out ships off by default as an open question rather than a settled fact. The content license is broad, described as worldwide, perpetual, irrevocable, non-exclusive, sublicensable, and transferable. The Terms also state there is no obligation to retain your content, and, separately, no obligation to delete trained model weights, external-vendor caches, or audit logs. Contractors and human reviewers may be involved in some circumstances.

A few more clauses a buyer should weigh. Inputting personal information is prohibited, as is health, financial, and other sensitive information, which by itself tells you Fugu is not built for regulated data. Building a competing AI orchestration or routing product is prohibited. There is no uptime or response-time guarantee, and the Terms explicitly contemplate degradation or suspension caused by an external provider. Credits expire after six months and are non-refundable. The Usage Policy, on the portion FSR confirmed, prohibits processing individuals’ sensitive information without consent, building facial-recognition databases, and real-time biometric identification, requires that AI-generated output be disclosed as such, and bars unauthorized security testing. One area of that policy concerning automated decisions in high-stakes domains is still being re-confirmed against the full text and is therefore not characterized here.

The procurement gap is the headline. FSR found no published Data Processing Agreement, no subprocessor list, no SLA, no fixed retention schedule, and no security certification such as SOC 2 or ISO 27001. The absence is the finding. For a regulated or enterprise buyer, those documents are the entry ticket, and at launch they are not on the table.

How Fugu compares to the alternatives

Fugu is not the only way to get multi-model capability, and the right comparison is by tradeoff, not by ranking. Each option below wins on a different axis. The table is meant to help you locate your own constraint.

The pattern is clean. Fugu’s genuine edge is the bottom row: it removes the work of building and maintaining a multi-agent system. Its genuine cost is the rows above: visibility, jurisdiction control, cost forecasting, and audit. If your binding constraint is engineering time, Fugu argues well for itself. If your binding constraint is governance or cost transparency, the alternatives argue better.

Who should use it, who should not, who should wait

Use it if you build complex coding, reasoning, or research agents, you would rather pay for one managed orchestration endpoint than build and maintain a multi-agent stack, and your work is not sensitive enough that routing and cost opacity become a problem.

Skip it if you are in the EU, EEA, UK, or Switzerland, if you need per-request model provenance or audit logs, if you handle regulated or sensitive data, if you need deterministic cost prediction, or if what you actually want is local, data-sovereign AI. In that last case, Fugu is the wrong category entirely, though the open-weight route is not the clean escape it looks like either: as FSR found with GLM-5.2 and Kimi K2.7 Code, the hardware floor pushes most teams back onto a vendor API.

Wait if you are a procurement or security team holding out for a DPA, a subprocessor list, an SLA, and audit logs, none of which exist yet. Or if you are cost-sensitive and need to measure real orchestration-token overhead on your own workload before you can trust the bill.

FAQ

Methodology and sources

This is a Tier C, document-and-architecture review. Future Stack Reviews did not run a paid production workload against Fugu. The findings come from Sakana’s public materials and primary policy documents, the two research papers Sakana cites, Anthropic’s export-control statement, a synthesis of the independent academic literature on multi-model orchestration, and a clearly attributed set of third-party and early-user signals that are not treated as verified product behavior.

• sakana.ai/fugu (product page, benchmark table, FAQ)
• Terms of Service, effective June 12, 2026
• Privacy Policy
• Usage Policy (partially confirmed; one section pending full re-read)
• Console pricing and developer documentation (get-started and models)
• Anthropic, Fable 5 and Mythos 5 access statement
• TRINITY (arXiv 2512.04695) and Conductor (arXiv 2512.04388)
• A Fugu technical report PDF exists in Sakana’s GitHub repository; FSR confirmed its existence but did not extract or rely on its contents

What FSR did not test. Real latency (time to first token, p50, p99), quota burn on a sustained workload, actual per-task cost ratios, the true magnitude of orchestration-token overhead, the quality impact of opting providers out, whether per-request provider attribution can be surfaced by any means, and the undocumented behaviors around rate limits, streaming, and structured outputs. Every one of those needs hands-on access.

Tier B follow-up plan. When paid access is set up, FSR will: quantify the orchestration-token overhead ratio (visible tokens versus billed) on a real coding-agent workload with screenshots; test whether the model that handled a request can be surfaced at all; reproduce a build task through Codex or Cursor and check it against the public-baseline benchmark claims; measure latency against a direct frontier call; and test what opting a provider out does to output quality.

Recheck discipline. Pricing and availability are high-volatility and must be re-verified within 48 hours of publication. The export-control situation is also live: at the time of writing, the Fable and Mythos suspension was being disputed, and Anthropic had stated it disagreed with the recall while complying. Independent reporting and policy analysis in mid-June framed the export action as a novel and legally uncertain application of export control to remotely accessed AI, which is the broader context for Sakana’s pitch.

FSR verdict

Sakana built something substantial. The orchestration is a hard engineering problem, the benchmark leads against publicly available models are checkable and mostly hold, and the no-fee-stacking pricing on the base model is an honest design choice. If your problem is that you do not want to build and babysit a multi-agent system, Fugu is a credible way to skip that work, and it deserves a paid trial on non-sensitive workloads.

The thing to discount is the second label. “AI sovereignty” oversells what Fugu does. The product hedges one vendor being cut off by spreading your dependency across a pool of US-jurisdiction models you cannot see into, governed by terms that push export-control compliance back onto you. That is supply resilience, and it is worth something. It is not data sovereignty, it is not jurisdictional independence, and it reduces your visibility into the system rather than increasing it. Read Fugu as an orchestration hedge and the value is clear. Read it as the marketing word, and you will have bought something other than what you thought.

For EU, UK, regulated, and audit-bound buyers, this is not close: the door is shut today, and the procurement documents that would reopen it do not exist yet. For everyone else, the right move is to trial it on disposable work and measure the orchestration tax yourself before you let it near production. The benchmark leads are checkable against public baselines, but they are vendor-published, not a production audit. Whether they survive contact with your own workload, behind routing you cannot inspect, is the one question only a hands-on test can answer, and that test is still to come.