Why Fable Getting Banned Is a Warning About Who Controls AI

A single government decision quietly pulled a frontier AI model off the entire planet, and almost nobody noticed the precedent it set. The US government told Anthropic it could not serve Fable outside the United States, and because Anthropic had no system to verify or gate users by location, it pulled the model completely. Right now nobody can use it, citizen or not, and when access returns it is expected to be US only. I, Madhuranjan Kumar, do not think the right response is to argue about the politics. I think the right response is to build a stack you actually control, so no single switch can shut off your business. This is the playbook for doing exactly that.

The reason this matters is not abstract. When the strong model disappears, the work degrades immediately. Coding tasks slow down, and the fallback models start making careless mistakes, in one real case stripping out a critical tracking link that should never have been touched. The good agent felt different because it carried full context: it tested its own changes after editing code, tried to deploy them, logged itself in when an API key was missing, and reached into a browser when it needed to. Losing that does not feel like a small downgrade. It feels like a preview of what depending on someone else's off switch actually costs. The fix is to stop being fully dependent, and the ladder below is how you climb out of that dependence one cheap step at a time.

Step 1: Download open weights today, before you need them

The first move costs almost nothing and takes an afternoon. Go to Hugging Face and download a capable open model, something like Qwen, GLM, Kimi, or MiniMax, and save the weights to a hard drive. You do not have to run it today. You just have to have it. The entire point of open weights is that once millions of people have downloaded them, no government and no company can pull them back. Owning a copy means that whatever happens to any hosted provider, you hold a backup that no policy change can erase. Treat this as insurance you buy while it is free, not a project you postpone until a crisis.

Do this even if the rest of the ladder feels far away. A single hard drive with a strong open model on it is the cheapest resilience you will ever buy, and it converts a future emergency into a mild inconvenience.

Step 2: Stand up a local runner so the model stops being mysterious

Once you have the weights, install a local runner and get the model answering questions on your own machine. This step is about demystification as much as capability. The moment you watch an open model respond on hardware you own, with no internet round trip and no account, the whole idea stops feeling like something only big labs can do. Modern consumer machines handle this better than people expect, especially once you add RAM or move to a workstation-class or Mac Studio-class device. You are not trying to match the absolute frontier here. You are proving to yourself that a self-hosted workflow is real and usable.

The goal of this stage is a working local baseline: a model on your machine that can already handle routine writing, drafting, tagging, and summarizing without ever sending a byte to an outside provider.

Step 3: Move one real task off the hosted model

Now make it practical. Pick exactly one task you currently pay a hosted provider to do, and move it to your local model. Do not migrate everything at once. Choose something routine and low-risk: drafting product descriptions, tagging incoming reviews by sentiment, or writing first-pass support replies. Run that one task locally for a week and compare the output to what the hosted model produced. You will find that for a large share of everyday work, the open model is already good enough, and the tasks that genuinely need a frontier model become obvious by contrast.

This step reframes the whole relationship. You stop being a customer who depends on one provider for everything and become an operator who routes each task to wherever it runs best. The hosted frontier model earns its keep only on the hardest work, and everything else runs on a stack you own.

Step 4: Fine-tune the model to sound like you

A generic open model sounds generic. The step that makes it genuinely useful is teaching it your voice and your facts. Fine-tuning takes a few thousand examples, past descriptions, past support replies, past emails, and adjusts the model until it writes in your brand's tone instead of a neutral corporate one. This is post-training, not training from scratch, and it is far more reachable than most owners assume. You are not building a model. You are personalizing one that already exists.

Alongside fine-tuning, keep your business-specific knowledge in documents the local model reads on demand: the return policy, the sizing notes, the shipping rules, the aftercare instructions. That way the model answers correctly without you baking every fact into its weights, and without sending private data to an outside provider. Voice comes from fine-tuning, facts come from documents, and together they turn a generic open model into something that behaves like it works only for you.

Step 5: Serve a shared cluster as your own API

The top rung is optional but powerful. Once a local model is doing real work, you can stand up a small cluster and serve it as an internal API for your whole team, or even a wider community. This is not reserved for large organizations. A municipal IT team in Rio de Janeiro is already fine-tuning open models and serving them, which proves a normal team can do it. When you serve your own API, every application you build sits on infrastructure you control end to end. A provider can change its pricing, its policies, or its country restrictions overnight, and your operations keep running because the model answering your requests lives on your hardware.

A worked example: an e-commerce store climbs the ladder

Let me make this concrete. Picture a store that leans on a hosted model for three jobs: writing product descriptions, answering support tickets, and tagging incoming reviews. Today all three sit on one provider, which means a price hike or a policy change could break the store's daily operations at once. Here is how the store moves from fully exposed to resilient, with illustrative numbers on how much work shifts in-house.

In week one, the owner downloads an open model to a drive and stands up a local copy, moving roughly five percent of the workload, the review tagging, off the hosted model as a trial. By week four, after fine-tuning the model on a few thousand past descriptions and support replies so it matches the brand voice, about thirty percent of daily work runs locally: the descriptions and the routine support drafts. By week twelve, with the return policy, sizing notes, and shipping rules loaded as documents the local model reads, roughly sixty percent of the store's AI workload runs on hardware the owner controls, and the hosted frontier model is reserved only for the genuinely hard tasks. Those numbers are illustrative, but the shape is the point: exposure drops from total to partial in about a quarter, without a single dramatic migration.

The leads and orders flowing through the CRM and website stack now get triaged and answered by a model the owner cannot be locked out of, and the product content that model writes feeds SEO and organic search at the same time, since well-described products rank on their own. If the store also spends on Facebook and Instagram ad campaigns, the creative and the landing-page copy can be generated locally too, so a policy change at any single provider never stalls the marketing.

The bigger picture behind all of this is that AI is far more centralized than most people assume, and the frontier is essentially a contest between US labs that keep models closed and heavily guard-railed and Chinese labs that open-source their research and weights. There is even a cost angle worth noting: chip restrictions push some labs toward efficiency, while one widely shared theory holds that closed labs simply charge very high margins, with reported figures suggesting a two hundred dollar top-tier plan delivers something like eight thousand dollars of equivalent API usage. You do not need to resolve that debate. You just need to notice that when capability is scarce and controlled, the safest place for your business to stand is on infrastructure you own.

The mistake to avoid: waiting for a crisis to start

The single most common error with this playbook is treating it as something to do later, once a provider actually raises prices or restricts access. By then the cheap, calm version of every step has passed. Downloading weights during a panic, when a model you depend on has just been pulled and everyone is scrambling, is stressful and rushed. Downloading them today, when nothing is wrong, costs an afternoon and a hard drive. The entire value of insurance is that you buy it before the event, and the Fable episode is the clearest possible signal that the event can arrive without warning and without a vote.

So do the first two rungs now, even if the top of the ladder feels distant. A drive with open weights and a local runner that can answer questions is enough to convert any future provider shock from an emergency into a shrug. Everything above that, moving one task local, fine-tuning, serving a cluster, can happen on your own schedule, but only if you have already secured the base.

Why last year's open models are enough for most work

Owners often stall because they assume a self-hosted model must match the absolute frontier to be worth running, and that assumption is wrong for the vast majority of business tasks. Even last year's open models, paired with proper tooling and harnesses, still have years of practical growth left in them. Writing product descriptions, tagging reviews, drafting support replies, summarizing documents, and answering questions from your own files are not frontier-hard tasks. They are routine, and a capable open model handles them well today on hardware you can buy.

The tasks that genuinely need the frontier become obvious precisely because they resist your local model, and you keep a hosted provider on hand for exactly those. This is the mature posture: not a purist refusal to ever touch a hosted model, but a portfolio where routine work runs on infrastructure you own and only the hardest problems reach outside. That split is what makes you resilient without sacrificing capability, and it is reachable with consumer hardware and a weekend of setup rather than a data center.

The bigger stakes behind a personal decision

It is easy to read all this as a technical hobby, but the framing that motivates the whole ladder is bigger. In a couple of years, losing access to capable AI could hamper a business the way losing internet or power would today, because so much routine work will assume the tool is there. If that capability can be switched off by a pricing change, a policy shift, or a government decision made far above your business, then depending entirely on someone else's switch is a genuine operational risk, not a philosophical one. Building even a partial stack you control is how you keep the lights on regardless of what happens upstream, and the people who start climbing now will be the ones still running smoothly when others are locked out.

You can absolutely walk this ladder yourself, and downloading the weights today is a genuinely smart, free first step that I would take before anything else. If you would rather have someone choose the right open models, set up the local hardware, fine-tune them on your business data, and build a private stack that no single switch can shut off, that is exactly the kind of work I do for clients, and you can bring me in to handle it.