The common reading of open-weight models is that they level the field: capable models available to anyone, no dependence on a handful of labs, the end of proprietary advantage in AI.
Half of that is right. Access has genuinely broadened, and the capability gap between the best open weights and the best proprietary models has narrowed to a degree that would have seemed implausible two years ago.
What has not happened is the disappearance of advantage. Advantage moved, and the place it moved to is less accessible than the models ever were.
The base model is now an input
Consider what a company with open weights actually has: a general-purpose model trained on public data, equivalent to what every competitor has, capable of general reasoning and no specific knowledge of any business.
That is a raw material. It confers no advantage precisely because it is available to everyone, in the same way that having access to the same cloud provider as your competitors confers none.
What converts the raw material into something differentiated is post-training on data nobody else holds. Edgewisely’s analysis of an enterprise reasoning model post-trained on open weights using proprietary data describes the play clearly, and its observation that every software company sitting on a data moat is about to run the same one is the important part. The base model is fungible. The data is not.
This inverts the strategic picture. When frontier models were closed and scarce, the advantage sat with whoever had access. Now that capable weights are broadly available, the advantage sits with whoever has something unique to apply them to — which favours incumbents with years of accumulated operational data over well-funded newcomers with none.
Why the barriers moved rather than fell
Three barriers replaced the one that came down.
Proprietary data at sufficient quality. Not merely having data, but having it labelled, consistent, permissioned and representative of the task. Most organisations that believe they have a data moat have an unlabelled archive, which is a different thing and considerably less valuable.
The engineering capability to post-train. Adapting a base model is meaningfully harder than calling an API. It requires people who understand training dynamics, evaluation design and the failure modes of fine-tuning. That skill set is scarce and expensive, and it is not the same skill set as prompt engineering.
The evaluation infrastructure to know whether it worked. This is the one most organisations lack entirely. Without a reliable way to measure whether a post-trained model is better than the base on the tasks you care about, you cannot iterate, and you cannot safely deploy. Teams frequently discover that building the evaluation harness costs more than the training run.
Each of these is more expensive than API access ever was. Open weights lowered the barrier to entry and raised the barrier to advantage — which are different barriers, and conflating them produces bad strategy.
The operational consequences
For organisations planning around this, several things follow.
Portability is worth designing for. If base models are interchangeable inputs, the ability to swap them is a genuine capability rather than a theoretical nicety. That means an abstraction layer between your application and whatever model is behind it, and it means your evaluation harness has to be model-agnostic. Edgewisely’s comparison of a self-hosted gateway against a hosted aggregator covers the practical options and their cost structures; the strategic point is that whichever you choose, the switching cost should stay low deliberately.
Data rights need checking before they matter. Whether you may use customer data to improve a model is a contractual question that most existing agreements answer badly or not at all. Companies discovering this during a training project rather than during contract negotiation lose months, and sometimes lose the option entirely.
Governance moves onto the critical path. Post-training on proprietary data requires knowing precisely what that data contains, where it came from, and what restrictions attach. Organisations without that clarity cannot run this play safely, regardless of how much data they hold.
Model behaviour becomes your responsibility. When you use a hosted model, the provider’s instruction hierarchy and safety posture is a control you inherit — and it is worth understanding, since as Edgewisely notes in its examination of how one provider turned model safety into a ranked instruction hierarchy, the ranking determines what happens when instructions conflict. Post-train your own and you own that question, including what the model does when a user’s instruction conflicts with your policy. Most teams running fine-tuning projects have not thought about it at all.
When open weights are the wrong answer
There is a countervailing case, and teams enthusiastic about self-hosting tend to underweight it.
Running your own models means owning the operational surface: capacity planning, GPU availability, upgrade cycles, incident response at three in the morning when inference is degraded and nobody on call understands why. That is a real function with real headcount, and it is frequently justified on a cost comparison that counts inference spend and omits the engineers.
The honest comparison is total cost of ownership at your actual utilisation. Hosted APIs are priced per unit and scale down to nothing when traffic is low, which suits variable or early-stage workloads. Self-hosting has a high fixed cost and low marginal cost, which suits high, steady, predictable volume. Crossing that line is a volume question with a clear answer, and it is usually calculated once and then never revisited as circumstances change.
There is also a capability question. Frontier hosted models generally remain ahead of the best open weights on the hardest reasoning tasks. If your application genuinely sits at that frontier, self-hosting means accepting a capability gap in exchange for control. If it does not — and most production applications do not — the gap is irrelevant and the control is worth having.
The pragmatic architecture for most organisations is neither: hosted models for the hard tail, self-hosted or smaller models for the high-volume routine work, and an abstraction layer that lets the boundary between them move as both economics and capability change.
Who this is bad news for
The companies most exposed are the ones whose product was a thin layer over a frontier API with no proprietary data underneath. Their differentiation was access and interface, and both are now cheap.
The companies best placed are unglamorous incumbents with years of domain-specific operational data, existing customer relationships, and a reason for that data to exist. They were widely expected to be disrupted by AI-native competitors. They are now holding the scarce input.
That is not the outcome most commentary predicted in 2023, and it has a certain historical symmetry: the technology everyone believed would level the field has, as usual, advantaged whoever already owned the thing that could not be copied.
