How to Avoid AI Vendor Lock-In: Stop Buying a Model, Build the Harness
The gap between open-weight and closed frontier models is an interval, not a chasm. The sensible response is architectural: hold the switching cost in an orchestration layer you own, and let a costed workload, not a leaderboard, decide which model to plug in.
Ask how to avoid AI vendor lock-in and most answers reach for contract clauses and exit terms. That is the wrong layer to defend. Lock-in in AI systems is architectural rather than legal: once your prompts, tool integrations, evaluations and team habits are shaped around one vendor's API, the exit clause is decorative, because the real switching cost has already been paid in engineering time. The UK's Competition and Markets Authority made a version of this point in its review of AI foundation models, which flagged switching barriers and vertical tie-ups as the mechanisms most likely to harden the market. So the practical question is not whether you'll carry switching cost. It is where you choose to hold it.
Why is the frontier premium under pressure?
Closed-model pricing is priced off a gap: the distance between what the metered frontier can do and what everyone else can get for less. Analysis by Epoch AI estimated that the best open-weight models trail the closed frontier by something like a year, with the lag varying by benchmark and moving as new releases land. Whether that interval is shrinking remains genuinely contested, and honest buyers should treat it as an open question. What matters is its shape: it is an interval, not a chasm, and an interval has a price.
Most enterprise AI work is classification, extraction, drafting, summarisation and agent plumbing. Once a model that trails the frontier clears the bar for a given task, the buying standard for that task flips from best to sufficient, and it rarely flips back, because few procurement teams will pay a premium for capability the workload can't use. That claim needs its qualifier stated plainly: sufficiency is task-specific. A model that is sufficient for ticket summarisation may be nowhere near sufficient for contract review, which is why the whole argument runs through evaluation rather than instinct.
What does switching actually save? A worked example
Abstract talk of commoditisation persuades nobody with a budget, so start from a documented workload. Klarna reported that its AI assistant handled 2.3 million customer service conversations in its first month, work the company said was equivalent to 700 full-time agents. Those are Klarna's own figures and deserve the usual scepticism about self-reported success, but the volume is the useful part: call it roughly 28 million conversations a year.
Now do the arithmetic with current rate cards in hand. The token figures below are illustrative assumptions chosen for legibility, not Klarna's numbers or any vendor's quote. Assume a routine support conversation consumes about 3,000 input tokens and 300 output tokens once context and tool calls are included. At 28 million conversations a year, that is roughly 84 billion input tokens. Price those at $10 per million and the input bill alone is about $840,000 a year; price them at $1 per million on a cheaper model that passes the same evaluation suite and it is about $84,000. Published rate cards have recently differed by more than tenfold between flagship and budget tiers, but check the live numbers yourself before you build the business case: they move quarterly, which is rather the point. A spread of that shape, sustained across one high-volume workload, funds a serious amount of harness engineering.
When does a vendor-agnostic harness not pay?
Honesty demands the other column. Run the same arithmetic at 20,000 conversations a month and a tenfold spread is worth a few hundred pounds a month, which won't cover the maintenance of a single adapter, let alone a routing layer. A harness also struggles to pay when the workload depends on genuinely vendor-specific capability: a fine-tuned model, a caching discount your architecture is built around, or a tool-use behaviour rivals can't yet match. In those cases the premium is buying something real, and portability would mean giving it up. Comparisons must also be like for like. Setting one vendor's flagship against another's budget tier tells you about tiers, not vendors; compare models that pass the same evaluation bar, with hosting, data residency and support terms included, or the spreadsheet is fiction. The harness pays when volume is high, tasks are well specified, more than one model clears your bar, and you have the evaluations to prove it. Absent those conditions, standardising on a single vendor can be the rational choice, and pretending otherwise would be its own kind of marketing.
It also helps to discount the softer differentiators. Vendors sell feel: this model is thoughtful, that one is fast and irreverent. In practice, much of that felt character rides in a replaceable layer of instructions and defaults sitting on top of the weights, and a surprising amount of it travels when the same instructions are moved to a different model. A trait you can substantially reproduce with a page of text is thin grounds for a premium. The same discount applies to scarcity: sold-out tiers and throttled signups for a product priced per token are more plausibly demand management than evidence of quality, and are best read as marketing signals until a vendor explains the actual constraint.
How do you avoid AI vendor lock-in?
You stop trying to pick the permanent winner and relocate the switching cost to a layer you own. Concretely, that means prompt and context management, tool definitions, routing rules, logging and evaluation live in your orchestration layer, behind an abstraction that treats any model API as a plug. When the price or capability picture moves, swapping the model becomes a configuration change rather than a rewrite, and the worked example above becomes a decision you can take in a budget meeting rather than a migration you have to fear.
The harness earns its keep as a control surface too. Models will sometimes report work as complete when it isn't, so cross-vendor review, using one lab's model to audit another's output, is one of the more practical checks an enterprise can run, and it is only possible if the architecture is vendor-agnostic to begin with. We cover the governance side of this in our work on secure agentic systems and keeping humans in control of practical AI.
If leaderboards are gamed, what do you evaluate with?
Public benchmark leadership has stopped being useful for procurement: the popular suites are saturated and the incentive to tune for them is enormous. What replaces them is boring and yours: evaluation against your tasks, on your data, with your failure costs. NIST's AI Risk Management Framework makes the underlying point in standards-body prose: measurement only means something when the metrics fit the context and intended use of the system. A leaderboard can't tell you whether a model can do your job. An afternoon with your own evaluation suite can.
That suite is itself the anti-lock-in infrastructure. If you can score any candidate model against your work quickly, switching stops being frightening and becomes a routine cost decision, which is the whole game. This is readiness work, and it belongs before the build: the case for that ordering is set out in our piece on AI readiness before you build, and establishing it is exactly what an independent technical strategy engagement is for. The vendors are selling engines; buy the fuel on merit each quarter, and keep the engine in your own garage.
Questions people ask
Is an open-weight model good enough for enterprise use?
For most workloads the honest answer is: test it. Define what 'good' means for the specific task, then score candidate models against your own data. If a cheaper open-weight model clears your bar, the frontier premium is buying capability your workload can't use. The remaining questions (hosting, data residency, support) are engineering and procurement matters, not capability ones.
What does a vendor-agnostic AI orchestration layer actually contain?
A prompt and context store, tool and function definitions, routing and fallback logic, logging and observability, an evaluation harness, and a thin adapter so any model API is a plug. The test is simple: if swapping the underlying model is a configuration change rather than a rewrite, you own the harness. If it is a rewrite, the vendor owns you.
Does running multiple AI models cost more than standardising on one vendor?
There is real overhead: adapters to maintain, more evaluations to run, and occasionally a vendor-specific feature you have to forgo. Whether it pays is arithmetic, not doctrine: multiply your monthly token volume by the spread between the rate cards of models that pass your evaluation bar. High-volume workloads typically recoup the overhead the first time a cheaper model clears the bar; low-volume ones may never do, and saying so up front is part of the discipline.
Related
- AI Deskilling Is the Workforce Risk Your Board Isn't Pricing
- The Memory Oligopoly Behind AI's Cost Inflation
- Least privilege for AI agents is a 1975 idea your pilot is skipping
- AI & Automation
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.