Your business has a single point of failure. Mine was an AI model.

Your business has a single point of failure. Mine was an AI model.

I was about to spend the next month building a browser that I thought could take months, possibly years, to build the traditional way.

I had the architecture planned, the research done, and an AI model that made the whole thing feel achievable. We had been using Claude Fable 5 to work on some ambitious projects, including AI memory infrastructure. It was finding bugs, suggesting techniques we hadn’t considered, and helping us make progress much faster than we could with our previous tools.

I had paid for Claude’s Max plan because I wanted to make the most of that capability.

Then the US government intervened.

On June 9, 2026, Anthropic released Claude Fable 5. On June 12, the company announced that a US government export-control directive required it to suspend access to Fable 5 and Mythos 5 for all customers. Anthropic said the directive cited national security authorities and appeared related to concerns about bypassing the models’ safeguards. The company restored access on June 30, with Fable 5 becoming available again on July 1.

You can read Anthropic’s original announcement and its update on restoring access.

Three days separated the model’s release from the restriction.

I had built my plans around something I didn’t control. And when it became unavailable, the alternatives we had tried didn’t come close to what we needed at the time.

We couldn’t make the progress we expected. The browser project had to wait, and so did other work that depended on that level of capability.

That experience made a piece of advice from my mentor finally click.

I had mistaken capability for reliability

My mentor had warned me about building things around a single dependency. I didn’t pay much attention to it back then.

I understood the words. I just hadn’t experienced what they meant.

When a tool works exceptionally well, it’s easy to start designing everything around it. You adapt your workflow to its strengths. You choose projects based on what it makes possible. You invest time learning how to get the best results from it.

Eventually, the tool stops being just one part of your workflow. It becomes the foundation underneath everything else.

That’s where things get dangerous.

The problem wasn’t that Fable 5 was a bad model. Quite the opposite. Its capabilities were exactly why I had become so dependent on it. The problem was that I had no adequate alternative ready when access disappeared.

I had optimized for what the model could do, not for what would happen if I couldn’t use it.

And this isn’t unique to AI.

A service business can depend on one engineer who understands the entire codebase. A company can depend on one vendor to deliver something its customers cannot do without. An organization can have a process that only one employee knows how to run.

As long as everything works, these arrangements can look perfectly reasonable.

Until they don’t.

I started free-tier maxing

After that experience, I began distributing my work across different AI tools instead of routing almost everything through Claude.

I call it free-tier maxing.

The name is a little unserious. The underlying idea isn’t.

I started looking at which tools could handle which tasks, what free or existing plans I could use, and where I actually needed to spend money. For a while, I used my boss’s Cursor account for work. Later, I discovered OpenCode through friends and started using it for suitable work tasks, while being careful about the data sent to external model providers.

I kept my paid Claude subscription for personal projects, coding, research, and studying. I moved general querying and some data-processing tasks to Gemini, which I also pay for. I use Gemini for image generation, too, and ChatGPT for image generation when it makes sense.

I also moved my blog-writing workflow to ChatGPT.

I narrate my ideas rather than type every thought out. A single blog can involve a long voice note, several rounds of questions, research, editing, and revisions. I have an open-source framework for this process, and I wanted to be able to publish consistently without consuming the same pool of coding credits I needed for other work.

So I used Claude to help configure my blogging workflow in ChatGPT and transferred relevant settings, prompts, and personal context into the tools I use.

That initial setup took a few days.

It wasn’t free in the sense that my time cost nothing. I had to move context, configure the tools, test their responses, and figure out which tasks belonged where. But once the setup was done, I had a system I could use without routing every request through one provider.

My estimated AI expenses dropped by roughly half compared with my earlier setup. That’s my experience, not a claim that everyone will save the same amount.

More importantly, I had options.

If one tool wasn’t producing good enough results, I could try another. If one service became unavailable, I had alternatives for at least some of the work. And I could reserve my most expensive or capable tools for the tasks that actually justified using them.

I didn’t stop relying on AI.

I stopped relying on one AI provider for nearly everything.

Redundancy is useful only when you can switch

There is a catch here.

Having access to five tools doesn’t automatically make a business resilient. If all five depend on the same underlying provider, share the same failure mode, or can’t handle the task you need to complete, you haven’t diversified much.

A backup needs to be capable of doing the job.

It also needs to be ready when you need it.

Imagine a company whose entire development workflow depends on a particular AI coding tool. Buying access to a second tool isn’t enough if nobody has configured it, the team’s instructions only exist in the first tool, and nobody knows how to move the work over.

The alternative exists on paper. Operationally, the company is still stuck.

That’s why I think about dependencies as part of system design. I want to know what each component does, what depends on it, and what happens when it becomes unavailable.

For a business using AI, that might mean choosing an aggregator that provides access to multiple model providers, building provider-independent integrations, keeping task instructions and project context portable, or maintaining a tested fallback for critical workflows.

For other businesses, the answer might be a second supplier, documented procedures, cross-training, or a clear process for handing work over when someone leaves.

None of these approaches is effortless. They cost money and time, and maintaining alternatives that are rarely used can become its own expense.

I wouldn’t build an expensive backup for every minor dependency. I’d start with the ones whose failure could stop delivery, interrupt revenue, or leave customers without something they rely on.

The important part is deciding that before the failure happens.

The same problem gets more expensive as you grow

I’m still building my own business, so I can’t pretend I’ve already solved this at the scale of a large company.

But I know how I want to approach it as I grow.

When I build a team of engineers, designers, marketers, and salespeople, I don’t want every important workflow to depend on one tool or one person.

If an engineer leaves, someone else should be able to understand the system and continue the work. If a vendor becomes unavailable, there should be a practical route to another provider. If one tool stops producing acceptable results, the team should know what to use instead.

That doesn’t mean every employee must be interchangeable or that every piece of knowledge needs to be documented in exhaustive detail.

It means the business shouldn’t grind to a halt because one person is absent or one dependency disappears.

The same principle applies when selling services to other businesses. Clients aren’t just buying the immediate work. They’re also taking on some risk when they depend on you to deliver it.

If a critical service relies entirely on one person, a client may reasonably worry about what happens when that person is unavailable. If you can’t explain how you handle continuity, you make the decision to trust you harder than it needs to be.

The right response isn’t to promise that nothing will ever go wrong. It is to understand the risks, reduce the ones you reasonably can, and be honest about the ones you cannot eliminate.

You can’t predict every failure. You can design for some of them.

I still use Claude. I still think powerful AI models are worth paying for when they help me do work that would otherwise take significantly longer.

The lesson wasn’t to distrust a good tool. It was to stop confusing a tool’s usefulness with my ability to depend on it indefinitely.

I can’t predict every government decision, service outage, price change, vendor shutdown, or personnel change. Neither can anyone else.

And sometimes, particularly when you’re starting out, you simply won’t have enough money or time to build a backup for everything. You take the risk because the alternative is not moving forward at all.

That’s a trade-off, not a failure of judgment.

But as a business grows, it gains more to lose from an interruption. The systems that helped it move quickly at the beginning can become the same systems that hold it back later.

Whenever I think about a new business or project now, I try to ask one additional question: If this one dependency disappeared tomorrow, what would actually stop working?

I don’t need a backup for everything.

I need to know which failures I can afford, which ones I can’t, and what I’m going to do about the difference.