Blog
Keyword routing vs classifier routing, and why the afternoon-script approach stalls
Everyone is converging on the same pattern: expensive model for the hard part, cheap model for the rest. The naive way to automate that decision caps out fast. Here's why, and what actually works.
July 9, 2026 · 6 min read
A pattern has quietly become the default on every team shipping AI-assisted work: use the expensive model for the genuinely hard step, and a much cheaper one for everything else. Plan with a frontier model, implement with a cheap one. It works, and the savings are real, a good cost-effective model runs close to an order of magnitude cheaper per token than a top tier one while landing near it on public coding benchmarks. The hard part isn't believing the pattern. The hard part is automating the decision, per request, without a human in the loop.
The first thing everyone reaches for: keyword routing
The obvious automation is a small hook: scan the prompt for keywords, map them to a model. If the prompt says "architecture" or "design", send it to the premium model; otherwise send it to the cheap one. It takes an afternoon to write, and for a while it feels like it works. Plenty of teams have exactly this running right now, wired into whatever editor or CLI they already use.
Then it starts missing. "Fix this" turns out to be a subtle concurrency bug that needed the premium model, and it went to the cheap tier because no scary word appeared. "Explain the design of this loop" was trivial, and it burned premium tokens because "design" was in the string. The keyword list grows, the exceptions grow faster, and you end up maintaining a brittle dictionary that still routes on the presence of words rather than the difficulty of the task.
Why it stalls: keywords are not complexity
The reason keyword routing plateaus is structural, not a matter of a better word list. The thing you actually want to estimate is how hard this request is, and that lives in the task, not in any specific token. Two prompts with identical vocabulary can differ by an order of magnitude in difficulty. A keyword rule cannot see that, because it never models the task, it matches strings. In our testing, prompt-keyword routing lands around a third accurate at picking the right tier. That is not a tuning problem you can escape by adding rules, it is the ceiling of the approach.
What works: a classifier that scores the request
The alternative is to route on a trained classifier that reads the whole request and predicts its complexity and intent, then sends it to the cheapest tier that can actually handle it. Same input, a completely different basis for the decision: estimated difficulty instead of matched words. In our testing that moves tier-selection accuracy from roughly a third to the mid-nineties. It also degrades gracefully, on a low-confidence call it escalates a tier rather than gambling on the cheap one, which is the opposite of what a keyword rule does when it simply finds no match.
This is the layer RemKey runs on every request. You send one request with
model: "auto", and the classifier makes the tier decision that a keyword hook only
approximates, with no dictionary for you to maintain.
Two honest caveats
First, a classifier that says it downrouted correctly is still just a claim until something checks it. That's why we verify a sample of downroutes against the premium baseline and publish a quality-hold number instead of asking you to trust the router, covered in a separate post.
Second, the cheapest capable models you most want to route to are frequently the ones a security team most wants to inspect, several of the strongest low-cost open models are developed in high risk jurisdictions. Routing you to the cheap model is only useful if you can also see and govern what you routed to, which is why every model in our catalog carries its origin. Picking the cheap model and governing the choice are the same decision, made once.