The Problem
When you build on LLM APIs, you inherit their fragility. A provider can deprecate a model, change pricing, or restrict regions — and your entire stack breaks overnight. The fix isn't to avoid LLMs; it's to know where your dependencies are before they bite you.
What Vendor Lock-In Actually Looks Like
Most teams think lock-in means "I can't switch providers." That's only half of it. Real lock-in hides in:
- Prompt formats: One provider's function-calling syntax that you've hand-tuned for months
- Embedding models: Vectors that only make sense in one provider's space
- Tool definitions: MCP servers that assume one backend's quirks
- Pricing tiers: A workflow that's only economical at one provider's rates
A Simple Audit You Can Do in 10 Minutes
- List every LLM call in your codebase. Count them. If you can't, that's your first finding.
-
Score each one on a 1-5 scale:
- 1 = pure stdlib, any provider works
- 5 = hardcoded to one provider's exact API shape
- Find your average. Above 3.5 means you have real migration risk.
- Write down the migration cost for your top 3 highest-scoring calls. Be honest: days of engineering, or hours?
The Pattern That Survives
The teams that migrate well don't use fewer providers — they make every call interchangeable by default: one interface, a config file that maps names to endpoints, and a fallback chain. The day one provider has an incident, you flip a switch.
What to Watch
- Deprecation notices: Most providers give 30-90 days. Set a calendar reminder for each.
- Pricing changes: Track the per-token cost of your top 3 models monthly. A 20% jump is a migration trigger.
- Regional availability: If your provider goes down in your region, what's the backup?
The Question
What's the highest-scoring LLM dependency in your stack right now — and how long would it take you to replace it?
This post is a teaching piece with no product links and no signup steps — everything above works with the tools you already have.
Top comments (0)