LLM Vendor Lock-In Risk Cost Calculator

LLM vendor lock-in risk cost calculator

Building everything around one provider is fast — until that provider raises prices or your volume explodes. Lock-in means the cost to leave (rewriting code, re-prompting, re-testing, recreating fine-tunes) can exceed the savings of a cheaper alternative. This calculator quantifies that trade-off and tells you the breakeven timeline in months.

The four components of migration cost

When teams estimate migration effort, they consistently undercount. The hidden components add up quickly:

API integration code. Each provider has a different request schema, authentication method, streaming protocol, and error handling pattern. Rewriting the integration layer is the most visible cost and usually the one teams estimate first.

Prompt engineering work. This is the most underestimated component. A system prompt carefully tuned for one model over weeks of iteration does not transfer cleanly. Different models interpret instructions differently, have different tendencies for format and verbosity, and handle edge cases in model-specific ways. You need to re-engineer, re-evaluate, and re-validate prompts for the new model.

Test and eval suite execution. If you have an evaluation suite, every test case needs to be re-run against the new model to establish a new baseline. Regressions need to be investigated and re-prompted. This is calendar time, not just dev-days.

Fine-tune or RAG reconstruction. If you use fine-tuned models or retrieval systems optimized for a specific model’s embedding space, those need to be rebuilt. Fine-tuning a new model requires labeled data, compute, and validation time.

How it works

The tool compares your spend after a price increase against the alternative provider’s spend, and weighs the monthly savings against the one-time cost of migrating:

migration_cost  = dev_days × dev_day_cost
monthly_savings = projected_spend_current − projected_spend_alternative
breakeven_months = migration_cost / monthly_savings

If breakeven is short (a few months), switching is an easy call. If it stretches past a year — or savings are negative — staying put and absorbing the increase is often the rational choice.

Illustrative worked example

Suppose your current monthly LLM spend is £2,000 and a provider raises prices 30%, taking it to £2,600. An alternative provider would cost £1,800/month for equivalent capability.

Monthly savings from switching: £2,600 − £1,800 = £800/month (for example)

Migration effort: 8 developer-days (integration + re-prompting + testing) at £600/day = £4,800 one-time cost (for example)

Breakeven: £4,800 / £800 = 6 months

If you expect to use the alternative for well over 6 months and quality risk is low, switching is rational. If the lock-in period is uncertain or there is quality risk, absorbing the price increase may be more sensible. The calculator lets you test your own numbers rather than relying on a worked example.

Tips and notes

• Keep a thin provider-abstraction layer so the migration dev-day count stays low; that single architectural choice is what shrinks lock-in risk most.
• Re-prompting is usually the hidden cost — different models need different prompts and re-validation, so don’t under-budget the dev-days.
• Use this alongside a multi-provider spend view: sometimes the answer is to split traffic rather than fully migrate, hedging the lock-in entirely.