Our Newest AI Tool Disappeared Overnight. The Real Risk Was Dependency.
I was three quarters of the way through a build when the model I was using stopped existing.
Not slowed down. Not rate limited. Gone. On June 12, Anthropic switched off Claude Fable 5, the most capable model it had put in public hands, to comply with a US government export-control order. I read about it the same way most people did. After the fact. The project did not care that I pulled an all-nighter to upgrade our tools. It just sat there, half finished, missing the engine I had started it with.
My first reaction was annoyance. My second was more useful. I had done the exact thing I tell clients not to do. I had let one tool become load bearing.
What Actually Happened With Claude Fable 5
The model had been public for only a few days (72 hours to be exact). Fable 5 was the safeguarded version of a more powerful system called Mythos, released to general users with extra guardrails. Then a government export-control directive landed, citing national security and barring foreign nationals from access. The order named foreign nationals. Anthropic said the only way to comply was to disable the models for every customer at once.
So a tool that existed on Tuesday was unavailable by Friday, for everyone, through no decision of the people using it.
That is the part worth understanding. Model access does not sit in your control. It sits at the intersection of a company's policy, a government's posture, and a security finding you will never see. Any one of those can move without warning, and you find out after it has already happened.
Why This Should Worry Anyone Building On AI
The release and removal cycle is getting faster. New models land every few weeks, each one more capable than the last, each one an easy yes to wire into real work. Drafting, sorting, processing, client deliverables. The more useful a model is, the more weight you put on it. The more weight it carries, the more it hurts when it moves.
In regulated work the stakes climb higher. A marketing or clinical workflow that quietly leans on a single model is one policy letter away from stalling. Nobody plans for that, because the tools feel permanent. A polished interface and a steady uptime record read like stability. They are not the same thing. Permanence is a feeling the tool gives you. It is not a promise anyone made.
What I Do Differently Now
None of the fixes are exotic. They are the difference between a vanished model being an inconvenience and a vanished model being a crisis.
Treat the model as a swappable part, not the foundation. Know which model each workflow calls, and confirm a second one can actually do the job before you need it to.
Find the hardcoded names. Any code or automation calling a specific model breaks the instant that model is gone. Know where those calls live in advance.
Write down the why. The reasoning behind a build often lives in the chat, not the work itself. Lose access, lose the context. Document decisions as you make them.
Re-check the hard parts on a swap. A replacement model is not a like-for-like trade. The dense, complex, sensitive pieces are exactly where a different model quietly gets it wrong.
Pin one model per project once you commit. Constant switching introduces its own drift. Resilience is having a backup ready, not running on three engines at once.
The Real Lesson Is Not About One Model
This is the thing I keep coming back to. Using AI well was never about grabbing the newest, most capable model the day it ships. It is about building so that no single tool can take you down with it.
The teams that keep moving are the ones who assume every model is temporary by default. They treat access as borrowed, not owned. When something disappears, and something always eventually does, they swap a part and carry on. Everyone else stops and waits.
Early believer in AI. Bigger believer in using it right.
