Two years ago, this article would have been short. If you wanted frontier quality, you used a proprietary API; if you needed control and data sovereignty, you accepted a large quality gap and ran an open model. The trade was clear and the answer, for most enterprises, was proprietary.
That calculus is gone. The benchmark gap between the best open-weight models and the proprietary frontier has narrowed from twenty to thirty percentage points in 2023 to somewhere between three and ten points today depending on the task, and analysis suggests open weights now trail the state of the art by only about three months on average. On some production workloads (structured extraction, summarisation, standard code generation) the gap is effectively negligible; on the hardest multi-step reasoning, proprietary frontier models still hold a real lead. Meanwhile 85% of organisations now describe open source as important to their AI strategy, and the question has migrated from engineering forums to board papers, carried there by three words that concentrate executive attention: cost, control, and sovereignty.
So this article treats the question at the level it now deserves: not “which model is best” (an answer with a shelf life of weeks) but how to set your model portfolio posture, a decision with a shelf life of years.
First, the vocabulary that prevents expensive confusion
One clarification does a lot of work in this conversation. Open weights means the trained model parameters are downloadable and runnable on your infrastructure. Open source, properly used, means more: code, training details, and an OSI-approved licence with unrestricted use. Most models marketed as open source are in fact open weight, and the licences vary enormously: some are genuinely permissive (Apache 2.0, MIT), others restrict commercial use, cap monthly active users, or impose conditions on derivatives. The most famous example is the clause requiring a special licence above 700 million monthly active users, harmless for nearly everyone, but a perfect illustration of why “open” is a spectrum, not a switch.
The strategic implication is simple: licence review belongs in the model selection process with the same seriousness as benchmark review. A model that tops the leaderboard but restricts your commercial use case is not an option, it is a lawsuit deferred.
The real trade, itemised
Strip away the advocacy from both camps and the trade looks like this.
Proprietary APIs buy you frontier capability on the hardest tasks, zero infrastructure burden, continuous improvement without migration effort, and speed: from idea to working prototype in an afternoon. They cost you per-token pricing that compounds brutally at scale, dependence on a vendor’s pricing trajectory and deprecation schedule, data flowing to third-party infrastructure (with whatever contractual protections you negotiated), and a ceiling on customisation.
Open weights buy you models that cannot be taken away, deprecated, or repriced; deployment wherever your data must live, which in regulated and sovereignty-sensitive contexts is decisive; deep customisation through fine-tuning on proprietary data, which is increasingly where real differentiation lives now that everyone rents similar frontier capability; and unit economics that improve with volume, with the self-hosting crossover typically landing between 10 and 30 million tokens a day. They cost you real operational burden (infrastructure, serving, monitoring, and roughly 0.5 to 1.0 full-time engineers of MLOps attention that teams chronically underestimate), a persistent gap on frontier reasoning tasks, and responsibility: when the model misbehaves, there is no vendor to escalate to.
One risk cuts both ways and deserves honest treatment: continuity. Proprietary vendors deprecate models and change prices. But open-weight model families depend on their originators continuing to release, and a lab can stop publishing weights at any time. Open weights protect you against losing what you have; they do not guarantee a supply of what comes next. A mature posture plans for both discontinuities.
Figure 1 summarises the trade as a side-by-side leaders’ view.
The answer is a portfolio, not a pick
The comparison in Figure 1 tempts a verdict, and resisting that temptation is the strategic move. Here is the reframe that resolves most of the argument: sophisticated organisations in 2026 are not choosing a side. They run a deliberate model portfolio behind a routing layer, and the pattern has become standard enough to describe precisely.
Frontier APIs for the hardest work and the fastest starts. New use cases prototype against a proprietary frontier model, because development velocity matters most when you are still discovering whether the use case works at all. Complex reasoning tasks stay there, because the capability gap is real where it is real.
Fine-tuned open weights for validated volume. Once a use case is proven and volume grows, high-frequency tasks migrate to a fine-tuned open model on controlled infrastructure, capturing the unit economics and the customisation. The proprietary API remains as a fallback for the edge cases the smaller model handles poorly.
Sovereign path for restricted data. Workloads whose data cannot leave your infrastructure run on self-hosted open weights, full stop. This lane is defined by the governance labels, not by economics.
This layered pattern (prototype proprietary, scale on open, keep a frontier backstop) has emerged independently across enough enterprises to be called the consensus architecture, and the routing gateway that implements it is the single most leverage-rich component in the stack: it converts model selection from an architectural commitment into a configuration change, and it is your negotiating position with every vendor.
Figure 2 shows the portfolio in operation: the three lanes, what routes where, and the migration path a use case travels over its life.
The migration arrow in Figure 2 is the part strategy documents usually omit and the part that generates the value. A use case is not assigned a lane forever; it is born in the frontier lane, validated, and then deliberately migrated when three conditions hold: volume justifies the fixed costs, quality on your evaluation suite (not public benchmarks, your suite) matches requirements, and the operating capability exists. Organisations that skip the third condition rediscover it in production.
What this demands of your organisation
The portfolio posture carries obligations, and pretending otherwise is how it fails.
An evaluation suite you own. Public benchmarks tell you about public benchmarks. Migration decisions need your tasks, your data, your quality bar, run identically against candidate models. This is the same evaluation infrastructure the pilot-to-production article will insist on; the model portfolio simply cannot operate without it, because “is the open model good enough” is unanswerable without a definition of enough.
MLOps capability, staffed honestly. The half-to-one FTE of serving and monitoring attention, plus the platform work to run inference at production reliability. Under-resourcing this is the classic failure of enthusiastic open-weight adoption, and it is why the maturity model matters: this posture assumes Stage 3 to 4 operations.
Licence and provenance governance. A register of which models run where, under which licences, with which fine-tuning data. Your governance track instincts apply: when a regulator or customer asks what model made this decision and what it was trained on, “a download from last spring” is not an answer.
A refresh cadence. The open ecosystem ships major releases monthly. You do not chase every release (that way lies madness), but a quarterly evaluation pass against your suite, with a deliberate upgrade decision, keeps the portfolio current without turning your engineers into leaderboard watchers. The pass costs a day or two once the harness exists, and it doubles as your early-warning system: a quarter in which the open candidates suddenly clear your quality bar on a workload you are paying frontier prices for is a quarter in which the routing table, not the architecture, needs to change. That is the whole point of the posture: the expensive decisions were made once, and the cheap ones can be made often.
The board-level summary
When this reaches your board, and increasingly it does, the framing I recommend is this. We run a model portfolio, not a model bet. Proprietary frontier models where capability demands it and speed pays; open weights where volume, customisation, or sovereignty demand it; a routing layer that lets us move workloads as the ground shifts, because it will shift. The posture costs us real operational investment and buys us three things no single-vendor strategy can: unit economics that improve with scale, data control that satisfies our regulators, and independence from any one vendor’s pricing and roadmap decisions.
That is a strategy that survives model releases, which is the only kind worth writing down.
Of course, a portfolio posture makes vendor relationships more numerous, not fewer: API providers, platform vendors, tooling suppliers, and the fast-multiplying crowd of AI-powered products all want a place in your stack. Cutting through their claims is a discipline of its own, and it is the next article.