The short answer
Model providers deprecate versions, change behaviour and adjust limits, usually with notice that is shorter than the work involved.
Building so those events are routine costs little at the start and a great deal to retrofit under time pressure.
What actually changes
| Change | Effect |
|---|---|
| Version deprecated | Forced migration on their timeline |
| Behaviour changes on same version | Quality shifts with no deploy |
| Rate limits adjusted | Capacity changes without warning |
| Pricing changes | Economics shift |
| Terms change | May affect what you promised buyers |
The second row is the one that catches teams out. Output changing when nothing on your side changed is only detectable with continuous evaluation.
Build for portability
- Keep provider calls behind your own interface.
- Pin an explicit version rather than an alias that moves.
- Keep prompts and configuration separate from code.
- Maintain an evaluation set that can run against any provider.
- Try a second provider once, so you know what it involves.
Point five is the valuable one. Knowing roughly how much work switching is turns an emergency into a decision.
Do not over-abstract
A thin interface that isolates provider calls is worth having. A large abstraction layer covering several providers generically costs more than it saves and usually leaks anyway.
The goal is knowing where the provider is touched, not making providers interchangeable without effort.
Watch for notices
- Someone subscribed to provider announcements
- A known deprecation date for every model you use
- Evaluation running continuously to catch silent changes
- Budget alerts for pricing changes
- A review whenever terms change
Continuous evaluation is what catches the changes nobody announced, which are more common than deprecations and considerably harder to notice.