# Your model is a vendor, not infrastructure

Founders treat the frontier model like electricity — a utility that will always be in the wall. It isn't. It's a vendor with a shrinking lifecycle and a kill switch you don't control, and in 2026 we watched a top model get pulled worldwide days after launch for reasons that had nothing to do with anyone building on it. Model portability isn't over-engineering. It's the minimum posture for a business that runs on an API it doesn't own.

- **Author:** Fedor Chishchin
- **Published:** 2026-07-01
- **Tags:** business, architecture
- **Source:** https://fedorthinks.com/blog/your-model-is-a-vendor

---

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](https://presenc.ai/research/ai-model-deprecation-tracker-2026). OpenAI ran multiple
deprecation waves in 2026; [GPT-4o was retired, the Assistants API removed](https://developers.openai.com/api/docs/deprecations),
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](https://www.mindstudio.ai/blog/ai-model-export-controls-claude-fable-5-shutdown)
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](/blog/the-model-was-never-the-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](/blog/the-tool-you-build-on-got-bought).

## 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.**