Open Weights Are Your Insurance Policy

If you follow the hype train with AI, you'll know that on June 12, Anthropic released Claude Fable 5 and pulled it three days later after a US government export control directive forced a global shutdown.

Luckily, two AI models from Chinese companies, GLM-5.2 and MiniMax-M3, are now outperforming most other open models on real-world tasks. They run at roughly one-fifth the price of the leading closed model, Opus 4.8. The real issue is a risk most companies have not priced in yet.

Closed models like Opus, GPT-5, and Gemini run behind a company's API. You send a question, you get an answer, and you have no control over whether the model stays available. Open-weight models publish their design files so anyone can download and run them. You can host them yourself, use a third-party provider, or do both. The model cannot disappear without you having options.

Every closed model carries that same exposure. The actual risk is rarely a sudden shutdown. It is slower erosion: price increases, rate limits, capability changes without warning. Those happen every quarter. You just get used to them until the bill or the output quality stops you. Open weights do not solve sudden shutdowns by themselves, but they let you walk away before the erosion gets worse.

You do not need to run these models on your own hardware. That is still too expensive for most small/mid-sized companies, probably until mid-2027. What you do get right now is choice. GLM-5.2 is available through over 20 providers. If one goes down, you switch to another. The design is public, so you are limited by hardware, not permission. That said, local models are useful right now. I am running Qwen3.6-27B on local hardware and the more I use it, the more I like it. It covers a growing set of private and latency-sensitive tasks without touching an API.

The cost difference makes the case harder to ignore. Each step down in model quality cuts the price roughly five times, with only a small drop in performance. For products that process thousands of user requests per day, a five times cost difference is not an optimization. It is the difference between a business that works and one that does not. The math only flips at volume though. If you are spending $5,000 a month on Opus, the cheapest model saves you a few thousand and costs you more in engineering time to integrate and maintain. This argument is for the companies already burning six figures on inference, or the ones heading there.

The best approach is to use multiple models for different tasks. Use the most capable models for hard engineering work. Use cheaper models for the everyday tasks. Run local models for private work. Build your system so you can switch between them when one goes down. That switch is not free. It means writing model-agnostic abstractions, testing every workflow against every fallback, and maintaining prompt templates that behave differently per model. The real insurance is not the models you have on standby. It is application design: output schemas, retry logic, graceful degradation. The model you call is an implementation detail. The companies that survive the next outage are the ones that built for it.

There is also the China factor. GLM and MiniMax come from Chinese companies, and that triggers data residency questions, legal review, and procurement holds. You can argue the weights are public and available from Western providers, but the people who sign off on these purchases are not going to accept that as a shortcut. Open weights from Western labs will eventually close that gap, and the principle stays the same regardless of origin: public weights are optionality, closed weights are a bet.

Companies that build everything on a single closed model are going to find out the hard way. Fable was a preview, and the next outage will not come with everyone already on alert.

If you are building AI products right now, what is your fallback plan when a model goes down? I want to hear how other teams are handling this. Contact me or find me on LinkedIn.