The recurring cost of production AI is not inference. It is re-qualification: the eval reruns, prompt retuning, and regression testing you owe every time a model changes under you. The email arrived on a Tuesday.

A model we had been running in production for the better part of a year, pinned to a specific version on purpose, was being deprecated. We had a window to migrate. After that, the endpoint would start returning errors.

We had done everything the careful-engineering playbook tells you to do. We did not float on a latest alias that could change under us overnight. We pinned the exact model version, wrote it into config, and treated it like any other dependency we did not want moving without a review.

The pin was supposed to be the safe choice. The deprecation notice made something clear that the pin had been quietly hiding: pinning a model version does not buy you immunity from change. It buys you a delay.

The ground still moves. You just get to choose the Tuesday. That distinction is the most under-budgeted cost in production AI.

Teams model their AI spend as inference: tokens in, tokens out, times price. They optimize the model choice, they optimize the prompt length, they argue about whether the cheaper model is good enough. Almost nobody has a line in the budget for the day the model changes and the whole system has to be proven correct again.

I am going to call that line the re-qualification tax, and by the end of this piece I want you to have both a name for it and a way to plan around it. What pinning actually protects you from, and what it does not Pinning a model version is genuinely good practice. It stops silent behavior drift, where a provider updates the weights behind an alias and your outputs shift without a single line of your code changing.

If you have ever watched an eval score move for no reason you could find in your own commits, you already know why teams pin. But a pin is a lock on your side of a door the provider also controls. Providers deprecate.

In 2026 the cadence has if anything accelerated: new frontier models ship every few months, older ones get sunset, and several providers have retired models on short notice. Most teams are not running one model anyway. The current reality, borne out in engineering surveys through the year, is that production stacks keep several models in flight at once: a frontier model for hard reasoning, a cheaper model for routine calls, sometimes a self-hosted model for data that cannot leave the building.

Every one of those is on its own deprecation clock. So the pin does not remove the change. It converts an unpredictable change into a scheduled one.

That is a real improvement, because a scheduled change is something you can staff and budget for. It is only a disaster when you treated the pin as permanence and put nothing in the plan for the day it expires. The thing everyone forgets to price: the model is not the only thing that changes Here is the part that makes re-qualification expensive rather than trivial.

When you move from one model version to the next, the model is not a drop-in part. Almost everything you built on top of the old model was, whether you meant it to be or not, tuned to that model's specific behavior. Your prompts were tuned to it.

The phrasing that reliably produced structured output on the old model may produce something subtly different on the new one. Your few-shot examples were calibrated to its quirks. Your guardrails were set against its failure modes.

Your output parsers were hardened against the specific shapes it tended to return. Your temperature and y...