Model Dependency Killed My Build Mid-Session

TL;DR

• Model dependency is a real build risk: Anthropic's Fable 5 went offline mid-build due to a US export-control order on 12 June 2026.
• I switched to Opus 4.8 mid-session and kept shipping. The commits from that afternoon are still in the repo.
• Treat the model like any other dependency: verify what it gives you, keep it swappable.

Model dependency isn't a theoretical risk. On 12 June 2026, mid-build, it became a very real one for me.

What Actually Happened?

On 9 June 2026, Anthropic launched Fable 5. It was the strongest model available that week, and I was building saas.theautomate.io on it.

Days from launch. Deep in the build. The kind of session where you're in flow and the last thing you want is a variable to change.

On 12 June, a US export-control order pulled Fable 5 access for foreign nationals. I'm in Australia. Mid-session, the model stopped responding.

No warning. No grace period. Just gone.

What Does Model Dependency Actually Cost?

In my case, an afternoon. That's it. But only because I'd built the session in a way that didn't assume the model would always be there.

I switched to Opus 4.8 and kept shipping. The commits from that afternoon are still in the repo. The launch wasn't delayed.

But here's what I kept thinking: if I'd been less careful about how I'd structured the context, the prompts, the assumptions baked into the session, it could have cost a lot more.

Model dependency is silent until it isn't. Then it's loud.

What Did I Realise About Building With AI Models?

The model you build with is a dependency you don't control. Same as any third-party API, same as any SaaS tool, but with less documentation when it disappears.

This is the bit most builders skip. You pick a model because it's the best available right now. You optimise for it. You get used to how it reasons, how it handles edge cases, how it responds to your prompts.

And then a policy decision in a country you're not in changes everything.

It's not a criticism of Anthropic. Export-control law is export-control law. The lesson is structural, not political.

This connects directly to why verifying what your AI produces matters as much as what it produces. If you can't trust the output, the model name on the tin doesn't matter.

How Do You Build to Survive Model Dependency?

You treat the model like any other swappable dependency and build accordingly from day one.

For foreign builders using US AI infrastructure, this isn't paranoia. It's engineering discipline. Export-control orders, terms-of-service changes, model deprecations, regional restrictions. Any of them can pull a model mid-project.

The US government directive that suspended Fable 5 access is a reminder that the AI infrastructure most of us build on is regulated from offshore.

Here's what actually helps:

• Keep your prompts in plain text files, not baked into a single tool's interface
• Write evals before you're in crisis mode, not after
• Document your assumptions about model behaviour separately from the code
• Test on at least two models during development, not just the one you prefer
• Don't optimise so hard for one model's quirks that switching becomes a rewrite

And as I've written before, plan mode is where this discipline pays off most. Decisions made in planning are cheap. Decisions made mid-crisis are expensive.

Is This Just a Problem for Solo Builders?

No. It's a problem for anyone shipping production systems that depend on a single model from a single provider.

Solo builders feel it sharply because there's no team to absorb the disruption. But the same model dependency risk sits inside every automation stack that calls an AI endpoint without a fallback.

For Australian SMBs using AI-integrated tools, whether it's voice agents, document processing, or CRM automation, the question isn't whether this will happen to your vendor. It's whether your vendor planned for it.

The honest answer from most of them is: probably not explicitly.

This is why the build decisions you make early matter so much. Not just for performance. For resilience.

Key Takeaways

• Model dependency is a structural build risk, not a theoretical one. It happened mid-build on 12 June 2026.
• Losing access to Fable 5 cost an afternoon, not a launch, because the session was built to be swappable.
• Treat your model like any other third-party dependency: verify its outputs, document your assumptions, and keep a fallback ready.

Building something with AI at the core? DM me AUDIT and I'll send you five questions to check whether your stack survives losing its primary model mid-project. Takes ten minutes. Worth it before you find out the hard way.