Vendor Lock-In
Wiring your agent directly to one provider's SDK — so switching providers costs you a rewrite.
Intent & Description
🎯 Intent
Calling one provider’’s SDK directly throughout application code — request shapes, streaming format, tool-call contracts — with no adapter layer.
📋 Context
One provider offers a useful feature, the SDK is right there, and there’’s “no immediate plan for a second provider.” Fast-forward 18 months: the provider has an outage, raises prices, or a better model ships elsewhere. Switching is now a rewrite.
💡 Solution
Use a provider-agnostic abstraction from day one: Vercel AI SDK, LiteLLM, Mastra’’s provider/model string, or OpenAI-API-compatible adapters. Keep provider-specific features behind capability flags, isolated in feature modules — not threaded through the agent loop. See provider-string-routing, provider-fallback, multi-model-routing.
Real-world Use Case
- Never as a deliberate choice; if you must bind to one provider for a feature, isolate the binding behind a feature module.
- Treat the provider as a swappable adapter from the first commit; retrofitting abstraction later is expensive.
- Even single-provider deployments benefit from an adapter — outages and price changes do happen.
Source
📌 TL;DR
Treat your model provider as a swappable adapter from day one — retrofitting abstraction after the fact is expensive.
Disadvantages
- Provider outage = full application outage with no fallback
- Benchmarking against rival providers is a fork-and-rewrite project
- Compliance moves (regional providers, sovereign inference) require invasive rewrites
- Negotiating leverage with your incumbent erodes as switching cost grows