The lock-in is the prompts, not the API

TL;DR. A Dataiku and Harris Poll survey of 600 enterprise CIOs found 81% expecting to rely on two or more LLM providers in 2026, and 93% saying different models perform better for different use cases. An a16z survey of 100 CIOs found 37% running five or more models in production, up from 29%. Reported switching costs run 19 to 34%, with one documented migration of 40 workflows costing $315,000 and three months after a vendor collapsed, during which customer-facing features were degraded or unavailable. And the useful observation is a comparison. The ERP wave created large switching costs that were visible: multi-year projects with price tags and board approval. AI switching costs accumulate through ordinary engineering decisions nobody escalates, and the thing that creates them is not the API. It is the prompts, guardrails and evaluations built around the model.

---

Status: consistent direction, and the literature is almost entirely written by parties selling abstraction layers. AI gateway vendors, orchestration platforms and consultancies produce most of the switching-cost estimates, and a finding that lock-in is expensive is the most commercially useful conclusion available to them. The two CIO surveys state their samples, which puts them above the cost estimates. Attributions are given throughout.

---

What enterprises are actually doing

Dataiku with Harris Poll surveyed 600 enterprise CIOs worldwide. 81% expect to rely on two or more LLM providers in 2026 to stay competitive. 93% say different models perform better for different use cases, requiring continual evaluation and switching.

An a16z survey of 100 enterprise CIOs found 37% running five or more models in production, up from 29% a year earlier.

Multi-model is not an aspiration. It is the majority position, and the stated reason is capability variation across tasks rather than negotiating leverage.

Reported concern is high and reported preparation is not. 81% of enterprise leaders report concern about AI vendor dependency, 45% say lock-in has already hindered their ability to adopt better tools, and 84% factor digital sovereignty into their AI strategies.

Which is the familiar pattern from the data readiness article: near-universal awareness alongside a much smaller number who have done anything structural about it.

The comparison that does the work

Switching costs are not new and enterprise software has produced them before. What changed is their visibility.

The ERP wave of the 1990s and early 2000s created very large switching costs, and those costs were visible. Migration projects took years, carried defined price tags, and required explicit board approval. Incurring the dependency was itself a decision somebody made deliberately.

AI dependencies accumulate differently. A team prototypes with whichever model was convenient, writes prompts against its behaviour, builds evaluations against its outputs, tunes guardrails to its failure modes, and ships. No stage of that requires approval, and no stage of it looks like a commitment.

One analysis states the structural point precisely: enterprise buyers in 2026 are acquiring switching costs from several major AI vendors simultaneously, and almost none has a methodology for measuring what that accumulation means for their negotiating position two years out.

Switching costs accumulate before anyone notices them. That is what makes them effective as a competitive moat and dangerous as a strategic liability, and the reason is that they arrive through engineering decisions rather than procurement ones.

Where the cost actually sits

This is the part most coverage misses and it connects directly to a finding elsewhere in this territory.

The API is not the lock-in. Provider APIs are broadly similar, an abstraction layer normalises them, and swapping an endpoint is a small engineering task. If the API were the dependency, gateways would solve it and the problem would be closed.

The dependency is everything built against a specific model's behaviour. Prompts tuned to how one model interprets instructions. Guardrails calibrated to its particular failure modes. Evaluation suites whose thresholds were set on its outputs. Few-shot examples chosen because they worked. Agentic workflows whose orchestration assumes specific latency, tool-calling behaviour and error patterns.

One observation captures the mechanism: as companies invest in building guardrails and prompting for agentic workflows, they become more hesitant to switch.

Which is the scaffolding finding from the other side. That article established that a benchmark score belongs to an assembled system rather than to a model, because scaffolding moved one browser benchmark from a 14.41% baseline to 61.7%. The scaffolding is where the performance lives.

So the scaffolding is also where the lock-in lives, and it is the same object. The asset an organisation builds to make a model work is the asset that makes leaving expensive. Those are not two problems requiring a trade-off. They are one artefact with two properties, which is why an abstraction layer at the API level addresses the smaller half.

The numbers, and their provenance

Switching cost estimates cluster and none has a published methodology.

One analysis puts switching at 19 to 34% of the original implementation cost. Another puts average migration at $315,000. Data format conversion is reported to add 10 to 30% to migration cost. Single-vendor strategies are claimed to expose enterprises to up to 80% in unnecessary costs through limited model choice and pricing dependency.

The one documented case is more useful than any of the estimates. After the collapse of Builder.ai, a manufacturing enterprise spent $315,000 and three months migrating 40 AI workflows to a new platform, a cost explicitly attributed to the absence of a provider-agnostic abstraction layer. During that period several customer-facing AI features were degraded or unavailable.

That is roughly $7,900 per workflow, with an outage cost nobody quantified, and it is a single case at one company, reported by parties selling the remedy.

Every one of those figures comes from a vendor selling gateways, orchestration or migration services. The direction is consistent and the magnitudes are unestablished, which is commissioned framing in its ordinary form: the parties measuring switching costs are the parties selling protection from them.

The cost structure underneath

Two figures reframe what the dependency is attached to.

By 2026, inference accounts for roughly 85% of enterprise AI budgets, driven by agentic workflows that trigger ten to twenty model calls per task rather than one.

Enterprise generative AI spend reached $37 billion in 2025, more than tripling year on year, and 86% of enterprises report increasing AI budgets in 2026.

So the dependency is on a recurring operational cost rather than a licence, which changes its character. An ERP dependency was a sunk implementation with predictable maintenance. A model dependency is an ongoing meter that the counterparty prices.

And it makes the pricing exposure concrete. An organisation whose scaffolding is tuned to one model, running ten to twenty calls per task, on a budget where inference is 85% of the total, has a cost base its provider can reprice and a switching cost its own engineers created without noticing.

Self-hosted open-weight models are reported to reach up to 90% lower inference cost for suitable workloads, which is the escape valve most often named and which carries its own operational burden that the same sources rarely price.

What reduces it, and what the evidence for that is

The recommended measures are consistent across sources and their evidence base is thin.

Route calls through an abstraction layer so application code addresses a gateway rather than a provider. This is the most-recommended measure and it addresses the API layer, which this article has argued is the smaller half of the problem.

Maintain two or three providers in production, which 37% of surveyed CIOs already do.

Negotiate data portability and exit terms in the contract, which is the same conclusion the outcome pricing article reached about unit definitions: the load-bearing half of an arrangement should sit in the document that binds.

Keep prompts, evaluations and guardrails model-agnostic where possible, which is the measure that addresses the actual dependency and is by far the hardest, because a prompt that works across models is usually worse on each of them than one tuned to it.

None of these has a published before-and-after measurement. They are architectural recommendations from parties selling the architecture, and the reasoning is sound while the evidence is absent.

Where the dependency actually lives, layer by layer

Separating the layers shows why the most-recommended remedy addresses the least of it.

The top two rows are what abstraction layers exist for and they are the rows that were never expensive.

The bottom four are the migration, and they share a property worth naming: each was created by somebody solving a real problem well. A guardrail exists because a specific failure was observed. An evaluation threshold exists because somebody calibrated it against real outputs. Nobody built lock-in. They built quality, and lock-in is what quality looks like from the outside.

Which explains why the recommendation to keep prompts model-agnostic is rarely followed even by organisations that state the concern. It asks a team to accept worse performance today against a switching cost that may never be paid, and no source quantifies either side of that trade.

The honest version of the advice is narrower than the literature's. Portability is worth buying at the top two layers, because it is nearly free. At the bottom four it costs output quality, and whether that is worth paying depends on a probability of switching that nobody has estimated.

What an organisation could measure

The most actionable claim in this literature is also the least evidenced: that buyers are accumulating dependency across several vendors with no methodology for tracking it. That methodology is not difficult.

Count the model-specific artefacts. Prompts referencing a provider's behaviour, guardrails tuned to observed failure modes, evaluation thresholds calibrated on one model's outputs, orchestration assuming particular tool-calling semantics. A number, per system, that can be tracked over time.

Estimate the rebuild, not the migration. The relevant question is not what it costs to change an endpoint. It is how many of those artefacts would need re-tuning and re-validating, which is an engineering estimate any team can produce in an afternoon for a system they built.

And run one portability test. Take a single production workflow, point it at a second provider without re-tuning, and measure the quality drop. That number is the switching cost, expressed in the unit that matters, and it is obtainable for the price of an afternoon of inference.

None of these requires a vendor, a gateway purchase or a consultancy. They require somebody to ask a question the current literature answers with estimates from parties selling the answer.

Which is where this territory keeps arriving. The measurement is cheap, the data is internal, the obligation is absent, and the finding would be uncomfortable for whoever commissioned it.

Three things this establishes

A commitment that arrives without a decision is the hardest kind to manage. ERP switching costs required board approval to incur. AI switching costs are created by a prototype choice and deepened by every prompt written afterwards, and no stage of that presents as a commitment.

The asset and the liability are the same object. The scaffolding that makes a model perform is the scaffolding that makes it expensive to leave. An organisation cannot reduce its lock-in without reducing the specificity that produced its results, and no source that recommends model-agnostic prompting states this trade-off.

And the exposure is on an operational meter rather than a sunk cost. With inference at roughly 85% of AI budgets and agentic workflows multiplying calls per task, the dependency is a recurring price the counterparty sets, which is a materially different position from a licence renewal.

What it does not establish

That multi-model architectures reduce cost. They add orchestration, monitoring and prompt standardisation complexity, which the sources recommending them acknowledge and do not price.

That the switching cost figures are reliable. 19 to 34%, $315,000 and 10 to 30% all come from parties selling migration or gateway products, and none publishes a method.

That lock-in has caused widespread harm. 45% reporting that it hindered adopting better tools is a survey response, and the one documented migration followed a vendor collapse rather than a routine switch.

And nothing about any specific provider. The dynamic described here is structural and applies to every vendor in the market.

What is unresolved

What a real switching cost is. No organisation has published a measured migration with its components broken out, and the single documented case had an unusual trigger.

Whether model-agnostic prompting is viable at quality. The trade-off is named nowhere in the recommendation literature, and no comparison of tuned against portable prompt performance exists publicly.

How much of the 85% inference share is genuinely portable. Cost comparisons assume equivalent output quality across providers, which the CIO survey directly contradicts by reporting that 93% see different models performing better for different use cases.

And whether anyone measures accumulation. The observation that buyers are acquiring dependency from several vendors simultaneously without a methodology for tracking it is the most actionable claim in this literature and the least evidenced.

The counter-argument

Lock-in may be the correct trade rather than a failure. A prompt tuned to one model performs better than a portable one, and an organisation optimising for output quality is making a defensible choice. Treating specificity as a liability assumes switching is likely, and most organisations will not switch primary providers in a given year.

The abstraction layer literature is written by abstraction layer vendors. Every recommendation in this article traces to a company selling gateways, orchestration or migration, and the strongest version of their case is also their sales pitch. This corpus has stripped out vendor framing elsewhere and cannot fully do so here without leaving nothing.

The ERP comparison flatters the past. ERP switching costs being visible did not stop organisations incurring them, and multi-year lock-in with board approval is not obviously better than incremental lock-in without it. Visibility is being treated as though it produced good decisions, and the ERP record does not support that.

And the multi-model finding may show capability shopping rather than risk management. 93% of CIOs report different models being better for different use cases, which is a reason to use several that has nothing to do with lock-in. This article reads a capability behaviour as a strategic one, and the surveys do not distinguish them.

The short version

Dataiku and Harris Poll surveyed 600 enterprise CIOs and found 81% expecting to rely on two or more LLM providers in 2026, with 93% reporting different models performing better for different use cases. An a16z survey found 37% of CIOs running five or more models in production, up from 29%.

Concern is near-universal and structural preparation is not. 81% report concern about vendor dependency and 45% say lock-in has already prevented them adopting better tools.

The useful comparison is with ERP. That wave created very large switching costs and they were visible: multi-year projects, defined price tags, board approval. AI switching costs accumulate through prototype choices and prompt writing, and no stage of that presents as a commitment.

And the dependency is not the API. Provider interfaces are similar and a gateway normalises them. The dependency is the prompts tuned to one model's interpretation, the guardrails calibrated to its failure modes, the evaluations whose thresholds were set on its outputs, and the agentic orchestration assuming its latency and tool-calling behaviour.

Which is the scaffolding finding inverted. Scaffolding is where the performance lives, so scaffolding is where the lock-in lives. The asset and the liability are one artefact, and no source recommending model-agnostic prompting states that portability costs quality.

Reported switching runs 19 to 34%, with one documented case at $315,000 and three months for 40 workflows after a vendor collapse, during which customer-facing features were degraded. Every one of those figures comes from a party selling protection against the thing it measured.

Common questions

How many enterprises use more than one model? Most, and it is rising. A Dataiku and Harris Poll survey of 600 enterprise CIOs found 81% expecting to rely on two or more LLM providers in 2026, and an a16z survey of 100 CIOs found 37% running five or more models in production, up from 29% a year earlier. The stated reason is capability variation rather than negotiating leverage: 93% of CIOs report different models performing better for different use cases, requiring continual evaluation.

What makes AI lock-in different from previous software lock-in? Visibility. The ERP wave of the 1990s and 2000s created very large switching costs, but incurring them was a deliberate decision: migration projects ran for years, carried defined price tags and required board approval. AI dependencies accumulate through a prototype choice and every prompt written afterwards, none of which presents as a commitment or requires escalation. Switching costs accrue before anyone notices, which is what makes them effective as a moat and dangerous as a liability.

If the API is standardised, where is the actual dependency? In everything built against a specific model's behaviour. Prompts tuned to how one model interprets instructions, guardrails calibrated to its particular failure modes, evaluation suites whose thresholds were set on its outputs, few-shot examples chosen because they worked, and agentic orchestration assuming specific latency, tool-calling behaviour and error patterns. As one observation puts it, the more a company invests in guardrails and prompting for agentic workflows, the more hesitant it becomes to switch.

Why is that the same thing as the scaffolding finding? Because agent benchmark scores are properties of assembled systems rather than of models, with one browser benchmark rising from a 14.41% baseline to 61.7% largely through planner-executor-memory architecture. The scaffolding is where the performance lives. It is therefore also where the lock-in lives, and it is the same artefact. An organisation cannot reduce its switching cost without reducing the specificity that produced its results, which is a trade-off the recommendation literature does not state.

What do switching costs actually run to? The estimates are unmethodical and cluster: 19 to 34% of original implementation cost, an average migration figure of $315,000, and data format conversion adding 10 to 30%. The one documented case is more informative than any estimate: after Builder.ai's collapse, a manufacturing enterprise spent $315,000 and three months migrating 40 AI workflows, roughly $7,900 per workflow, with several customer-facing features degraded or unavailable during the period and no quantified outage cost.

Why does the cost structure matter? Because the dependency attaches to a recurring meter rather than a sunk implementation. By 2026 inference accounts for roughly 85% of enterprise AI budgets, driven by agentic workflows triggering ten to twenty model calls per task rather than one, against enterprise generative AI spend of $37 billion in 2025 and 86% of enterprises increasing budgets. An organisation with model-specific scaffolding, on that cost base, has an ongoing price its counterparty sets and a switching cost its own engineers created without noticing.

What reduces exposure? The consistent recommendations are an abstraction layer routing calls through a gateway, two or three providers in production, contractual data portability and exit terms, and keeping prompts, evaluations and guardrails model-agnostic. The first addresses the API layer, which is the smaller half of the problem. The last addresses the real dependency and is by far the hardest, because a prompt that works across models is usually worse on each than one tuned to it. None of these measures has a published before-and-after measurement.

How much should this literature be trusted? The two CIO surveys state their samples and are the firmer part. Everything about switching costs comes from AI gateway vendors, orchestration platforms and consultancies selling migration, for whom a finding that lock-in is expensive is the most commercially useful conclusion available. The direction is consistent and the magnitudes are unestablished. A further caution is that the multi-model finding may describe capability shopping rather than risk management, since 93% of CIOs cite task-specific performance as the reason, which has nothing to do with lock-in.