When the Model You Rented Disappears

It was gone for eighteen days. Nobody who built on it picked any of those dates.

Anthropic’s most capable model went live on June 9th. By June 12th it was gone. On July 1st it came back.

Eighteen days, and nobody who had built on it picked a single one of those dates.

That’s the part worth keeping now that the panic has passed. Fable 5 launched with a million-token context window and the best coding score anyone had posted, free to paying subscribers, and people wired it into their products the way you wire anything that looks permanent. Then the Commerce Department ordered access suspended under export-control rules, citing national security. The instruction covered any foreign national, inside or outside the United States, including Anthropic’s own employees. There was no way to comply narrowly on that deadline, so the model went dark for everyone. Two and a half weeks later the controls were lifted and it returned.

I’m not writing this to pile onto Anthropic. I use their tools every day, and an impossible order arrived with a clock on it. I’m writing it because of what those eighteen days did to people who had made one model “load-bearing”, and because the ending makes the lesson easier to ignore than it should be.

Rented reach, rented foundations

I’ve said for a while that the followers you collect on a platform aren’t yours. You rent access to them, and then the landlord changes the rules whenever they want.

Fable 5 pointed that same lesson at a different part of the stack.

A legal-AI startup called Legion went to court over it, because their product stopped working the moment the model did. Their filing put it plainly: every day the directive held disrupted their product and operations, sidelined their engineers, and eroded the company’s ability to survive in a field defined by continuous access to the most capable models. Legion did exactly what everyone tells you to do. They built on the best model available, and then they learned what “available” means when it depends on a vendor and a government you don’t control.

Across developer forums the conversation shifted inside a week. It stopped being about which model scores highest and started being about single points of failure. Teams that had hard-coded one provider spent those days building the ability to fail over to another. The ones who already could just kept working.

Tying your business to one frontier model isn’t a safety net. It’s a hope.

Draw the line before you need it

You can’t self-host a frontier lab, and you shouldn’t try. What you can do is decide, in advance and in writing, which parts of your system have to be yours and which parts you’re happy to rent.

I run my business on something I built called Core: my CRM, my tasks, my content, and the record of what actually shipped. That lives somewhere I control and can move. I self-host the pieces that are genuinely mine, the hosting and email behind my core workflow product. Everything else is a deliberate rental. Supabase runs my production databases, and it earns its keep with backups and security I’d otherwise be maintaining at two in the morning. Kit and Substack handle publishing. All in, I’m paying somewhere around a hundred dollars a month across managed services, and that number goes up as I ship more.

Sovereignty was never a cheap monthly bill or cancelling all your SaaS. It’s owning the core and renting only what genuinely earns its place.

The models sit firmly on the rented side, and they’re deliberately swappable. When one’s best for a job, I use it. When it’s gone, I route around it. The value was never in any single model; it’s in the harness around it, the contracts between the pieces, and knowing my own work well enough to point whatever model is standing at the problem.

The lane nobody can switch off

Since June I’ve been building one piece of insurance, and it isn’t a second subscription.

At 1:46 in the morning last week, two models running on my own laptop each drove a 39-turn research loop with live web search across ten topics, and both produced valid structured reports. No API bill, no account, no policy anywhere that could switch them off mid-run.

They’re not as good as the frontier models. That isn’t the point. The point is that a lane nobody can revoke changes what the revocable lanes are allowed to cost you. Bounded, repetitive, verifiable work is a good candidate: research, extraction, summarizing, the tasks where you can check the output yourself in seconds.

I’d also rather state the reason plainly than dress it up. Quota exhaustion is a routine operating condition here, not an incident. And the subscription policies underneath all of this have reversed three times in four months, which I keep on my risk list rather than in my feelings. Owning one lane outright is how a policy change stops being an outage.

What this isn’t

It’s easy to turn one strange month into a sermon, so let me be careful.

This isn’t an argument to abandon the big models. They’re remarkable, they do things nothing on my laptop can approach, and you should use them. You also don’t need an elaborate five-provider routing layer you’ll never maintain. Building that before you need it is its own kind of trap.

And I’m not predicting a repeat. The controls lifted, the model came back, and the specific politics of June may never recur. What you got was a free, low-stakes look at what a hard dependency feels like when it fails. The next one will cost more than a look.

Do this in the next ten minutes

Open whatever runs your business and find your single biggest dependency on something you don’t control. The model behind your app. The platform that holds your audience. The service that holds your data.

Write one sentence: if this disappeared for three days, here’s exactly what I’d do.

If you can answer cleanly, you own the seam and you’re fine. If the honest answer is that you’d be stuck, you’ve found the first thing worth fixing, and it starts smaller than you’d think. Export the data. Write down the manual fallback. Turn one hard-coded provider into a setting you can change.

You don’t need to predict the next directive. You need one dependency you’ve stopped pretending is permanent.

If you want help working out which layer to own first, and then building it, that’s exactly what I do with operators.