ikkachar.dev
All writing
3 min read

Build for the model you'll lose

The best coding model in the world lasted three days before a government directive switched it off. The lesson is not 'use local models.' It is 'never couple your product to a model you are not allowed to keep.'

Claude Fable 5 shipped on June 9 as, by most benchmarks, the best coding model in the world. By June 12 it was gone. A US government directive ordered Anthropic to cut off all foreign nationals, the segmentation was not clean, and the only way to comply was to switch the model off for everyone. Three days, public to dark.

If your product had a model: "claude-fable-5" line in it that week, you did not have a bug to fix. You had a dependency you were never allowed to keep.

The reflex is half right

The loudest reaction was predictable. "This is exactly why we need local models," went the top thread on r/LocalLLaMA, and it is not wrong. A model running on your own hardware cannot be switched off by a letter that arrives at 5:21pm.

But local-or-bust is the wrong lesson to take from this. Most teams cannot self-host a frontier model, and even if they could, they would be trading a political risk for an operational one: weaker capability, a GPU bill, and a model that is now your problem to keep running. You do not need to own the model. You need to never depend on a specific one.

The real lesson is substitution

The teams that shrugged on June 12 had one thing in common. Swapping the model was a config change, not a rewrite. Their product did not know or care which model was behind the call, because no single model's behavior had been baked into the code, the prompts, or the team's assumptions.

That is the property worth engineering for. Not "the best model," not "the model I host myself," but "a model I can replace by Friday without my users noticing."

The switch-off test

Pick the single model your product depends on most. Now assume it disappears tonight, permanently. If your honest recovery time is measured in weeks, you do not have an architecture, you have a hostage situation.

What portability actually looks like

It is unglamorous, which is why most teams skip it until a directive forces the issue:

  • An abstraction at the call site, so the model is a parameter, not a constant scattered across forty files.
  • A real fallback you have actually run, not a second model name you have never sent a production request to. Untested fallbacks fail exactly when you need them.
  • Prompts that do not lean on one model's quirks. If your output only holds together because Fable 5 happened to format things a certain way, you have a model-shaped crack in your product.
  • Evals that tell you the swap is safe. The only way to switch models with confidence is to measure that the new one still passes. This is, again, why your evals are the moat.

You are renting, so act like it

The whole industry is renting capability from a handful of labs, and that capability now comes with a geopolitical attribute it did not have a year ago. A model can be the best in the world and still be revoked by someone who is not your customer, your vendor, or your problem to argue with.

So build for the model you'll lose. Assume the one you depend on today gets switched off, repriced, deprecated, or geofenced out from under you, because eventually one of them will. The teams that treat their model as interchangeable will keep shipping. The ones that married a single model will spend that week on r/ClaudeAI asking a US citizen to marry them for API access.

One of those was a real post. It had 2,500 upvotes. Do not be the architecture that makes it relatable.

Did this resonate?

Get new essays by email

Field notes on AI-native products, straight to your inbox. No spam, unsubscribe any time.