Vendor Lock-In Costs: Measure It Instead of Fearing It

Lock-in gets discussed as a binary — you are locked in, or you are not — and the discussion usually fixates on the part that costs almost nothing to change. Swapping one OpenAI-compatible endpoint for another is a base URL and a key. That is not where the money is.

The expensive bindings are the ones you accumulated without deciding to: prompts tuned against one model's quirks, a tool schema shaped by one provider's parser, an evaluation baseline that only exists as numbers from one model, and cache behaviour your latency budget silently depends on. Those are worth measuring, because you cannot manage a cost you have never estimated.

What is genuinely portable

The transport layer is a solved problem. Most serious providers expose an OpenAI-compatible surface, and the ones that do not are wrapped by a gateway in an afternoon. Authentication, request shape, response parsing: none of this binds you.

Model choice, by itself, is also more portable than it feels. If your workload is a single-turn generation with loose output requirements, moving it is close to free — change the model string, spot-check a sample, ship.

The instinct to treat the API surface as the lock-in risk comes from cloud, where it genuinely was. Here it is the cheap layer, and treating it as the problem produces abstraction work that buys you very little.

Prompt tuning is the largest hidden binding

Every prompt in production that has been iterated on more than twice is tuned to a specific model's behaviour, whether or not anyone intended it. The phrasing that stopped it padding the answer, the ordering that stopped it ignoring the second instruction, the example that fixed a format it kept getting wrong — all of those are corrections to one model's tendencies.

Move to a different model and those corrections become noise at best. At worst they actively hurt, because you are still compensating for a failure mode the new model does not have while its own failure modes go unaddressed.

The cost is not rewriting the prompt; it is rediscovering, by iteration, which instructions the new model needs. For a mature production prompt that is days of work per prompt, not hours, and it does not parallelise well because each change needs evaluating.

To contain it: keep prompts in versioned files rather than inline strings, keep a plain-language statement of intent next to each one, and mark which lines exist as model-specific workarounds. When you migrate, the marked lines are the ones to delete first. Prompt templates and versioning covers the mechanics.

Tool-call format binds harder than it looks

Function calling is nominally standardised and practically is not. Models differ in how strictly they honour JSON Schema, whether they emit parallel tool calls, how they behave when a required field is missing from the input, and how they recover after a tool returns an error.

The binding is in your schemas. A schema that works reliably with one model has usually been shaped around that model's parser — flattened where nesting caused trouble, with descriptions that exist because the model kept guessing wrong. Those shapes do not transfer cleanly.

Agent code compounds this. Retry logic, argument validation and error-message phrasing are all tuned to how one model responds to being corrected. That is the part that takes longest to re-tune and the part least likely to be covered by tests.

Containment is straightforward but has to be deliberate: design schemas to the specification rather than to the model, keep the descriptions factual rather than corrective, and test your schemas against a second model occasionally even if you have no plans to switch. Tool schema design covers what portable schemas look like.

Evaluation baselines are a quiet dependency

If your only evidence that the system works is a set of scores produced by the current model, you cannot evaluate a replacement without rebuilding the measurement first.

This is the binding that catches teams by surprise, because the evaluation feels like an asset rather than a dependency. It is an asset only if it is model-independent: fixed inputs, expected outputs or graded criteria, and a harness that does not assume anything about response format.

Baselines built by eyeballing outputs are worse than none, because they create the impression that a comparison is possible when it is not. The first cost of any migration is then rebuilding the evaluation, before a single prompt gets touched.

Keep evaluations on your own tasks, versioned alongside code, with the harness separated from the model client. Building a model eval harness and evaluating models on your codebase cover the shape. This is the single highest-value thing you can do to keep options open.

Caching semantics create a performance dependency

Prompt caching changes both cost and latency, and the rules vary: what makes a cache hit, how long entries live, whether hits are automatic or must be marked, and how the discount is applied.

Teams architect around whatever their provider does — a long shared prefix, a stable system prompt at the front, request ordering chosen to maximise hits. That architecture is a dependency on those specific semantics.

Move providers and the same request shape may produce a different hit rate, which shows up as a cost increase and a latency increase at the same time, often after launch when the traffic pattern is real. It is one of the more common unpleasant surprises in a migration.

Containment: record your cache hit rate as a first-class metric, and know what your cost and p95 latency look like with caching disabled. That number is your floor, and it tells you how exposed you are. Prompt caching explained covers the variation between providers.

A way to actually measure it

Estimate lock-in as the engineering cost of a forced move, not as a feeling. Four line items, each in person-days.

Rebuilding or validating the evaluation harness. Re-tuning each production prompt, counted per prompt rather than in aggregate. Re-testing every tool schema and the agent code around it. Re-establishing cost and latency targets under different caching behaviour, plus whatever dual-running period you would need before cutting over.

Sum it and you have a number in days. That number is your lock-in cost. It also tells you exactly where to spend containment effort: whichever line item is largest is the one worth loosening, and for most teams it is either prompts or evaluations rather than anything to do with the API.

What is worth paying to avoid

Not all lock-in is bad. Accepting a provider-specific feature that saves real money or latency is often correct — the mistake is accepting it without knowing what it would cost to give up.

The rule that holds up: keep the cheap layer thin and the expensive layer explicit. Do not build an elaborate abstraction over the HTTP call, because it is already portable. Do put effort into model-independent evaluations, specification-shaped tool schemas and prompts whose model-specific parts are labelled.

Then, when a better or cheaper model appears, the question becomes an arithmetic one rather than an argument. When to switch models is a much easier decision when you already know what switching costs.