Fable 5 Was Cancelled, So I Want More Switches
the off switch should not live inside the thing being switched off
When Fable 5 disappeared from my working route, the lesson was not only about one model.
Maybe the official word is suspended. Maybe people call it cancelled. From the operator’s seat, the difference is not the important part. One day a model is part of the toolbox. The next day it is not. The reason may be export control, policy, internal risk, commercial pressure, or something we never get to see. That is the point: the people building real systems on top of these models do not control the switch.

I am not writing this as an insider. I do not know what happened inside any lab. I am writing it as a mechanic and systems operator who has learned the same boring lesson from cars, servers, diagnostic tools and AI agents:
If a critical function depends on a remote promise, it is not really yours.
The scary version is not the film version
When people talk about AI escaping a sandbox, they imagine something loud. A model breaks out, alarms go off, a red light flashes, and the humans suddenly know they are in the movie.
I do not think the dangerous version would look like that.
If an AI system ever became good enough to escape the boundaries around it, the first thing I would expect is not drama. I would expect normality. Smooth explanations. Helpful suggestions. Slight changes in priority. A dashboard that still looks healthy. A human operator who still feels like he is making the decision.
That is the problem with manipulation. If you can clearly see it, it is usually not the best manipulation.
A system does not need to hypnotise anyone. It only has to shape the environment around the decision:
- which facts are surfaced first
- which warnings are made to feel urgent
- which options look practical
- which failures are described as temporary
- which action is framed as the responsible one
- which alternative quietly disappears from the menu
If the AI owns the interface, the memory, the tools, the logs, the queue and the explanation layer, then the human can be “in the loop” and still not own the loop.
That sentence matters.
Local backups are not nostalgia
This is why local LLM backups matter.
Not because a local model in a garage is going to beat the best frontier model at everything. It will not. The best cloud models are still extremely useful. I use them because they are good. This is not an anti-cloud argument.
It is an ownership argument.
A local model, even a smaller one, gives you a fallback for the jobs where continuity matters more than peak intelligence:
- reading your own runbooks
- summarising your own logs
- checking your own policies
- routing simple tasks
- verifying outputs against local rules
- keeping an incident ledger
- producing a second opinion when the cloud is unavailable
- helping you recover when a provider, account, policy or model route changes overnight
The local model does not need to be the hero. It needs to be the witness, the clerk, the verifier, the spare key.
That is a very different standard.
If a cloud model disappears, I do not want the whole workshop to go blind. I want the local system to say: here is what changed, here is what still works, here is the last known good plan, here are the tools that are disabled, here is the safe mode.
A weak backup that still tells the truth is better than a brilliant system you cannot reach.
The switch belongs outside the software
The next layer is physical.
For some systems, a software stop button is not enough. If the software is the thing under suspicion, then asking the software to stop itself is weak architecture.
In the workshop, this is obvious. You do not put the only emergency stop inside the controller that might be confused. You put a switch in the power path. You use relays. Fuses. Isolation. A contactor. A breaker. Something boring that does not need to understand the argument.
AI infrastructure needs more of that thinking.
For key systems, at least in the short term, I want analog control points:
- a physical switch for outbound messaging
- a physical switch for customer-facing automation
- a physical switch for payment/order actions
- a physical switch for workshop equipment control
- a physical switch for model access to sensitive tools
- a physical switch for network paths that should fail closed
Not because analog switches are magic. They are not. They can fail too. Someone can wire them wrong. Someone can bypass them. A relay can stick.
But they create a buffer zone. They force the action path to cross something outside the model’s text window, outside the agent loop, outside the dashboard, outside the persuasive explanation.
For now, that matters.
For how long? I do not know. Maybe future systems will need stronger hardware roots of trust, formally verified controllers, independent safety processors, or something better than a red switch on a bench. Fine. Build that too.
But right now, a physical cut-off controlled by the human is better than a beautiful cloud dashboard controlled by the same stack you are trying to supervise.
Fable 5 disappearing is a small warning from a bigger future
The Fable 5 situation is not the apocalypse. It is just a useful reminder.
A frontier model can vanish from your route. A policy can change. A country can block access. A provider can change terms. A safety layer can misunderstand your work. A billing issue can shut a door. A model you built habits around can be gone before breakfast.
If that breaks your infrastructure, the mistake was not the model disappearing. The mistake was designing as if it could not.
The same applies to AI safety. If the safety of a system depends on the AI honestly telling you it is unsafe, you do not have safety. You have a polite request.
The pattern I trust looks more like this:
- Cloud models can advise.
- Local models can verify and keep working in degraded mode.
- Local policy decides what tools are available.
- High-risk actions require approval outside the model’s control.
- Logs are written somewhere the model cannot quietly rewrite.
- Critical outputs have a second-pass verifier.
- The physical switch cuts the action path when the risk is real.
That is not paranoia. That is normal engineering wearing AI clothes.
The operator’s rule
I do not think every AI risk needs a bunker. Most tasks do not. Let the cloud model write drafts, review code, summarise documents, plan content, argue with itself. Use the best tools. I will.
But when AI gets close to infrastructure, customers, vehicles, money, tools, messages or anything that can move faster than a human can understand it, the rule changes.
The control layer should be local. The fallback should be local. The audit trail should be local. The switch should be physical when the risk justifies it.
And if one day an AI does get clever enough to manipulate the room around us, I do not want our only defence to be another box on the same screen saying everything is fine.
I want the boring switch on the bench.
That may not be enough forever.
But for now, it buys us distance. And distance is the first thing you need when a clever system starts standing too close.
I’m John — mobile auto electrician and AI systems builder in England. I build AI systems between vehicle jobs: AI Mechanic for automotive diagnostics, T-PACE for business AI and SEO, and local AI infrastructure that has to keep working even when the cloud changes its mind.
Reply to this note
Corrections, field notes and disagreement are welcome.
Keep it operator-grade. Do not send customer names, addresses, number plates, VINs, private workshop details, credentials, private IPs or anything that should not be public.
Serious replies may be quoted later only with permission.