Model Dependency Killed My Build Mid-Session
    Behind the Scenes

    Model Dependency Killed My Build Mid-Session

    SBSyed Bilgrami14 June 20264 min read

    On 9 June 2026 I was building on the strongest model available. By 12 June it was gone. Here's what model dependency actually costs when you're days from shipping.

    On 9 June 2026 I was building on the strongest model available. By 12 June it was gone. Here's what model dependency actually costs when you're days from shipping.

    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.

    Scene: building saas.theautomate.io on Fable 5, days from launch

    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.

    Then: Fable 5 stopped responding mid-session due to export controls

    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.

    Realised: the model is a dependency you don't control

    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.

    Changed: switched to Opus 4.8 mid-session and kept shipping

    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? Five questions will tell you whether your stack survives losing its primary model mid-project. Takes ten minutes, and it is worth knowing before you find out the hard way. Send us a note and we will send them over.

    Frequently Asked Questions

    What is model dependency in AI development?
    Model dependency is when your build assumes a specific AI model will always be available. If that model gets restricted, deprecated, or goes offline, your project breaks. It's the same risk as any third-party API dependency, but with less notice when things change. Building with a single model without a fallback plan is the most common version of this risk.
    What happened to Fable 5 access for Australian builders?
    On 12 June 2026, a US export-control order pulled Fable 5 access for foreign nationals, including Australians. Builders mid-session on the model lost access without warning. This is an example of how offshore regulatory decisions can directly affect Australian developers using US AI infrastructure, regardless of their relationship with the provider.
    How do you switch AI models mid-project without losing progress?
    Keep your prompts in plain text files, write evals early, and document your model-specific assumptions separately from your core code. When Fable 5 went offline, switching to Opus 4.8 was possible because the session wasn't locked to one model's interface. The commits kept flowing. Portability is a build decision you make before the crisis, not during it.
    Does export-control law affect Australian AI developers?
    Yes. Most AI infrastructure used in Australia is hosted and regulated in the US. Export-control orders, sanctions, or policy changes made in the US can restrict access for Australian users. This isn't unique to any one provider. Any Australian builder or business using US-based AI models should treat this as a real operational risk and plan accordingly.
    What's the practical fix for model dependency risk?
    Test on at least two models during development. Store prompts as portable plain text. Write evals that work across models, not just your preferred one. Don't optimise so hard for one model's quirks that switching requires a rewrite. And plan your session structure before you're deep in the build, not after the model disappears.

    Share this article


    SB

    Written by Syed Bilgrami

    Runs TheAutomate, a Melbourne automation agency. He scopes the work, writes it, and picks up when it breaks.

    What is the work that repeats in your business?

    Book a 30 minute discovery call with Syed. He scopes the work himself, so you are talking to the person who would build it.

    Book a Discovery Call

    Related Articles