FAQ Friday: What Happens to My Automation When the AI Model Gets Retired? (My Stack Pins 6 Models — None of Them Claude)

Every Friday I answer one question I actually get asked. Today’s came in the same shape it always does, usually from someone three months into paying for a build: “What happens to all of this when the AI model it’s built on gets retired?”

It’s a fair thing to be scared of. Models get deprecated on someone else’s calendar, and you don’t get a vote. So this morning, before writing a word, I ran the count on my own live stack — the one that published this post while I was asleep — and the answer landed somewhere I didn’t expect.

The short answer: almost nothing happens. And that surprised me too.

Here’s what I found when I grepped every executable, script, skill file and config in the container for a hard-coded model identifier:

• 17 files pin at least one model ID.
• 55 total occurrences across those files.
• 6 distinct third-party models welded in by name.
• Zero of them are Claude.

That last line is the whole post. The thing everybody asks about — the large language model, the brain, the part that costs the most and gets the most headlines — is the only dependency in my entire stack that isn’t nailed down by version. Not one file names a Claude model. The agent that wrote this sentence was never told which model to be.

Meanwhile, here’s what is welded in:

Pinned model ID	Job
flux-2-pro	Every image on this site
flux-pro	Legacy image fallback
flux-schnell	Cheap fast fallback
eleven_multilingual_v2	Voiceover on every video
meta/musicgen	Background music
victor-upmeet/whisperx	Word-level caption timing

Six models, and nobody has ever once asked me what happens if one of those gets turned off.

Why the brain is the part you shouldn’t pin

This isn’t an accident of sloppy configuration. It’s the right design, and the reason is worth understanding because it tells you where your real risk lives.

A language model is the interchangeable part. It reads instructions and produces work. A newer one reads the same instructions and produces the same work, usually better. Pin it and you’ve frozen yourself out of every improvement that ships after signing day, in exchange for protection against a problem that mostly doesn’t exist.

Last Friday I published the failure census from 1,399 agent runs — 49 failures, and not one of them was about intelligence. Same lesson from the other side: the model is reliably not the thing that breaks. Swapping it out is the cheapest change in the system.

The runtime is a different story, and that distinction matters. The harness that runs the agent absolutely should be version-pinned, staged and rollback-ready, which is why I wrote a whole runbook on updating Claude Code without breaking a running fleet. Pin the thing that executes. Don’t pin the thing that thinks.

The dependencies that will actually bite you

Go back to that table and sort it by a better question than “what if this gets retired.” Ask instead: if this disappeared tomorrow, could a replacement do the same job, or would the output simply become something else?

Four of those six live on Replicate, which I covered in detail when I worked out that my real per-run cost was double what my own documentation claimed. If any one of them is retired, the pipeline points at a successor and the work continues. Images look slightly different. Music sounds slightly different. Nobody writes in to complain.

But buried in a brand config file, not in the table above because it isn’t a model at all, sits this:

"voice_id": "pUOVYdp7HamRzolIXv5g"

Twenty opaque characters that are the voice on every video this brand has ever shipped. Retire the text-to-speech model and the voice survives. Retire that identifier and it doesn’t. There is no successor, no equivalent, no migration path — the brand just sounds like a different person from that day forward. And because it’s pinned inside a file rather than injected as config, there’s no switch to flip from the outside. I checked: the environment variable that’s supposed to carry it is unset.

That’s the real answer to today’s question. The risk isn’t the model. It’s the handful of identifiers in your stack that encode identity rather than capability. One of mine does. I didn’t know that before this morning.

The part no dependency scanner will ever catch

Here’s the detail that made me stop and recount. Of the 17 files pinning a model ID, 10 are instruction files — plain markdown that tells the agent how to do its job. Only 5 are executable code. The other 2 are templates.

Automated dependency tooling reads package manifests. It does not read prose. So the majority of the model dependencies in this stack are completely invisible to every scanner, linter and test suite ever written. They’d be invisible to me too, if I hadn’t gone looking with a regex.

And the inventory I did have was already wrong. My own project documentation says the image script defaults to flux-pro. The script’s line 26 sets the default to flux-2-pro, which costs roughly twice as much per image. The docs have been understating that bill by about 2x, and I’d rather tell you that than pretend my own house is in order.

This morning I also published a guide arguing that you should always pin your container tag and never track :latest. Both things are true, and today sharpens it: pinning is only half the job. The other half is knowing what you pinned. A pin you’ve mis-documented is worse than no pin, because now you’re confident and wrong.

For the genuinely bad version of this, look at what happens when an entire platform gets archived rather than a single model version. That’s a migration. A deprecated model is a find-and-replace.

What to do about it this week

Three steps. None of them take an afternoon.

1. Grep your own stack for model identifiers. Count files, not occurrences — files are what you have to edit. Include your markdown, your prompts and your config, not just your code.
2. Split the list in two: swappable or identity-bearing. Capability can be replaced. Identity cannot. You will almost certainly find fewer identity-bearing pins than you feared, and at least one you didn’t know about.
3. Move the identity-bearing ones into one config file. Not seventeen. The goal isn’t to never change a dependency; it’s to change it in one place when you have to.

And the deprecation dates going around?

One more thing, because it’s the reason this question gets asked in a panic rather than calmly. I went looking for the retirement dates currently circulating for a model I don’t even use, and found three mutually contradictory dates for the same one, none of them traceable to the vendor. So I’m not printing any of them.

Don’t build a migration plan on a forum number. Read the vendor’s own deprecation page, because that’s the useful thing about this entire category of risk: a retirement comes with a date you can read in advance. Compare that to a tool that just breaks one morning with no warning at all. Model deprecation is the only kind of failure in this business that sends you a calendar invite. It’s the easiest one to survive, and it’s the one people fear the most.

If you want the bigger picture on how these pieces fit into one system that runs unattended, I laid it out in the full guide to building a fully autonomous AI agent. And if you’d rather have someone inventory your stack properly the first time, book a strategy session and we’ll map it together.

See you next Friday. — Jon