Privacy was never the only reason to run a model on your own machine. Control and resilience are, and I mostly forgot that until a frontier model I use went dark for 18 days.
On June 12, Fable 5 was pulled offline under a US Commerce Department export-control order. The model was barely out, still in the window where you’re deciding whether it’s earned a place in your daily loop, and a government order took it dark anyway. Nobody I know had anything to do with the order, and nobody I know could do anything about it. It came back on July 1, once the order was lifted. For two and a half weeks a brand-new frontier model simply wasn’t there. Not slow, not degraded. Gone, before most of us had even finished deciding whether to trust it.
That’s the part worth sitting with. The lazy version of this argument waits until you’re deeply dependent on a hosted model and then says “see what happens when it disappears.” But the dependency isn’t the scary part. The speed is. A model can go dark for reasons that have nothing to do with you, before you’ve committed to it, before you’ve even finished evaluating it, and there is no lever on your end that brings it back a day sooner.
I’ve written three honest cases for running a model locally: code you can’t paste into a hosted box, latency on the inner loop, and offline. That post also spent most of its length arguing that local models lose most of the time, which is still true. But it left a fourth case implied and never named, in one line about “the discipline of a workflow that doesn’t depend on someone else’s uptime.” The dark week is that line coming due. So here’s the fourth case, stated plainly: resilience.
You don’t own a workflow you rent#
The uncomfortable part isn’t that a model went down. Services go down. The uncomfortable part is why this one went down. A jailbreak researchers had flagged was the real trigger, and the model was patched before it returned, but the thing that actually cut your access was regulatory, not something a careless vendor or an unpaid bill explains: an export-control order is not on anyone’s incident runbook. Neither is a deprecation notice, a sudden price change, a region getting geofenced, or a Tuesday-afternoon outage with no ETA. The common thread: a single hosted endpoint is a single point of failure you don’t control and can’t fix.
When your inner loop runs entirely through one frontier API, that API’s uptime is your uptime. You’ve quietly made a business-continuity decision without treating it like one. It feels like using a tool. It’s closer to renting your workflow from a landlord who can change the locks for reasons the lease never mentioned.
A local model is the backup generator you keep meaning to wire up. It’s not as good as grid power. That’s not the point of a generator.
What resilience actually buys you#
Be clear about the size of the claim, because the temptation is to over-sell it. A local Qwen 2.5 Coder 1.5B running through Ollama is not a replacement for a frontier model. On anything hard, the quality gap is visible and frustrating, exactly as it was before the outage. Nothing about a dark week makes the small model smarter.
What it buys you is a floor. The inner-loop work I lean on most, autocomplete, function-signature completion, explaining a regex, rubber-ducking a small refactor, is the work a 1.5B model already handles well enough to keep you moving. That’s the same latency case I made before, now doing double duty: the local model that’s fast enough for the tab-key loop is also the model that’s there when the hosted one isn’t.
So the resilience version of the pitch is narrow on purpose. Keep a fallback you control for the inner-loop work, so a dark week is an annoyance instead of a full stop. You still lose the hard stuff, the big refactors, the recent-knowledge questions, the tasks where frontier quality earns its keep. But you keep typing. Half of something beats all of nothing.
The honest counter-argument#
Here’s where I have to argue against my own thesis, because the strongest objection is a good one: this almost never happens, and building for it is a tax you pay every day to insure against a week you might get once a year.
That’s fair. Eighteen days is real, but it’s also rare, and “prepare for the rare catastrophic thing” is how people end up with elaborate disaster-recovery setups they maintain forever and use never. If wiring up a local fallback meant standing up new infrastructure and babysitting it, I’d tell you to skip it and just take the bad week when it comes.
But the tax here is close to zero, and that’s what changes the math. If you already keep a warm Ollama daemon for the latency case, resilience is free. You’ve already paid for it. The model’s already pulled, the editor’s already pointed at http://127.0.0.1:11434, the 1GB of RAM is already resident. When the hosted endpoint goes dark, you don’t scramble to set anything up. You just notice your autocomplete still works and get on with it.
That’s the whole argument. Not “run local instead.” Run local as well, for the narrow slice of work where the small model is already good enough, and get resilience as a side effect of a setup you’d want anyway. The people telling you to go all-local are selling something. So, quietly, are the ones telling you a single hosted endpoint is all you’ll ever need.
Wiring the generator before the next outage#
If you want the fallback, the setup is the same one I’ve already written up, so I won’t repeat it in full. LM Studio if you want a GUI to pull and test models. Zed pointed at a local model or Ollama wired into Void if you want it in the editor. Qwen 2.5 Coder 1.5B is still the right size: small, fast, scoped for code, cheap on memory.
The only thing the dark week adds is a reason to actually do it instead of meaning to. A generator you install after the power goes out isn’t a generator. It’s a very slow apology.
Fable’s back. Mine stayed on the whole time, which is the only reason this reads like a note instead of a complaint. Pick the narrow slice where local is already good enough, keep the daemon warm, and the next time a hosted model goes dark for reasons that have nothing to do with you, your workflow doesn’t go dark with it.
