You send Sakana AI’s new Fugu model one request, and it decides which other models do the work. You never find out which ones. Sakana’s own FAQ confirms the routing is hidden by design, the pool of models it draws from is undisclosed, and that pool can change without telling you. That opacity is not a bug in the launch. It is the product.
Fugu Max and Fugu Ultra v2 shipped on September 11, and they belong to a category that quietly turned into a real buying decision this year: the model router. On paper a router solves the problem the site covered when a frontier model started dropping every eleven days. You stop picking one model and let software pick per request. What the Fugu launch makes clear is that the word “routing” now covers two opposite products, and the difference between them is the whole decision.
Two things both called routing
One camp is the transparent gateway. OpenRouter sits in front of 300-plus models across 60-plus providers behind an OpenAI-compatible API, and its Auto Router (built on NotDiamond) exposes a cost_quality_tradeoff dial from 0, always the most capable model, to 10, always the cheapest, defaulting to 7, with no surcharge for using it. LiteLLM does the same job as an open-source proxy you host yourself across 100-plus providers. Portkey, now owned by Palo Alto Networks after an April 2026 acquisition, adds guardrails and semantic caching on top of 250-plus providers. Azure AI Foundry ships a native Model Router with Balanced, Cost, and Quality modes across 27-plus models. Martian and RouteLLM round out the field with proprietary and open routing models respectively.
Everything in that camp shares one trait: you can see the seams. You choose the pool. You can read, per request, which model answered. You can pin a model when a router’s choice goes wrong. The savings, whatever they turn out to be, are yours to measure on your own logs.
The other camp is the learned orchestrator, and Fugu is the sharpest example yet. According to MarkTechPost’s launch coverage, Fugu is not a single model at all. It is a model trained to hand each task to other models and stitch the answers back together, and to recursively call instances of itself. The training combined large-scale fine-tuning, evolutionary algorithms, and reinforcement learning, and it builds on two ICLR 2026 papers: TRINITY, a lightweight evolved coordinator that assigns Thinker, Worker, and Verifier roles across turns, and The Conductor, trained with reinforcement learning to discover its own coordination strategies in natural language. You send one request to one API. Fugu owns every decision after that.
What Fugu actually costs and claims
Fugu Max is the cost-optimized tier at $2 per million input tokens and $6 per million output, which Sakana says runs 40 to 60 percent cheaper on output than Sonnet 5, GPT-5.6 Terra, and Kimi K3. Its pool leans on open-weight and specialist models including the NVIDIA Nemotron family, and Sakana reports it topping six benchmarks (Terminal Bench 2.1, GPQA Diamond, AA-LCR, GDP.pdf, AutomationBench, and SWEFish) while expanding the cost-performance frontier on seven of ten.
Fugu Ultra v2 chases quality instead: $5 per million input, $30 per million output, a 1M-token context window, 128K maximum output, and a long-context surcharge above 272,000 tokens, per DataNorth’s breakdown. Sakana claims 48.3 on Chartography against 27.3 for Opus 5 and 29.5 for Fable 5, and 74.3 on DeepSWE while beating models priced three to five times higher per token. Notably its pool excludes Fable 5, Fable 5.1, and GPT-6-Astra, which is how Sakana frames it as not depending on any single proprietary frontier model.
Two caveats sit inside those numbers. SWEFish is Sakana’s own internal benchmark, so it is grading part of its own homework. And the models are hosted API only, with no open weights and no self-hosting, and they are not offered in the EU or EEA while Sakana works on GDPR compliance. A European buyer cannot use them at all right now.
The independent numbers are less flattering than the pitch
Every router vendor markets a savings figure, and every figure comes from the vendor’s own evaluation. RouteLLM, the open router from LMSYS and the one with peer-reviewed ICLR 2025 work behind it, reported cutting GPT-4-class calls by up to 85 percent while holding 95 percent of GPT-4 quality on MT-Bench, routing only about 14 percent of queries to the strong model. NotDiamond markets 20 to 40 percent savings; Martian has claimed cuts as high as 97 percent. The common thread, flagged in an independent comparison of the three, is that those wins were measured mostly on MT-Bench, a benchmark of easy, chatty questions where cheap models already do well.
When a neutral benchmark, RouterArena, scored the field, the results inverted the marketing. A leading commercial router ranked 12th, specifically for over-selecting expensive models, the opposite of the promise, and the study concluded no router is optimal across all metrics. The same analysis makes the point that matters for a budget: a router is not free money. It is an inference-shaped cost of its own, adding roughly 100 to 200 milliseconds per request through hosted prediction and network hops, and the savings only materialize when two things are both true, a large price gap between the strong and weak models and a meaningful share of traffic that can safely go to the cheap one. Below that threshold you pay latency for very little.
There is a subtler risk that no cost dashboard will show you. DigitalApplied’s 2026 routing guide names it silent quality regression: a router quietly sends more work to a weaker model, output degrades a little, and the damage surfaces days later in customer tickets, invisible until then. The fix it recommends is a pre-merge evaluation gate of 50 to 500 representative cases, checking groundedness with an LLM-as-judge, before any routing change ships. That is the same discipline as building your own eval instead of trusting a leaderboard, applied to the router itself.
The seam you can see versus the one you can’t
Running IT operations, the thing that gets you paged at 2 a.m. is almost never the component you understand. It is the dependency nobody can see into. An untraceable dependency is a liability before it is a convenience, because when it misbehaves you cannot debug it, you cannot attest to it, and you cannot swap it out under pressure. That is the lens I bring to this split.
A transparent gateway keeps the seams visible. When a request produces a bad answer, you can read which model handled it, reproduce it, and pin around it. Fugu’s bet is the opposite: trust our routing, and in exchange stop thinking about models. For a prototype or a research workload where you value the best result per dollar and the data is not sensitive, that trade can be worth it. For a regulated workflow, it is disqualifying on its own terms. If you have to attest to which model and which data path touched a request, an orchestrator that hides both cannot be part of the answer, no matter how good the benchmark looks. Sakana’s pitch that Fugu frees you from single-vendor dependence is also undercut by its own opacity: you have traded a set of documented suppliers you can audit for one undisclosed pool you cannot.
How to actually decide
Sort the choice by what you can prove, not by whose savings number is largest.
If you must be able to say which model handled a request, for audit, data residency, or contractual reasons, rule out the opaque orchestrators first and only then compare the transparent routers. Fugu is not even available in Europe today, which settles it for EU buyers.
If you want savings you can defend, use a transparent router but put it behind your own eval suite and measure cost per completed task on your traffic, not vendor MT-Bench numbers. Routing is a feature you validate, not a token-economics silver bullet.
If your traffic is uniform or the price gap between your candidate models is small, skip routing entirely. You will pay latency and complexity for savings that never arrive; pin one model and revisit when the cost map actually shifts.
And if the task is hard, heterogeneous, single-shot, and non-sensitive, an orchestrator like Fugu Max is genuinely interesting: it is doing the multi-agent coordination work that most teams get wrong in the handoffs, and doing it for you. The price of that convenience is that you will never see how. Decide whether that price is one you can sign for. It is the same question the image-model split posed a few days ago, moved up a layer: the routing is not the hard part anymore. Knowing what you gave up to get it is.