The blind spot every LLM router shares Every LLM router on the market looks at the prompt and predicts which model will handle it. Not Diamond trains a meta-classifier on your traffic and returns a recommendation. Martian does similar. OpenRouter and Portkey leave the prediction to your fallback config. Hand-rolled routers use regex or keyword rules. Different implementations, identical shape: read the input, guess the model, ship the answer the guess produced. When the guess is right, you save money. When the guess is wrong, the user eats a bad response. The router never finds out. That is dead-reckoning. You hold a heading, you assume the wind, you commit. If the wind shifts you arrive somewhere else. There is no instrument that tells you whether you arrived where you intended. What "verifier-gated cascade" changes The architectural shift is one extra step: read the cheap-model answer before you ship it. The pre-classifier reads the prompt. Confident cheap routes ship from Haiku immediately. That covers most traffic, under 10 ms overhead. Borderline prompts get the Haiku answer scored by a calibrated verifier. If the verifier accepts (score above tau), ship the cheap answer. If the verifier rejects, escalate to Sonnet, or to Opus on Sonnet rejection. The verifier never sees the Opus output. Its only job is deciding whether the cheap answer is good enough to leave alone. That is a much smaller, much more tractable scoring problem than predicting model fit from the prompt alone, and it generalizes better off-distribution. On 11,420 RouterBench held-out triples, verifier AUROC is 0.961 and calibration ECE is 0.016. The verifier knows what it knows. Predicted vs verified: same cost, different failure mode Run a prompt-only classifier and a verifier-gated cascade on the same held-out split at matched cost: | Strategy | Cost (x) | Catastrophic | Quality preserved | |---|---:|---:|---:| | Always-Opus | 12.0x | 0% | 100% | | Prompt-only classifier | 4.8x | 3.4% | 96.6% | | Verifier-gated cascade | 4.7x | 1.7% | 98.3% | | Always-Haiku | 1.0x | 26.0% | 74.0% | Same cost. Half the quality drops. The mechanism that produces the gap is the verification step. Reading the cheap-model answer turns "we predicted this prompt was easy" into "we predicted this prompt was easy and the cheap model in fact produced a passing answer." Different claim, different reliability. A prompt-only router maxes out at the ceiling of how well any model can predict outcome from input alone. That ceiling sits around 96-97% on RouterBench-class evals. The verifier breaks the ceiling because it reads the output, not the input. Why this is the architectural wedge The competing router products lead with cost. So do we, eventually. But the buyer concern that actually blocks the purchase is quality: "If I switch, will my users get worse answers?" A router that predicts model fit cannot answer this honestly. It can show eval results and cross its fingers that your traffic looks like its eval. The verifier-gated cascade can: the verifier is in the loop on every borderline request, so quality drops are caught and surfaced, not absorbed silently. Lead with quality preservation, not cost. ND and Martian lead with cost. The wedge for the buyer is "I will not be punished for switching." Once they trust the quality story, the 60% cost number lands. The tradeoff, said honestly The verifier adds 180 ms when it runs. Most requests skip it because the pre-classifier is confident, so the average added latency is much smaller, but the borderline path pays this cost. We think 180 ms on the slow path to avoid shipping a bad Haiku answer is the right tradeoff for production LLM workloads. If your application is in a tight loop where 180 ms is the difference between viable and not, you are probably better served by always-Haiku with manual escalation rules, and you should not be reading this post. The verifier is also currently trained on RouterBench-derived signal. RouterBench covers a wide distribution of public LLM tasks, but it is not your traffic. If your prompt distribution is meaningfully different (deep agentic, narrow vertical, heavily multilingual), the verifier may need on-distribution calibration. The OCR closed loop in production is already wired to do this from your live response signal. What we are publishing next A direct head-to-head against notdiamond-0001 on the same RouterBench held-out split. Both routers, same triples, same metric. Until that artifact is public, we will say "the closest competitor on routing claims" and let the architectural difference do the rest of the work. After it is public, we will lead with the head-to-head number. How to try it Two-line change. Swap your base URL to https://api.getnadir.com. Set model="auto". BYOK on every tier including Free. The verifier ships with the image; the version is stamped on every response as x-nadir-classifier-sha. The eval JSONs that produce the numbers in this post are in the public repo. You do not have to pick the threshold. The production cascade ships with a sane default. You can read the full threshold sweep in the RouterBench cascade benchmark.