The Model Is Not a Constant: What Changes Under Your AI Application After You Ship

Ask an engineering team what version of PostgreSQL they run and you get a precise answer, plus an upgrade plan. Ask the same team which model version is in their AI feature and you often get a product name. That gap is where the next incident lives.

Every model has an expiry date, and you do not set it

Start with the fact that reframes everything else: the model behind your feature will be switched off, on a date chosen by somebody else, and after that date your requests fail.

This is documented policy, not speculation. Anthropic describes a four-state lifecycle — active, legacy, deprecated, retired — and states plainly that requests to models past the retirement date will fail, with at least 60 days’ notice for publicly released models.¹ Amazon Bedrock uses three states — Active, Legacy, and end-of-life — where the legacy period is the notice period, published per model as either six months or 45 days, and after EOL the model is removed from all Regions and requests fail.² OpenAI commits to at least six months for generally available models, at least three for specialized variants, and warns that preview models may be retired with much shorter notice, such as two weeks.³

Observed intervals are tighter than the headline numbers suggest. Anthropic’s published deprecation history shows Claude Opus 4.1 announced for retirement on June 5, 2026 and retired on August 5, 2026 — a 61-day window from announcement to failure.¹ That is the policy working exactly as written. It is also less time than many organizations need to get a change through review, regression, and a release train.

Where you call it from decides when it dies

Here is the gotcha that abstraction layers hide most effectively. The same model, with the same capabilities, carries different lifecycle dates depending on which platform you reach it through.

Anthropic states that its published dates apply to Anthropic-operated platforms, and that partner-operated platforms such as Amazon Bedrock and Google Cloud set their own retirement schedules, so a model’s lifecycle status and dates can differ.¹ AWS says the same thing from the other side: model lifecycle dates are specific to Amazon Bedrock and may differ from dates published by model providers, and for Bedrock usage only the dates on the model card apply.²

Model identifiers diverge along the same seam. As of September 2026 the same model is addressed with a bare identifier on one platform, a vendor-prefixed identifier on a cloud marketplace, and a suffixed form on another cloud, with routing options — global endpoints with dynamic routing, regional endpoints with guaranteed data routing — that differ per platform.⁴ For a regulated workload, that routing distinction is a data-residency decision wearing the costume of a configuration flag.

One Bedrock rule deserves separate attention because it breaks a specific and common pattern: once a model enters the legacy state, new customers cannot adopt it and existing customers may lose access after 15 days of inactivity.² A quarterly reporting job, a seasonal campaign model, a disaster-recovery path exercised twice a year — each of these can find its model gone well before the published EOL date, because the qualifying event is your inactivity, not the calendar.

Pinned or floating, and the convention moved under both

There are two ways to reference a model and no third. A floating alias resolves to whatever the provider currently points it at, which means your application’s behavior can change without a deployment. A pinned identifier gives you a fixed artifact, which means you inherit its retirement date and must schedule a migration. Teams often believe they have chosen the safe option. Both options carry a cost; only one of them tells you when.

The convention itself is not stable, which is the part that catches experienced teams. As of September 2026, in one current lineup, older generations used an alias that resolved to a dated snapshot, while from a later generation onward the dateless identifiers are their own pinned snapshots rather than pointers.⁴ An identifier with no date in it therefore means the opposite thing depending on which generation it belongs to. Code that inspects a model string to decide whether it is pinned will draw the wrong conclusion across a generation boundary.

Models are not the only thing that gets retired

Version risk is usually framed as whole-model replacement. The subtler version is that the shape of a valid request changes underneath you while the model name stays familiar.

A concrete instance, as of September 2026: on one current family, the sampling parameters temperature, top_p, and top_k are deprecated from a specific generation onward, and returning a 400 error when set to a non-default value on those models — with the provider’s Python SDK removing them outright from its request types, so passing them raises a TypeError rather than reaching the API at all.¹ The documented replacement is not another parameter. It is prompting.

Sit with what that does to a codebase. A wrapper function written two years ago that helpfully sets temperature=0 on every call — because that is what the tutorials said — does not degrade gracefully on the new model. It raises. The same pattern applies to controls for extended reasoning, where a mode available on one generation is deprecated on the next and not accepted on later ones.⁴

What reproducibility can actually mean

The parameter deprecation above removes a crutch that was never load-bearing to begin with, which makes this a good moment to be precise about determinism.

Setting a temperature of zero requests greedy decoding. It does not promise bitwise reproducibility, because identical output also depends on batching, hardware, kernel and library versions, and routing decisions inside the serving stack — none of which are part of your request. Teams that discovered this the hard way usually did so through a test suite that asserted on exact strings and failed intermittently for reasons nobody could reproduce locally.

The workable definition is behavioral rather than literal. A system is reproducible when the same input produces an output that passes the same assertions: the schema validates, the extracted fields match, the classification lands in the right bucket, the refusal happens when it should. That is a property you can actually test across model versions, and it is the property that matters to a downstream consumer. Chasing identical bytes optimizes for something no provider offers and no user needs.

Same window, different document

Context windows are quoted as a single number, which makes them look like a stable property you can plan against. Two things complicate that.

The first is that the tokenizer can change between generations. In one current lineup, a tokenizer introduced at a specific generation means roughly 555,000 words fit in a million tokens, where models before it fit about 750,000 words in the same nominal window.⁴ The window number did not move. The amount of your content that fits inside it moved by a wide margin.

Follow that through. A retrieval system tuned to pack a fixed number of documents into the context can overflow on a newer model with an identical advertised window. A cost model built on tokens-per-document is wrong by a similar margin in the same direction. Neither failure announces itself as a tokenizer change; they present as truncation and as an unexplained bill.

The second complication is that occupying a window is not the same as using it well. Retrieval quality and instruction adherence degrade as context grows long before the hard limit is reached, which is why the practical question is never how much fits. It is how much helps — and that is a property of your content and your task, measurable only against your own evaluation set. This is the same argument as resolving meaning before querying: a larger window is not a substitute for a layer that decides what the model should be looking at.⁵

Output is the budget

Token pricing is asymmetric in a way that reshapes design decisions once you notice it. Across one current lineup as of September 2026, output tokens are priced at five times input tokens at every tier — $10 against $50 per million on the largest model, $2 against $10 in the middle, $1 against $5 at the fastest tier.⁴

That ratio means the expensive decisions are the ones that make the model write more. “Explain your reasoning” is a budget line. So is a verbose output schema, a chatty system prompt that encourages preamble, and any retry strategy that regenerates a long answer to fix a short defect. Meanwhile the instinct most teams have — trim the context to save money — attacks the cheaper side of the ledger.

Caching is real money and a prompt-shape dependency

Prompt caching is the most effective cost lever available to a high-volume application, and the most fragile. It rewards a property of your prompt that no type system checks and no test asserts: byte-stability of a prefix.

The mechanics reward precision. Caching works on prompt prefixes: the system hashes the prompt up to a marked breakpoint, and a hit requires a completely identical segment. Cache writes happen only at your breakpoint, and the lookup walks backward a limited number of blocks looking for an earlier match.⁶ The documented common mistake is the one most teams make first — placing the breakpoint after a block containing a timestamp or the user’s message, which produces a different hash on every request and therefore never hits.

Invalidation is hierarchical, and the top of the hierarchy is easy to disturb. Changing tool definitions invalidates the entire cache, including system and message segments.⁶ Adding one tool to an agent — a routine, apparently additive change — resets caching for every request until the new prefix warms.

Now the part that belongs in an article about model change. Minimum cacheable prompt length varies by model — as of September 2026, across one lineup it ranges from 512 tokens on some models to 4,096 on others — and prompts shorter than the minimum are processed without caching, with no error returned.⁶

That is a silent cost regression triggered by a model swap. A team migrates ahead of a retirement date, the evaluation suite passes because output quality is fine, and the bill rises sharply the following month because a prompt that comfortably cleared the old model’s minimum falls under the new one’s. Nothing failed. Nothing logged. The economics simply changed.

Cache writes also cost more than ordinary input — commonly 1.25 times the base rate for a short time-to-live and around twice for an extended one, against reads at roughly a tenth⁶ — so a cache with a poor hit rate is worse than no cache at all. Hit rate belongs on a dashboard, not in an assumption.

Customization inherits the expiry

Fine-tuning is where lifecycle risk compounds, because the investment is larger and the constraint arrives earlier than teams expect.

A fine-tuned model is a derivative of a base model that has its own clock. On Amazon Bedrock, once a foundation model enters the legacy state you cannot create new fine-tuning jobs on it and cannot create new Provisioned Throughput endpoints, although existing deployments created beforehand continue to work.² Read that as a capability freeze that lands at the start of the notice period, not the end. From that moment your customized model cannot be retrained on new data, and you cannot scale it onto new dedicated capacity.

The strategic consequence is worth stating directly: choosing fine-tuning binds your differentiated asset to a base model that will be retired, and re-creating it on a successor is a project — new training run, new evaluation, new tuning of everything downstream that had adapted to the old behavior. That can absolutely be the right call. It should be a decision made with the expiry date visible, alongside the alternatives of retrieval, prompting, and routing, which port across model changes far more cheaply.

The suite that turns a swap into a decision

Everything above converges on one capability. If you can answer “is this new model better or worse for our task?” in an afternoon with evidence, every item in this article becomes scheduled work. If you cannot, each one becomes an incident, and the organization learns to avoid upgrades — which guarantees that the eventual migration happens under a deadline set by someone else.

The evaluation set is the asset, not the harness around it. It needs enough examples drawn from real traffic to be representative, expected outputs specified as assertions rather than reference strings, layered grading that separates retrieval failures from reasoning failures, and weighting by the consequence of being wrong rather than by how often a case appears.⁷

Planning an adoption that assumes movement

Most AI adoption plans are written as though the hard part is getting to production. The pattern we see is that reaching production is achievable for a competent team, and the difficulty lands afterward, in the operating model that nobody designed because the plan ended at launch.⁸

A plan that assumes movement looks different in a few specific ways. It names an owner for the model inventory — which models, which platforms, which identifiers, which retirement dates — and reviews it on a cadence rather than on receipt of an email. It treats the evaluation set as a deliverable of the first use case rather than an artifact of the third. It funds a migration allowance each year, because at current cadence a production model will need replacing roughly annually. And it establishes an abstraction boundary early: not a heavyweight framework, but one internal interface where the model identifier, the platform, and the request shape are resolved, so a provider change is a configuration change in one place.

None of this is exotic. It is the same discipline any organization already applies to operating system versions, TLS certificates, and database major releases — dependencies that also expire on somebody else’s schedule and whose expiry is nonetheless a routine calendar item rather than a crisis. The only thing new is that the dependency in question produces prose, which makes it feel less like infrastructure than it is.

What to take from this

Language models are worth adopting, and the constraints in this article are not arguments against adoption. They are arguments against a specific and very common assumption: that the model is the stable part of the system and the work around it is the variable part. It is the other way around.

The retrieval layer you build, the evaluation set you accumulate, the semantic definitions you resolve, the routing logic that matches consequence to capability — those are durable. They survive provider changes and outlast individual model generations. The model itself is the component with the shortest supported lifetime in your entire stack, and it is usually the one teams document least.