The single-model era is already over, most teams just haven’t noticed

If you’re still hitting one model from one provider for every request, you’re shipping a 2024 stack into a 2026 market. In eighteen months that sentence will sound obvious. Today it still sparks debate. I’ll earn it.

I’ve shipped vertical AI features for two years. My stack went from “one Claude call per request” to “three providers, four tiers, and a router in front.” Not because I like complexity. Every time I tried to simplify, the bill spiked or the quality sagged.

The pattern that shook out — and that I now see under the hood of serious vertical AI apps — is a three-layer router. Classifier on top. Model selector in the middle. Fallback at the bottom. By 2027, this will be standard, the way “use a CDN” became standard in 2014.

Here’s why it wins, and what each layer does.

Why one model can no longer be best, cheapest, and most reliable

The assumption that broke for me in 2025: “the frontier model” is a stable thing. It isn’t. The frontier moves every quarter, and it moves on different axes for different vendors.

Claude 3.5 Sonnet led on structured extraction for a while. GPT-4o caught up on extraction and pulled ahead on vision. Then Sonnet 4 jumped on tool use. Meanwhile Haiku and GPT-4o-mini got good enough for 70% of the cheap-and-fast work I was overpaying frontier rates to do.

Bet on one model and you’re making three bets at once:

• That it stays best for your task
• That the provider won’t deprecate it (Anthropic and OpenAI both have, with weeks of notice)
• That a competitor won’t undercut its price-per-token before your runway runs out

You’ll lose at least one of those. Probably all three, in cycles. The fix isn’t “pick better.” It’s “stop picking.”

Layer 1: the classifier — cheap model decides what kind of request this is

Top layer: a small, fast, cheap model that labels the incoming request. Not to answer it. To tag it.

In a vertical AI app, those tags are your domain. On an AEC product I worked on, the classifier returned one of a dozen labels: drawing markup question, code compliance lookup, quantity takeoff, schedule reasoning, vendor lookup, free‑form chat. In legal-tech you’d use different ones. Same for a support agent.

The classifier turns an unstructured ask into a concrete routing decision. Haiku or GPT‑4o‑mini does this in under 400ms for fractions of a cent. You can also use embeddings plus a simple logistic regression — cheaper and faster, but trickier to extend when you add categories.

Most teams skip this and send everything to Sonnet or GPT‑4o because “the big model can figure it out.” It can. You’re just paying 10–20x more to have a frontier model decide if the question is about pricing or refunds. That math gets worse every month as cheap models get great at classification.

Stripe Radar is the right mental model. It runs cheap rules and lightweight ML first, and only escalates when the cheap layer isn’t confident. Mature ML systems look like this. AI apps are about to as well.

Layer 2: the model selector — route to the right tier for the labeled task

Once you have a label, you’ve got a route. This is where most of the cost and quality gains live.

Map labels to model tiers. A solid starting point:

• Classification, summarization, simple extraction → Haiku / GPT‑4o‑mini / Gemini Flash
• Domain reasoning, multi‑step tool use → Sonnet / GPT‑4o / Gemini Pro
• Vision‑heavy or long‑context → whichever provider currently leads (this changes)
• Code generation → currently Sonnet for most cases, with a fast path for autocomplete

The selector is also where product judgment lives. Maybe your highest‑value users always hit the better model. Maybe free users hit the cheap model with a quality fallback. Maybe regulated flows must run on a specific provider for compliance. Put that policy in config, not in a switch statement buried in a handler.

Cursor’s model picker is the user‑facing version of this: let the user choose. That’s a valid call — surface the selector. Notion AI, from what I’ve seen, runs the opposite play: per‑feature model assignment, invisible to the user. Different products, same primitive underneath.

This layer matters more every quarter because the gap between cheap and expensive is widening, not shrinking. A year ago, the difference between Haiku and Sonnet was meaningful but not wild. Today the cheap tier covers far more tasks, while the expensive tier is reaching for things (long agentic loops, complex tool use) the cheap tier can’t touch. A single‑model app pays ceiling prices for floor‑level work.

Layer 3: the fallback — when the chosen model fails, try a different one

This is the layer teams discover the hard way, usually on a Friday night. When your pick is down, rate‑limited, or returning junk, you need a Plan B.

A fallback layer does three things:

1. Detects failure — not just HTTP errors, but quality failures (empty responses, refusals, malformed JSON)
2. Reroutes to a different provider with an equivalent capability
3. Logs the failure so you can learn what broke

The reroute isn’t the hard part. Portability is. Anthropic’s tool‑use schema isn’t OpenAI’s function calling. A prompt that yields clean structured output on Sonnet often needs tweaks for GPT‑4o, and vice versa. If you don’t have a prompt abstraction that compiles to each provider’s format, your “fallback” is pretend — you’ve got a second provider you can’t actually call.

This is where Linear‑style discipline pays off. Linear reportedly runs AI summarization on cheaper models with deterministic prompts and tight schemas. That discipline makes fallback real. Sloppy, model‑specific prompts make multi‑provider routing a maintenance nightmare.

What this looks like in code, roughly

Implementation will vary, but the shape is small:

• A Router that takes a request and returns a RoutingDecision { classifier_label, primary_model, fallback_model, max_cost_cents }
• A ModelClient with one method complete(prompt, schema, model) that compiles to the target provider
• A config file — yaml/json — mapping labels to tiers, owned by product, not just engineering
• Logging that records which model handled which request, cost, and whether the user accepted or corrected the output

A senior engineer can build v1 in a week. v2, with real evals on each route, takes a quarter. v3, where the router learns from outcomes, takes longer — and that’s where the moat forms.

The 2027 prediction, stated plainly

By 2027, vertical AI apps without a router will lose three ways at once: paying frontier prices for floor‑level tasks, going dark when their one provider has a bad week, and slipping on quality every time a competitor drops a better model in one of their categories.

The winners will look boring from the outside. A request comes in. A small model labels it. A config‑driven selector picks a tier. A prompt compiler emits the right format. A fallback waits. It’s observable, swappable, and gets cheaper every quarter as the cheap tier improves.

Not exciting. Just correct. The teams that build this now will spend 2027 shipping while everyone else is stuck migrating.

What to do this week

Pick one feature that hits a frontier model on every request. Put a classifier in front — even a crude one, even regex or embedding similarity. Route the easy 50% to a cheap model. Measure the quality delta. If it’s acceptable (it usually is), you just cut that feature’s inference cost by 60–80% in an afternoon.

That’s the smallest version of the pattern. Ship it. Do it again next week. By quarter’s end you’ll have a routing layer — and you won’t remember living without it.