Your model is a vendor, not infrastructure

There's a quiet assumption baked into most AI products: that the model is infrastructure — like electricity or DNS, a thing that's simply always there. You wire your product straight into one provider's best model and move on, because why would it ever go away?

Here's why. It's not infrastructure. It's a vendor — one with a shrinking shelf life and a kill switch you don't hold.

The shelf life is getting shorter, not longer

Model support windows have compressed from the 18–24 months you used to get down to roughly 6–12 months. OpenAI ran multiple deprecation waves in 2026; GPT-4o was retired, the Assistants API removed, and whole classes of integration had to be rewritten on the vendor's schedule, not yours. The thing you built on is a moving target that moves whether or not you're ready.

And it can move for reasons that have nothing to do with you. Claude Fable 5 launched in June 2026 and, days later, access was reportedly suspended worldwide under a US export-control directive. Imagine that's the model your product depends on. No bug on your side, no warning you could act on — the supplier just vanished, by government order.

If a single company's roadmap — or a government's export policy — can take your product down overnight, you didn't build a product. You built a dependency with a login page.

Why "just use the best model" is a business risk

Hard-coding one provider's flagship feels like a quality decision. It's actually a continuity bet: you're wagering that this specific model, at this specific endpoint, stays available and stable for as long as your business needs it. Every deprecation, price change, region block, and policy shift is now your emergency. The model was never your moat — and it's definitely not your foundation.

Portability is the cheap insurance nobody buys

The fix is boring and it's the same discipline I keep landing on:

• Put the model behind an adapter. Your product talks to your interface; the provider sits behind it. Swapping models is a config change, not a rewrite. This is exactly what a router like OpenRouter buys you at the infra layer.
• Stay evaluated across two providers, not one. Keep a second model warm and tested on your real tasks, so "our provider went dark" is a switch you flip, not a project you start.
• Own the parts that are actually yours. Your prompts, your grounding data, your evals, your glue — those are portable assets. Keep the model as the replaceable part, because it is one.
• Read the deprecation policy before you build, not after. Support window, notice period, and region terms are product decisions. Treat them like you'd treat any critical supplier's contract.

None of this is over-engineering. It's what you do for any dependency that can disappear — and this one can change owners or vanish overnight.

The bottom line

The frontier model feels like a utility because it's convenient to pretend it is. But utilities don't get export-controlled, retired on a vendor's calendar, or repriced at will. Yours can.

Treat the model as a vendor you can fire — put it behind an adapter, keep a second one tested, and own everything around it. The provider's bad day shouldn't be your outage.