What do you do the day you open your project, and the model it runs on is just gone?

I built the first version of my portfolio chatbot around a free embedding model on Hugging Face. It was an early Mistral model that did a good job turning my portfolio text into vectors I could search.

I wired it into a small RAG backend (so it searched my stored data before answering instead of relying only on what the model knows), stored the embeddings, and got the thing working well enough that I started thinking about deployment.

Then during one of the final QA runs, I got an error 😓

The model had been pulled from the hub without a warning or replacement. It was just gone, and I’d lost more than a dependency.

The embeddings I’d already built were tied to that specific model’s coordinate space. Swapping in a different model (Gemini, thanks in large part to its generous free tiers) meant every vector I’d already generated was unreadable since two different models don’t necessarily share the same semantic space.

I basically had to regenerate the whole set from scratch, a week before I was trying to deploy. I hadn’t even considered this part or its possibility.

I’d written my code as if the model were a fixed thing, a stable function I could call indefinitely, the way I’d treat any library dependency. You pin the version and assume it stays put.

What I actually had was a lease, and I’d never read the terms.

The Skill That Used to Work, and Doesn’t Anymore

That feeling of working and relying on a leased tool from an unreliable source didn’t stay in the past. I still watch a quieter version of this playing out in my day-to-day across different workflows.

For example, I write for THT using a set of skills files, essentially explicit instructions spread across three or four documents that tell a model exactly how to revise a draft, things like:

• which words are banned
• how sections are structured
• which voice patterns to check for before a draft is done (let’s be honest, I get sarcastic far too much 😬)

I built it because I got tired of re-explaining the same rules every time. A workflow file lets me set it up once, point a model at it, and let it run the checks.

When I first set up the skill, the model running it did exactly what I asked. Mind you, not perfectly, but reliably enough that I trusted it to run the pass.

I can’t say the same thing when running the same setup with the newer models. I’ve noticed the checks aren’t applied the same way. Instructions that were followed through explicitly (run this check, confirm this pattern is gone, verify that structure matches) now get skimmed or partially applied.

Same files and instructions, however, different level of application.

At least the model admits its mistake each time when I push back. But it’s terribly frustrating to watch a setup that used to work reliably start missing things it used to catch.

If I had to put a name on it, it feels like regression. A newer model is doing worse at a task an older one in the same family handled fine. Though I don’t know what changed upstream to cause it, I know what changed on my end: nothing.

I share this story because what used to be a personal annoyance (i.e., me noticing drift in a workflow) is now baked into production systems everywhere.

Note ⚠️
Companies are handing entire workflows to models, sometimes fully automated, no human checking the output before it moves to the next step. Yet, underneath all of that sits a model the provider can change on their own schedule, for reasons that have nothing to do with whether it breaks your pipeline. Think about this really carefullly.

Why This Isn’t the Same Problem as Depending on Microsoft Word

Now, if I were reading this instead of writing it, I’d wonder: Isn’t this like every other dependency out there?

Microsoft changes Word whenever it wants. Ships new versions, retires old ones, moves features around without asking.

Every business running Word or Excel depends on a vendor it doesn’t control too.

So what actually makes an AI model different from any other piece of rented software?

Why Your File Survives When the Model Doesn’t

When Microsoft changes Word, the .docx file you wrote five years ago still opens in Word, Google Docs, or half a dozen other programs. The format is documented and portable, and it outlives any single version of the software that made it.

When a model provider changes a model, there’s no equivalent file sitting on your machine.

You had a live connection to the model, not a copy of it. When that connection changes, there’s nothing local to fall back on.

Why AI Models Aren’t Like Excel Formulas

Excel’s SUM function returns the same total for the same numbers today and next year, whether Microsoft ships a new build or not. That’s the entire contract a spreadsheet formula makes with you (otherwise known as “determinism”).

An AI model makes no such promise 🙅‍♀️

Ask it to run the same set of checks against the same instructions, and it might follow through on some of them and quietly skip others tomorrow, under the exact same model version.

Why? Solely because something shifted in a backend router, a safety layer, or an internal weighting you’ll never see in a changelog.

So it’s not that AI is the only rented dependency a developer has. It’s that:

• Word rents you a tool with a fixed, testable contract
• An AI model rents you a probability distribution the provider can nudge at will (often for reasons that have nothing to do with whether your workflow still parses what comes back)

Tip 📍
For workflows that depend on a model’s output following a specific structure, treat that structure as unstable by default. Validate the response before you trust it, the same way you’d validate any input you didn’t generate yourself.

1. Pinning an AI Model Version Freezes the Weights, Not the Behavior

For my devs, don’t think of pinning a hosted model the same as pinning a package because it doesn’t work the same way.

While pinning a package freezes behavior, for a model you freeze the weights, not the parameters the API accepts, which can still move under the same unchanged model ID.

For instance, Claude Opus 4.7 and later reject temperature, top_p, and top_k outright, returning a 400 error the moment any of them are set to a non-default value.

While the SDK still type-checks the request and it ships fine, the first failure shows up in production because the request types still define those fields “for compatibility with earlier models,” so your code compiles cleanly while the API rejects it server-side.

await anthropic.messages.create({
  model: "claude-opus-4-7",
  temperature: 0.2,   // rejected, 400 on Opus 4.7+
  top_p: 1,           // rejected, 400 on Opus 4.7+
  messages: [{ role: "user", content: prompt }]
});

The model string is the one line you meant to change, and everything else that breaks is code you never touched.

None of it shows up in CI, because the SDK still type-checks the old fields as valid, so the first failure you see is a 400 in your production logs.

Note 👇
Pinning a model string in production doesn’t mean the parameters around it are safe to leave alone. Check the current migration notes for that specific model line before you ship, not after a 400 shows up in your logs.

2. AI Model Deprecation Notices Run on the Provider’s Clock, Not Yours

To be fair, none of these changes happen without warning. Every major provider runs a formal deprecation schedule with a hard cutoff, not a silent auto-upgrade.

• Anthropic commits to at least 60 days’ notice before retiring a publicly released model.
• OpenAI’s policy runs longer for generally available models: six months minimum, three months for specialized variants, and as little as two weeks for anything marked preview.
• Google plays it differently by publishing earliest-possible shutdown dates and only confirming the real one as it gets close, so you plan against a target that doesn’t resolve into a fixed date until you’re already near it.

Sixty days sounds generous until you remember it’s a floor, not a negotiation.

A lesson from this is to build a migration runbook against the floor a provider states, not the hope of extra time.

That said, sixty days is still more warning than my embeddings model gave me. That one just vanished.

But even when you do get warned, the tool you built on has an expiration date you didn’t set, on a clock someone else is holding.

3. Sometimes AI Model Access Gets Cut Off by Outside Forces, Not the Provider’s Roadmap

The deprecation clock is at least predictable. What’s harder to plan around is access getting pulled for reasons that have nothing to do with the model, your code, or anything you did.

Take this week as an example. I woke up to an email notification from OpenAI announcing it told SpaceX that it’s winding down Cursor’s direct access to OpenAI models, with a shutoff date of November 12, 2026, after SpaceX closed its $60 billion acquisition of the coding tool.

The reasoning wasn’t about model quality or misuse inside Cursor itself.

OpenAI pointed to Elon Musk’s past contract disputes at other companies he controls and said its next model, Astra, won’t be supplied to Cursor at all.

If you’d built a workflow around Cursor’s OpenAI-backed features, none of that was your call, and none of it was about anything you built.

And this isn’t a one-off case, as access wars are rampant. Anthropic cut off Windsurf’s access to Claude in 2025 over acquisition talk with OpenAI, and OpenAI’s own API access to Claude got revoked months later over a benchmarking dispute 😬

Access between AI companies changes over corporate relationships in a way library maintainers mostly don’t operate. And sometimes it’s not corporate at all.

When Global Rules Affect Your AI Build

Anthropic released two new models, Fable and Mythos, on June 9, 2026. Three days later, it suspended access to both to comply with U.S. Department of Commerce export controls.

Model suspension here had nothing to do with how the models performed or who was using them. It was a regulatory requirement enforced after the models were live.

The controls were lifted on June 30, and Anthropic restored access on July 1. That’s a three-week gap where anyone building on those models simply couldn’t reach them, for reasons entirely outside Anthropic’s product decisions.

None of these are the routine “we’re freeing up capacity for a new release” kind of change. They’re a reminder that the thing sitting between you and the model is a company with competitors, regulators, and business relationships that can change your access for reasons that never touch your code.

4. Running AI Models Locally Trades One Kind of Instability for Another

But what if you go local? If you run your own weights and control your own updates, there’s no provider quietly changing anything under you. Doesn’t that solve the whole thing?

Once you’ve pulled a model with a tool like Ollama, the weights sitting on your machine don’t change on their own. There’s nothing that auto-updates them, and running the same pulled model tomorrow uses the same file it used today.

Explore: I Tried the ‘Code for Free with Local AI’ Setup. Here’s What Actually Happened.

Well, the “problem”, if we call it that, is the tag itself.

Model tags are more like pointers than version numbers, and if a model’s maintainer pushes an updated build, the same tag now refers to something different the next time you or anyone else pulls it.

Re-run the exact command you ran three months ago, and you can end up with different weights under an identical-looking name. And the tag isn’t the only moving part.

An Ollama issue saw a runtime engine update alone cause inference speed to collapse tenfold on unchanged model weights, just from how the new engine handled memory and caching.

So local buys you a copy of the weights, but doesn’t buy you a stable place to keep running them because the tag pointing at those weights and the engine running them can both move without your files changing at all.

Let’s also not forget about the hardware gap. A legitimate local inference setup in 2026 looks like a MacBook Pro with 64GB of unified memory or a Mac Studio with 128GB, just to comfortably run something that competes with a Frontier cloud model.

That’s not a casual purchase for most developers, myself included.

Related: Why OpenClaw And Hermes AI Agents Aren’t Actually Free

None of This Makes the Tools Less Worth Using

The AI coding tools I lean on daily changed what I can build alone, and the RAG project that started my deeper dive into RAG and customization wouldn’t exist without a free embeddings model I couldn’t control 🙌

That’s what makes everything frustrating instead of simple.

If these were bad tools, walking away would be easy. But they’re good tools that are extremely unstable, and I don’t think we consider that instability enough outside the “should we use AI” argument, which is a different question altogether.

Most of what I read treats a model update as pure upside and skips over what it costs the person holding a project built on the version that just changed underneath it. It’s great news for the AI enthusiast on YouTube but a headache (with potential for nightmare status) for those running systems 😑

I also don’t blame any single provider for this because deprecating an old model to push people toward a better one is a reasonable call.

Related: Why LinkedIn’s New AI Job Search Has Users Fuming

Even the Cursor and export-control examples above are companies acting within their rights, not doing anything shady.

What bothers me is the framing that model updates are purely progress, with no cost on the other end of the API call, and no acknowledgment that access itself can move for reasons that have nothing to do with the product.

Hey! We’re basically integrating and automating on a dependency that can disappear overnight for whatever reason without any stable or portable format that’s deterministic. I guess in a way this should already have been a red flag when everyone focused on prompt engineering, that they had to tweak and differentiate the style and structure of the prompts for different models 🙂‍↕️

It’s a Wrap

This was never really about whether models change. Of course they do; so does every piece of software.

Instead, it’s that handing a workflow to a model means depending on something whose weights, parameters, and access can all move independently of each other, on a schedule you don’t set, sometimes for reasons that have nothing to do with your code at all.

At that point, your response, my response, our response is all reactionary.

Word doesn’t do that, and neither does a typical library dependency. A model does it constantly, and that’s the actual difference.

I’d argue the “solution” isn’t to stop building on these tools. In fact, I don’t know if there is necessarily a “solution.” I definitely treat “the model works today” as a much shorter-lived fact than most of us currently do.

Build the parts around it (validation, fallbacks, the willingness to regenerate something from scratch) like the model itself might not be there tomorrow in the shape you left it today.

Maybe also reconsider the processes and workflows that are getting handed to AI for automation or that are largely dependent now on an AI workflow.

We all need to (a) know the risk exists and (b) actually build for it. Knowing of the risk and building for it are two different habits.

Start by asking yourself: if the model you depended on vanished, just like my Mistral model did, or it got cut off for reasons that had nothing to do with you, what would you do?

Are any of the products, processes, or daily habits you’re now depending on going to be affected?

If your answer is yes, it’s time to put the thinking hat on.

Think about it and be smart.

‘Till next time, friends.