The case against one big model
The argument here is narrower than the title. It is not that more models are better, or that every question needs a committee. Most of the time one well-chosen approach is exactly right.
It is that choosing to be structurally unable to use anything else is a liability, and it is a liability that reads as simplicity right up until the day it does not.
Simplicity is a real benefit and we should say so
One provider, one interface, one set of behaviours to learn. Fewer moving parts, fewer failure modes, one bill, one place to look when something is wrong. For an individual session this is straightforwardly good, and anyone dismissing it has not operated anything.
The reason it does not survive as a strategy is that the simplicity is not where it appears to be. It looks like simplicity in your system. It is actually simplicity in your contract — you have reduced the number of relationships you manage by making one of them load-bearing for everything. That is a different trade than the one being advertised, and the bill for it arrives all at once rather than in instalments.
The monoculture comparison, and where it breaks
The analogy we keep returning to is agricultural. Industrial monocultures are extraordinarily productive until a blight arrives, and the productivity and the fragility are the same property, not two properties in tension. Uniformity is what makes the yield high and what makes the failure total. Diversified systems degrade gracefully; uniform ones fail fast.
Model capability follows the same pattern closely enough to be useful. Every model has a characteristic profile: tasks it handles confidently, tasks where it hedges, and — the dangerous category — tasks where it silently underperforms in ways that are hard to detect from the output. Route everything through one and you inherit that profile entirely, strengths and blind spots together, with no way to tell them apart. You are not merely dependent on the model being good. You are dependent on its particular weaknesses never being the weaknesses that matter on the day they matter.
The analogy has a limit worth naming, because arguments that lean on a metaphor usually break where the metaphor does. A blight is external and arrives without warning. Model failure is mostly internal and continuous — it is not an event, it is a slow tax on the categories of question that model is weak at, which you never notice because you have no control group. That is arguably worse than the agricultural case. There is no crop failure to point at. There is just a class of answers that were always slightly thin.
Capability is not one dimension
There is an assumption smuggled inside the phrase "the best model": that capability is a single axis, and the best model is best along all of it.
That is not how this technology behaves. Different models carry different training emphases, different reasoning styles, different performance across domains. The one most capable at dense legal reasoning is frequently not the one best at structured numerical analysis, which is not the one best at producing a draft in a particular register. "Best" is always best-for.
This is not a temporary condition that resolves as the field matures. The range of tasks people bring to these systems exceeds what any single training run can optimise for uniformly, and it keeps widening faster than any individual model generalises. Betting on convergence is a coherent position; it is just a bet, and it is one where being wrong is expensive and being right saves you very little.
What we rejected: the two obvious ways to use several models
Having decided against one model, there are two standard ways to use more than one, and we rejected both.
Ask several and compare. Send the question everywhere, show the answers side by side, let the reader pick. This has real appeal and we built toward it before stopping. It fails on the thing it is supposed to fix: it converts a question into a second, harder question. The reader now has to adjudicate between three fluent, confident, mutually inconsistent answers with no more information than they started with — and in practice they pick the one that reads best, which selects for fluency over correctness, which is precisely the failure we were trying to design out. It also multiplies cost and latency for a benefit that only accrues to readers who were already able to tell the answers apart.
Ask several and merge. The more sophisticated version: combine the outputs into one consensus answer. We rejected this harder. Merging destroys the only useful signal in the disagreement. Where two models diverge, that divergence is information — it is usually pointing at exactly the part of the question the evidence does not settle — and a merged answer launders it into a single confident paragraph that is now wrong in a way neither original was. A consensus of three is not more reliable than its parts. It is less legible than its parts, and legibility was the point.
What is left is unglamorous: route the work to the capability that fits it, tell the reader where it went, and let them override. No panel, no vote. It is a smaller idea than either alternative and it is the only one that does not make the reader's job harder.
What variety actually buys
Two things, one obvious and one not.
The obvious one is insulation. When your workflow depends on a single provider, that provider's deprecations, price changes and outages become yours, on their schedule. When work can move, those events get absorbed before they reach the person trying to finish something.
The less obvious one is calibration. If you have only ever seen how one model approaches a question, you cannot separate the answer from that model's characteristic voice and habits — and you will systematically mistake its style for the shape of the truth. Exposure to a range makes the underlying uncertainty visible, which is uncomfortable and makes the work more honest. Some of the confidence you had was the model's, not the evidence's.
See /models for what is currently available.
Where this position costs us
Variety is a real burden. More options means more surface to explain, more inconsistency in tone across a session, and more ways for a user to be confused about why two similar questions behaved differently. A single-model product is easier to use and easier to describe, and we pay for the alternative every time someone asks why the answer feels different today.
Routing can be wrong, and wrongly is worse than uniformly. A system that sends work to the fitting capability most of the time will occasionally send it to the unfitting one, and that failure is harder to reason about than a consistent weakness would have been — because it is intermittent. A model that is always mediocre at something is a known quantity. A system that is usually excellent and sometimes not is harder to build a habit around. This is a genuine cost of our position and the honest answer to it is visibility: you can see where the work went, and you can send it elsewhere.
What we would do differently
We would have built the override before the routing.
We designed a system that chooses well and then, later, added the ability for a person to disagree with it. That order encodes an assumption we do not actually hold — that the choice is ours to make and the user's to accept. It is the wrong way round. The person with the question knows things about it that no signal in the request can carry: what it is for, how much it matters, how much checking they are prepared to do afterwards. The override is not an escape hatch from the routing. It is the part that should have defined it.
Simplicity in an interface is a virtue. Simplicity in your capability foundation is a risk. They are not the same thing and it is worth holding them apart.