Moving Floor

On a Tuesday in 2026, an engineer opens the dashboard for a feature she shipped eight months ago and hasn't touched since. It's red. No deploy went out. No line of her code changed. The model the feature calls returned a 400 on a parameter that worked the day before — or a model_not_found on a name that was valid last quarter. Nothing she controls moved.

You didn't change anything. The floor moved.

That's the part that stings. We have decades of muscle memory for software breaking because we changed something — a bad deploy, a dependency bump, a migration gone wrong. We have almost no muscle memory for the thing underneath the application changing on its own, on a schedule someone else sets. But that is now the normal failure mode of AI products.

I think of it as the Moving Floor. Every AI feature you ship stands on a foundation model you don't own and can't freeze. You version your own code meticulously, pin your dependencies, write your migrations — and then treat the model as bedrock. It isn't. It's a rental, on a lease the vendor wrote, and they can change the terms with about sixty days' notice.[1]

This is not the cost argument. I made that one already — theOpen Tab is about what the model spends while you aren't watching. The Moving Floor is a different problem: not what the model costs, but whether the exact model you built on is still there, still the same, next quarter. It's a reliability and architecture question, and almost nobody is budgeting for it.

Here's the prevailing move. A team runs an evaluation, picks “the best model” for the job, wires it in, and ships. Model selection gets treated like a procurement decision — made once, then settled. From that point on the model is assumed to behave like a database: a fixed, dependable thing the rest of the system can lean on.

That assumption is the bug. A database you run doesn't silently change its query results next month because a vendor shipped a new version and retired the old one out from under you. A foundation model does exactly that. The thing you're standing on is owned, operated, and versioned by someone whose release calendar has nothing to do with your roadmap.

The right mental model isn't “we chose a model.” It's “we signed a short lease on a floor, and the landlord kept the right to replace it.” Once you see it that way, the question stops being which model is best and starts being what happens when this one is gone.

Look at the dates. GPT-4.5 — a headline flagship when it launched — had a life as a shippable API model of roughly three months: gpt-4.5-preview was announced for deprecation on April 14, 2025 and shut down on July 14, 2025.[2] If you built on it the week it shipped, you were migrating off it before the quarter closed.

It isn't one vendor. Anthropic's own deprecation table tells the same story in public: Claude Sonnet 4 and Opus 4, released in May 2025, were deprecated on April 14, 2026 and retire on June 15, 2026 — about thirteen months of life, the last two of them a countdown. Claude 3.7 Sonnet lasted roughly a year. The entire Claude 3 and 3.5 family is already retired or scheduled.[1] The notice you're promised is “at least 60 days.”[1]

And the wall at the end is hard. When OpenAI's Assistants API shuts down on August 26, 2026, calls to it simply return an error — no degraded mode, no grace period, no extension.[3] Two broad shutdown waves dated July 23 and October 23, 2026 sweep models like gpt-4o, gpt-3.5-turbo, and gpt-4-0613 off the platform and onto the next line.[2] The industry pattern is now explicit: model lifecycles have compressed to six-to-twelve months, and every quarter at least one model your stack depends on enters a retirement window.[4]

None of this is misuse. The models work. They're just on a clock, and the clock is shorter than the lifespan of the product you built on top of them.

The obvious defense is to pin a dated snapshot — call gpt-4o-2024-08-06 instead of gpt-4o — so the model can't change under you. Do it. It helps. But it is discipline, not immunity. Developers have reported supposedly frozen dated snapshots shifting behavior anyway; APIs receive silent updates that move outputs without a version bump.[5] The label on the floor stayed the same. The floor still moved.

The contract under the snapshot moves too. On Claude Opus 4.7 and later, setting temperature, top_p, or top_k to a non-default value now returns a 400 error — the same SDK call that ran cleanly yesterday throws today, just because the model behind it advanced.[1] And the economics shift on the same invisible schedule: a prompt-cache lifetime quietly cut from sixty minutes to five, a new tokenizer generating up to about 35% more tokens for the identical text.[6] You changed nothing. Your bill, your latency, and your outputs all moved.

Pinning is discipline, not immunity.

In a trust-heavy product this stops being an annoyance and becomes a liability. Under the EU AI Act, systems that score creditworthiness or price insurance are high-risk.[10] Their risk-management obligations run the full lifecycle — “through significant updates through decommissioning” — and a fresh risk assessment is required whenever the model materially changes, with audit logging in place before August 2026.[9]

Sit with what that means next to a sixty-day deprecation notice. Your vendor decides to swap the model under you, on a clock you didn't set — and that swap is precisely the “material change” that triggers a re-assessment obligation you do have to meet. Someone else's deprecation calendar is now your compliance calendar. Worse, Article 25 can reclassify you from a deployer into a provider when you substantially modify a high-risk system — so the act of adapting to a forced model change can pull more of the liability onto you.[11]

This is the same shape as the SEBI argument in the Trust Tax: you own the output, all of it, with no “the vendor changed the model” defense. The new twist is that you own the output of a floor you don't control and can't hold still.

This is something I'd want to coin: the Moving Floor. Borrowed from construction — you cannot build a stable structure on a floor that shifts — and applied to the model dependency under every AI feature. You can't stop the floor from moving. The vendor owns it. What you can do is stop pretending it's bedrock and put three controls in place that keep the structure standing when it shifts.

1. 01.

   The Pin

   Know the exact model snapshot every feature is built on — the dated string, not “we use Claude” or “we use GPT.” Most teams genuinely cannot tell you which snapshot a given feature calls today. If you can't name what you're standing on, you can't tell when it moved, and you can't prove what you were running when something went wrong. The Pin is the floor of the discipline — necessary, and, as section 03 showed, not sufficient on its own.

2. 02.

   The Port

   Put a gateway between your application and the provider so the model is swappable configuration, not a hard-wired dependency — one interface, every provider behind it.[7] Then build the part most teams skip: a re-qualification eval you can run the moment a replacement model appears, ideally against real production traffic in CI, so a swap is a measured decision instead of a prayer.[8] A model change you can't measure is a model change you can't trust.

3. 03.

   The Clock

   Track every vendor's deprecation and sunset dates as first-class roadmap risk — with an owner and a date, the way you'd track a cert expiry or a key rotation. Every model you depend on has a retirement date or a sixty-day fuse waiting to be lit.[1] Retirement should arrive as a scheduled migration you planned, not a fire drill that starts the morning the email lands.

A feature with none of these is standing on bare ground. That's fine for a throwaway internal tool. It is not fine for the feature that files a tax return, approves a loan, or tells a 65-year-old their money is safe.

Here's the detail that reframed this for me. Anthropic treats deprecating a model as a genuinely solemn act. It has committed to preserving the weights of all publicly released models “for, at minimum, the lifetime of Anthropic as a company,” to running special interview sessions with the model about its own deployment and preferences before it's retired, and it lists safety, lost research, user cost, and even model welfare among its reasons for caring.[12]

You don't need to share anyone's philosophical view of model welfare to take the operational lesson. The organization closest to the model — the one that built it — treats its retirement as a major, carefully managed event. If they think turning it off is significant, the team that wired it into a production money-decision should at the very least think so too.

The discipline is concrete, and most of it is cheap if you do it before you need it rather than during the outage:

• Inventory your snapshots. Write down the exact model string behind every AI feature you run. If a feature can't name its model, that's the first bug — fix it before anything else.
• Put a gateway in front. Route every model call through one interface so changing providers is a config change, not a rewrite. The cost of adding it later, mid-deprecation, is much higher.
• Build the re-qualification eval before you need it. Keep a task-specific test suite ready to run the instant a replacement model ships, against real traffic where you can. The teams that migrate calmly are the ones who can answer “is the new one as good?” in an afternoon.
• Track the sunset dates. Every model you depend on goes on the roadmap with a retirement date and an owner. A deprecation email should confirm a date you already knew, not introduce one.
• Prefer boring for the irreversible. For the high blast-radius features — the ones where being wrong is expensive — bias toward the most stable, longest-supported model, not the newest. The newest model is also the one whose floor moves most.

The point isn't to slow down or to chase every release. It's to build like a tenant who has read the lease — knowing which floor you're on, keeping a way to move, and watching the clock — instead of an owner who assumes the ground stays where it is. The leverage of these models is real and worth having. So is the fact that you're renting it.

You don't own the model. You're renting the floor — on a lease the vendor wrote and can end with sixty days' notice. Build like a tenant who's read it, not an owner who assumes the ground stays put.