LLM Vendor Lock-in: Why Switching Costs More Than You Think

Switching LLM providers costs more than the spreadsheet says. The issue isn't the API, it's prompt lock-in. Here's how to build a multi-provider strategy that works.

Why switching LLM providers costs far more than your spreadsheet says, and how to break free before it breaks your runway.

You've spent six months optimising your prompts. They encode your domain knowledge, your edge-case handling, and the kind of behavioural fine-tuning that only comes from production traffic. Right now, they're locked inside a single vendor.

Then your finance team does the maths.

Claude Sonnet 5.5 costs $2 per million input tokens and $10 per million output tokens (Anthropic pricing, 28 October 2026). OpenAI's GPT-6.1 Sol lists at the same $2/$10. GPT-6.1 Terra is significantly lower, priced at $1 for inputs and $5 for outputs (OpenAI pricing, 28 October 2026). The spreadsheet shows a potential 50% cost reduction. They want to know why you aren't making the change.

So you try. And that's when you discover the trap.

Your prompts don't work on the new model. Not in an obvious way, no errors, no crashes. Worse: they're subtly wrong. Summaries drift. Tone shifts. Safety guardrails get porous.

This isn't a hypothetical. A lead engineer shared their nightmare on r/ExperiencedDevs: they reported spending two weeks building a "semantic conversion layer" to translate prompts between providers. They achieved 85% fidelity, which sounds great until you realise that a 15% gap in production quality is a showstopper.

The "lock-in" isn't about the API. It's about the architecture of modern LLMs working exactly as designed.

The Lock-in Nobody Talks About

When CTOs evaluate LLM vendor risk, they typically think about API compatibility. Swap the endpoint and adjust the request format; done. Tools like LiteLLM and Portkey solved this years ago, and gateways such as Vercel's AI Gateway now charge the provider's list price with no markup on tokens (Vercel).

But API lock-in is the shallowest layer. The real cost sits deeper.

There are three types of LLM lock-in:

API Lock-in (Low Risk): Each provider has its own request/response schema. OpenAI uses messages, Anthropic uses content blocks, and Google uses parts. Abstraction libraries handle this. Migration effort: days, not weeks.
Prompt Lock-in (High Risk): A prompt optimised for Claude performs differently on GPT, and vice versa. Research from Accenture and UC Santa Cruz quantified this: a prompt optimised for GPT-5 that scored 99.4% on HumanEval dropped to 68.7% when transferred directly to Llama 3.1 70B Instruct (PromptBridge, December 2025). That's a 30-point performance collapse from the same instructions.
Evaluation Lock-in (Critical Risk): The most dangerous and least discussed. Your evaluation suites are tuned to expected outputs from a specific model. Switch providers, and your entire quality framework breaks. Not because the new model is worse, but because your tests assumed the old model's output patterns.

Fig. 1 — API lock-in is the shallow layer. The same prompt lost 30 points moving between models, and evaluation lock-in sits deeper still. Source: PromptBridge.

Is This Your Problem? (The Lock-in Checklist)

This might not be your problem. Some teams can switch providers with minimal friction. However, prompt lock-in hits hardest when:

You have 50+ production prompts built over 6–12 months.
Your prompts encode domain-specific logic and edge-case handling.
Output quality is customer-facing and measurable.
You operate under EU data residency requirements (GDPR, AI Act, Schrems II), meaning you can't simply default to a US-only provider if they lose compliance certification.
You're spending $10K+/month on LLM costs (enough to justify switching).

If three or more apply, you're already locked in. The question is whether you manage it or let it manage you.

Why Prompts Don't Port

The API problem was solved. The problem is that your engineering hours are being eaten up, and it's not because your engineers are doing something wrong.

The fundamental issue is architectural. Prompts aren't programming code; they are conditioning mechanisms that guide a model through a high-dimensional probability space.

Every model interprets prompts differently based on its training data, architecture, and fine-tuning. Here's why:

Syntax matters more than you think. OpenAI popularised JSON-based function calling. Anthropic emphasises XML-tagged structural prompting. Google's Gemini requires distinct safety configurations. These aren't cosmetic differences; they influence the model's attention mechanism. A prompt using Markdown headers for structure might be given lower priority by Claude, leading to instruction drift.
RLHF creates invisible dependencies. Each lab uses a different workforce and set of guidelines to align its models. OpenAI models tend toward conciseness. Anthropic's Claude defaults to thoroughness and explicit reasoning. When your prompt relies on GPT's tendency to be brief, moving that prompt to a verbose-by-default model requires rethinking your entire instruction strategy.
"Vibe coding" creates semantic debt. Developers iteratively tweak prompts until the output "feels right" on a specific model. This creates undocumented dependencies on idiosyncrasies. Unlike technical debt, semantic debt does not generate compiler warnings. The failure mode is silent: the system continues to run, but quality degrades.

The Real Cost of Switching

Enterprise AI migrations rarely cost what the business case says. For LLM-specific switches, here is what the spreadsheet misses:

The Hidden Migration Ledger

Cost Category	Impact	Visibility
API and compute migration	Token pricing delta + infrastructure	High
Prompt rewriting	Weeks of engineering time per prompt library	Low
Evaluation suite reconstruction	Full regression and validation cycles	Hidden
Quality degradation risk	Output quality drop during transition	Hidden
Delayed feature roadmap	Every migration hour displaces product work	Hidden

Fig. 2 — The spreadsheet sees the list-price saving. The costs below the line decide whether it survives. Sources: Anthropic pricing, OpenAI pricing.

Most teams underestimate total migration effort. That 50% cost saving evaporates when you factor in two months of your senior engineer's time, a regression in output quality, and the features you didn't ship.

Breaking Free: A Practical Framework

You don't need a "conversion layer." Translation assumes one canonical prompt. Reality is different: each model benefits from a different prompt architecture.

The winning approach is to embrace that, manage it systematically, and let data drive decisions.

Fig. 3 — Five steps that turn a provider switch from a multi-week engineering project into a data query.

Step 1: Separate intent from implementation.

Define what your prompt needs to accomplish separately from how it's formatted for a specific model. Your intent layer is portable. Your implementation layer is model-specific. Keep both versions.

Step 2: Establish evaluation baselines per provider.

Before considering any migration, run your evaluation suite against 2–3 providers. Not synthetic benchmarks. Your production prompts, edge cases, and scoring against your quality criteria.

Step 3: Maintain parallel prompt versions.

For your highest-value use cases, maintain optimised prompts for at least two providers. The overhead is manageable with proper version control. The insurance value is enormous.

Step 4: Route by capability, not by default.

Once you have parallel prompt versions (Step 3), you can route strategically. Anthropic leads in coding, with an estimated 54% of the enterprise coding market, driven in large part by Claude Code (Menlo Ventures, December 2025). Gemini excels at multimodal and long-context. OpenAI's GPT models remain strong for general reasoning. But this only works if you've already invested in optimised prompts for each provider, not if you're trying to apply the same prompt across all providers.

Step 5: Invest in prompt version control.

Multi-model strategies are already mainstream: 37% of enterprise CIOs surveyed use five or more models (a16z, June 2025). But without version control, teams manage prompts in code repositories, spreadsheets, or individual engineers' heads.

There's no way to compare how v3 of a summarisation prompt performs on Claude versus GPT versus Gemini. No way to roll back when a model update breaks output quality. No audit trail for compliance teams.

With proper prompt management, the switching-cost problem transforms from a multi-week engineering project into a data query: "Which provider delivers the best quality-per-dollar for this use case, given our constraints?"

Your Prompts Are Your Most Valuable AI Asset

The companies that treat prompt management as infrastructure will have an asymmetric advantage.

When Finance asks about cost optimisation, they'll have actual performance-per-dollar data across providers. When Legal raises vendor-concentration risk, they'll already have production-ready alternatives baselined. When Compliance flags EU data residency, it will display prompts already optimised for compliant providers.

ProNova builds its agents on Claude and OpenAI, with Vercel where spending limits, a backup model or strict data rules matter most, and keeps every design portable, so a provider switch stays an option rather than a project. The agent runs in your own account, and the code lives in your repository.

You've invested months building prompts that encode real IP domain knowledge, edge-case handling, and behavioural calibration that only comes from production traffic. That IP shouldn't be held hostage by a single vendor's pricing or compliance decisions.

Manage it accordingly.

Services