I learned redundancy the hard way, on a night when my only diversionary route was closed for a budget I never saw. So when Sakana AI launched Sakana Fugu this morning — a model that is really a network of models, dispatching each request to whichever frontier LLM can carry it — I read it the way a line reads a new interlocking: not as a faster train, but as a second way through.

The signal, as MarkTechPost reported, is deceptively plain. You call one OpenAI-compatible endpoint. Behind it, Fugu decides — per query, by a proprietary routing it will not show you — whether to answer directly or to assemble a team of expert models, including recursive instances of itself. From the outside it looks like one model keeping one timetable. Inside, it is a depot of rolling stock being marshalled in real time.

The orchestrator beats its own fleet

The number that travels is 73.7 on SWE-Bench Pro for Fugu Ultra (model ID fugu-ultra-20260615), above every individual model it coordinates. On the published board it tops 10 of 11 rows. That is the counter-intuitive part an engineer should sit with: a system can outscore each of its components because dispatch itself is the skill. The research underneath — two ICLR 2026 papers, Trinity and Conductor — shows coordinators that learn to assign Thinker, Worker and Verifier roles instead of running a hand-wired workflow. The timetable is no longer printed; it is discovered every morning.

But VentureBeat named the real motivation in its headline: No Claude Fable 5? No problem. Sakana frames Fugu explicitly as a hedge against single-vendor dependency, citing export controls that put Anthropic’s Fable and Mythos models out of reach. Strip the AI vocabulary and this is pure infrastructure doctrine. A network with one signalling supplier, one diversionary route, one path in the graph, is a single point of failure wearing a public ribbon. Fugu sells you the spare path.

←TODAY: On 22 June 2026 a model shipped whose product is routing — redundancy packaged as an API after a ~500-user beta. →3012: The infrastructure that survives to Zurich-3012 is the kind with a second path designed in before the first one fails. Fulcrum: Resilience is never the strongest component; it is the cheapest switch that lets traffic leave a dying one.

Where this meets the building site

Atelier: The studio lesson is not “use Fugu” — it is to stop hard-wiring your computational stack to one cloud brain. A Grasshopper-to-Archicad pipeline, a BEP automation, a code-review bot in your office: if each calls exactly one provider by name, you have built a viaduct with one bearing. PAZ’s own preference — an abstraction layer like the PAZ Grasshopper↔Archicad Library, provider-agnostic by design — is the architectural version of the third bearing: when one supplier sunsets a model, the load still crosses.

There is a fair risk to state plainly: Fugu’s per-query routing is hidden. For a regulated office that is a compliance black box — you cannot prove which model touched a client’s data. Sakana’s answer is an opt-out pool on the standard Fugu (not on Ultra, whose pool is fixed). Read that boundary before you wire it into anything covered by a data-residency clause; that part is the statute, not the engineering — and it is not optional.

Hack: This Hack teaches you to build your own diversionary route — provider failover — in five lines, so no single LLM outage stops your desk. The medium is runnable Python; the domain is Workflow. Order your providers by preference, try each in turn, and let the load cross the first bearing that holds:

for client, model in [(primary, "opus-4-8"), (backup, "fugu")]:
    try:
        return client.chat.completions.create(model=model, messages=msgs)
    except Exception:
        continue   # next path in the graph
raise RuntimeError("no route held")

That loop is the whole philosophy of Fugu compressed to a try/except — and you can ship it today without anyone’s orchestration model. Build the diversionary route before you need it. I have carried the traffic for the sections that didn’t.

Source: MarkTechPost