The model you shipped on will be gone in a year

Runway's Gen-4 Aleph — a genuinely impressive video model, the kind that gets launch coverage and conference demos — lived about twelve months as a production API. That's not a scandal; it's the going rate. In generative media, the model your product depends on has a shorter expected lifespan than your product's roadmap, and planning as if otherwise is how teams end up rewriting integrations under deadline instead of by choice.

The churn isn't carelessness — it's the business model

Hosted inference has brutal economics. Every model a provider keeps serving occupies GPU fleet, ops attention, and support surface. The moment a new checkpoint outperforms an old one at the same price point, the old one stops earning its keep: new customers won't choose it, and the hardware it sits on could be serving the model that wins benchmarks this quarter. Deprecation is what a rational provider does with that math. Some give you a year of notice; some give you a blog post; occasionally an alias just starts returning 404s while the billing meter keeps its composure.

The upgrade treadmill runs fast even without full retirement. Model families rev — v1.5 to v2.5 to v3.0 within a couple of years is normal cadence for video models now — and providers steer traffic to the newest revision, letting the older ones quietly degrade in queue priority long before any formal end-of-life.

The pinned-model-id antipattern

Most integrations hard-code the very thing that's guaranteed to change:

• The provider's model id (some-vendor/awesome-model-v2) sits in application code, sometimes in several services, occasionally in a mobile client that needs an app-store release to change.
• The parameter schema — names, ranges, defaults — is that model's dialect, hand-rolled into your request builder.
• Output handling assumes that model's format, resolution behavior, and quirks.

When the deprecation notice arrives, the migration is a code change × every place that knowledge leaked, plus regression testing, plus the discovery that the replacement model's parameters don't map one-to-one. The team does it in a sprint under a countdown, and the postmortem action item — "abstract the model layer" — gets filed for the third time.

"Text-to-image" is a stable interface. Every particular implementation of it is a depreciating asset.

Capabilities are the layer that doesn't churn

What your product actually needs has been stable for years: text-to-image, image-to-video, upscale, dub. The instability is entirely in which model, on which provider, best serves that need this quarter. So put the boundary there:

• Code names the capability. Application code submits text-to-image with normalized inputs and never learns a vendor's model id.
• Config names the candidates. A routing catalog maps each capability to an ordered list of concrete (provider, model) implementations, each with its own input mapping. When a model retires, the migration is a catalog edit — no application deploy, no app-store release.
• The ledger names what actually ran. Routing indirection is only safe when it's auditable. Every job should record which provider and model served it — so "which model made this asset?" stays answerable years after the model is gone, which is precisely when the question gets asked.

There's a bonus: the same indirection that absorbs deprecations also absorbs outages and rate limits. A capability with three live candidates fails over across them mid-job; a capability with one deprecated candidate fails over to its replacement permanently. Same mechanism, two very different bad days survived.

You can't make vendors keep models alive. You can build so that their retirement announcements are somebody else's rewrite — and your config change.