The bet hiding inside a "simple" decision
Sakana's new system, Fugu, does something quietly interesting. Rather than trying to be the single best model, it farms each request out to a pool of models through one API — an orchestration layer that, in Sakana's description, "chooses helpers, assigns work, checks results, and merges answers." The company pitched it partly as a hedge: frontier capability without depending on any one provider, after export controls disrupted access to some top models.
The early reviews are sceptical, and the benchmark claims are contested, so Fugu itself sits firmly in wait-and-see territory. But the architectural bet underneath it is the part worth paying attention to, because it is the opposite of what most engineering teams are quietly doing. Most teams are standardising on a single model. Fugu is a reminder that this feels like simplicity and is actually a wager.
Why teams standardise, and why it feels responsible
The instinct is understandable. Pick one model and one provider, and you get one API to learn, one bill to reason about, one set of quirks to work around, and a shorter path to onboarding a new engineer. It reads as discipline — the same discipline that says a smaller dependency list and a single database are usually better than a sprawl of them. Committing to one model looks like the grown-up choice.
The problem is that a model provider is not a database. It is a fast-moving, externally controlled dependency whose capability, price and availability all change on a monthly cadence, and standardising on one concentrates every one of those risks into a single point.
The risks you concentrate
Capability. No single model is best at everything, and the gaps are not small. The model that writes the cleanest code is often not the one you want summarising a long document, which is not the one you would choose for cheap, high-volume classification, which is not the one that reasons best through a gnarly problem. Standardising means accepting "good enough" on most tasks so that one task can be excellent — and usually not even noticing the tax you are paying on all the others.
Cost and performance drift. Relative price-for-performance shifts constantly as new versions ship. A model that was the obvious choice in the spring can be twice the price of a better option by the autumn. If your stack assumes one model, you cannot act on that; you just keep paying.
Continuity. This is the one teams underweight until it bites. Versions get deprecated on the provider's timeline, not yours. Rate limits and outages arrive without warning. Latency spikes under load. And, as Fugu's own pitch highlights, access can be disrupted for reasons that have nothing to do with your code — regulatory, commercial, geopolitical. A single provider is, quite literally, a single point of failure for a capability your product may now depend on.
The reframe: routing, not loyalty
The way out is not to adopt every model going. It is to change how you think about the decision. Choosing a model is a routing decision, made per task, not a loyalty decision, made once for the organisation.
In practice that means a thin abstraction between your application and any given model — a small adapter or gateway — so that the model sitting behind a particular task can be swapped without touching the code that calls it. You then choose per task on evidence: a handful of evaluations that tell you which model actually performs best for this job at an acceptable cost, and re-run them when something changes. The allegiance is to the task's outcome, not to a vendor's roadmap.
Notably, this is the same shape as Fugu's architecture, just without outsourcing the judgement to someone else's orchestration model. You keep the routing decision — and the visibility into it — in house.
The honest tradeoff
None of this is free, and it is worth being straight about the cost, because the failure mode here is over-rotating just as easily as under-rotating. Routing adds operational surface: more providers to hold accounts and budgets with, evaluations to maintain, observability to build across models rather than one, and the awkward fact that prompts are not perfectly portable — a prompt tuned for one model rarely drops cleanly onto another. Fugu's mixed reception is itself a caution against believing a clever orchestration layer is free capability.
So the goal is not the maximum number of models, and it is certainly not building your own model-merging system. The goal is simply to not be trapped. For most teams that means something modest: an abstraction layer, two models rather than one, and a small set of evals that make "should we switch?" a five-minute question with a real answer rather than a quarter-long migration.
The takeaway
Standardising on one model looks like good engineering hygiene, and in a stable market it might be. This is not a stable market. Underneath the tidy decision is a bet that a single vendor will stay the best, the cheapest, and the reliably available option for as long as your product lives — and none of those three tends to hold for more than a few months at a time.
The teams that will look shrewd in a year are not the ones who picked the "right" model today. They are the ones who kept the choice cheap to change.