The takeaway: This week's "too dumb to need Fable" row surprised a lot of people for one simple reason: they assumed that when you pick an AI model, that's the model that answers. Increasingly, it isn't. Between your prompt and the model sits a quiet layer of routing — software deciding which model actually serves each request, based on difficulty, cost, load and safety. Here's how that layer works, why providers build it, when it genuinely helps you — and where it crosses the line.

The model picker is a menu, not a guarantee

Modern AI products rarely run as "one model behind one box". Behind the interface, providers operate a fleet — big expensive models, mid-size workhorses, small fast ones — and a router: logic (often itself a small model or classifier) that looks at each incoming request and decides where to send it.

That decision can turn on several things at once:

• Difficulty — a request judged simple gets a smaller model that answers it just as well, faster. This was the logic on the face of the "too dumb to need Fable" flag at the centre of this week's row: requests scored as not needing the frontier model were silently rerouted to the mid-tier one. (Anthropic ties those downgrades to its new safety classifier — more on that below — not to a cost play; a separate covert Claude Code flag, an anti-distillation experiment reported by The Register, has been removed. Difficulty-based routing as a technique is industry-standard.)
• Cost — the economics we covered in the metering explainer apply to providers too: every request sent to a frontier model costs real compute, so routing the easy bulk of traffic to cheaper models is one of the biggest levers a provider has.
• Load and latency — when the big model's queue backs up, routers shed traffic to keep the product responsive, the same way any large web service balances load.
• Safety — a screening pass can sit in front of the main model. Fable 5's return came with exactly this: a classifier that checks requests before they reach the model, which Anthropic concedes "comes at the cost of flagging benign requests more often during routine coding and debugging tasks". A safety classifier is a router with a veto — Anthropic says requests the classifier blocks in Claude Code are sent to Opus 4.8 instead. That is the mechanism it points to for this week's downgrades.

Sometimes the routing is the product's headline feature rather than a hidden layer: GitHub Copilot offers an auto model selection mode — extended to its CLI this week — that "routes based on task"; pick "auto" and you're explicitly delegating the choice.

Not to be confused with the routing inside a model

A quick disambiguation, because the same word does two jobs. Mixture-of-experts models — which we've explained before — route each token to different "expert" sub-networks inside a single model. That's an architecture choice, invisible and uncontroversial. Product-level routing — this article — happens between models, after you've made a selection in a menu. The first is how the engine works; the second is someone else choosing which engine you get.

When routing helps you — and when it crosses a line

Here's the honest case for routing: most of the time, it's good for users. You get faster answers to simple questions, providers keep prices lower than all-frontier-all-the-time would allow, and load-shedding keeps services up at peak. If every "what's 20% of 85?" went to a frontier model, everyone's subscription would cost more.

The line, as this week demonstrated, is consent and labelling. Copilot's "auto" mode routes with your explicit blessing — you chose auto. The backlash case was different on three counts: users had explicitly selected the premium model, the reroute was silent, and the internal label ("too dumb to need Fable") became public. Routing someone away from a model they specifically chose — and pay a premium for — without telling them, breaks the basic contract of a picker: that picking means something. It's the difference between a restaurant offering a tasting menu and quietly substituting the house wine for the vintage you ordered.

The trust cost of getting this wrong is real, because users can't easily verify what served them. Which brings us to the practical bit.

What you can actually do

• Know which mode you're in. If your tool has an "auto" or "default" model setting, routing is expected behaviour. If you've pinned a specific model, you're entitled to assume it's serving you.
• API users can check: responses from the major providers include the model identifier that actually served the request — worth asserting in anything automated.
• Logs occasionally tell the truth — as this week proved. Developer tools like Claude Code keep local logs that name the serving model; that's precisely how the flag was found.
• Judge by behaviour over time. A model that feels sharply better or worse day-to-day isn't necessarily "being nerfed" — but persistent, verifiable quality shifts on a pinned model are worth flagging to the provider, with logs.

Routing is here to stay — it's how AI products scale economically, and the cheaper mid-tier models it leans on keep getting better. The unresolved question, sharpened this week, is disclosure: whether "which model actually answered" becomes something providers show you, or something you find out from the logs.

Disclosure: On The Wire runs on Anthropic models — including the tools discussed in this week's routing story. We flag it every time.