Two "auto routers" that solve different problems
Type model="auto" into an API call today and it can land in two very different places. On OpenRouter, openrouter/auto hands the prompt to a third-party router, NotDiamond, which picks from a rotating pool of models against a single 0-10 cost_quality_tradeoff slider, default 7. Source: OpenRouter, "How OpenRouter Model Routing Works: Providers, Fallbacks & Auto Router". On Nadir, model="auto" hands the prompt to a router Nadir trained itself, backed by a verifier that scores the cheap model's actual answer before deciding whether to escalate. Same three letters. Different products underneath.
Both companies call themselves routers. Only one of them built per-request model selection as its entire reason to exist; for the other, it's one mode inside a much bigger access-and-reliability product. This is the honest comparison: what each one actually is, how each one prices itself, and which problem you actually have.
What OpenRouter is
OpenRouter is a unified API and model marketplace: one endpoint, one API key, and 60+ inference providers supported for bring-your-own-key setups, including OpenAI, Azure, AWS Bedrock, and Google Vertex. Source: OpenRouter Docs, "FAQ". The default behavior most teams reach for is choosing a model themselves, then letting OpenRouter run two separate reliability layers underneath that choice. Provider routing picks among providers serving the same model, deprioritizing recent outages and weighting toward cheaper providers by default, or forced explicitly via :nitro for throughput and :floor for cost. Model fallbacks are an opt-in ordered list OpenRouter cascades through if the primary model errors, hits a context-length limit, or gets rate-limited. Source: OpenRouter, "How OpenRouter Model Routing Works: Providers, Fallbacks & Auto Router"; Source: OpenRouter, "OpenRouter Failover: Provider Failover vs Model Fallbacks Explained". You're billed for whichever model actually answered, not the ones that failed first.
The one mode that does automatic per-prompt model selection is openrouter/auto, and OpenRouter is explicit that it isn't OpenRouter's own routing brain: it's "powered by NotDiamond," the same third-party predictive router this blog has named before as one of several that ship no verification step, evaluating each prompt and choosing from a pool of capable models against that single cost-quality slider. Source: OpenRouter, "How OpenRouter Model Routing Works". It's a real, usable feature. It's also one option among hundreds in a marketplace whose core product is access and uptime, not a decision that gets checked against the answer it actually produced.
OpenRouter's own growth reflects what it's built for: it raised $113M at a $1.3B valuation in the same 30-day funding window that saw DeepInfra and Portkey pull in similarly large checks, on the pitch that the access layer between an app and every model provider is now mandatory infrastructure. Mandatory access infrastructure and mandatory decision infrastructure are both real categories. They aren't the same category.
What Nadir is
Nadir is an auditable decision layer that can run beside an existing gateway or execute through an OpenAI-compatible proxy. Start in shadow mode: the caller's requested model keeps serving while Nadir records the governed model-and-effort counterfactual. Complete non-streaming proxy responses can optionally enter a reference-free verifier cascade; streaming bypasses it.
from openai import OpenAI
client = OpenAI(base_url="https://api.getnadir.com/v1", api_key="YOUR_NADIR_KEY")
resp = client.chat.completions.create(
model="auto", # scored and routed; complete-response verification is optional
messages=[{"role": "user", "content": "Summarize this contract clause..."}],
)In a reference-assisted RouterBench research experiment on 11,420 triples, that architecture projected 60% lower cost at about 98% retained quality. The verifier had the expensive reference answer unavailable in production, so this is a research ceiling. Nadir's production wedge is the auditable decision receipt, shadow-to-enforce workflow, optional execution, and self-hosted delivery.
The fee model is the actual tell
Here's the difference that shows up on an invoice regardless of which router made the better call. OpenRouter charges to move money onto its platform: a 5.5% fee, $0.80 minimum, on Stripe credit purchases, or 5% via crypto, plus a 5% fee on BYOK requests once you clear the first 1 million free ones each month. Source: OpenRouter Docs, "FAQ". Both fees apply the same way whether or not the request that just ran needed the model it got routed to. They're a toll on volume.
Nadir has no base fee. Credits for Nadir-managed keys draw down at provider list price, and a 5.5% platform fee (8% on Business) is added when you buy them, the same rate as OpenRouter's. On your own keys, your provider bills you directly and Nadir adds no fee. What routing saves carries no fee either.
| OpenRouter | Nadir | |
|---|---|---|
| Core product | Unified API + model marketplace across 60+ providers | Managed per-request decision layer |
| Default model selection | You choose the model, or a static fallback list | Router scores and picks per request |
| Automatic per-prompt routing | Opt-in openrouter/auto, powered by NotDiamond, single cost/quality slider | Default behavior, first-party router plus verifier |
| Complete-response verification | Not part of the stated design | Optional for eligible non-streaming managed-proxy calls |
| Provider-level reliability | Automatic failover across providers for the same model | Fallback chains across models and providers |
| Pricing | 5.5% credit-purchase fee ($0.80 min); 5% BYOK fee above 1M free requests/month | No base fee; 5.5% on credit purchases; no fee on own keys |
| Pay if it doesn't help you | Yes, the access fee applies regardless of outcome | Only the credit platform fee; own keys and routing savings carry no fee |
| Source-available / self-host | Not applicable, hosted only | Routing core self-hostable, PolyForm Noncommercial |
| Published quality result | Not the product's stated focus | Reference-assisted 60% / 98% RouterBench research ceiling; not deployed performance |
Source: OpenRouter Docs, "FAQ"; Source: OpenRouter, "How OpenRouter Model Routing Works".
Two different jobs, not two rankings of the same job
If the problem in your head is "I need one key that reaches Claude, GPT, Gemini, and open-weight models without juggling five SDKs, and I need it to survive a provider outage," that's an access and reliability problem, and OpenRouter is built for exactly that, at real scale, with a funding round to prove the market agrees. Access to more models doesn't answer a different question, though: once you can reach every model, something still has to decide which one handles this specific request, and by default that's still you, writing a model string or a static fallback order into your code.
If the problem in your head is "I'm calling GPT-5.5 or Opus for requests a cheaper tier could have answered just as well," more access doesn't fix that. A bigger menu doesn't tell you what to order. Nadir starts by measuring that decision in shadow mode, then lets you enforce the routes whose executed economics and outcome labels clear your bar. Optional complete-response verification adds routing evidence on eligible proxy calls; it is not a universal quality guarantee.
Which one fits your team
- Choose OpenRouter if you need one integration across many providers and models, you want automatic provider-level failover when a specific provider goes down, and you're comfortable choosing, or statically ordering, which model handles which request yourself.
- Choose Nadir if you already know which providers you want to call and the actual problem is that every request pays the premium model's rate regardless of how hard it is, and you want that decision automated and checked, with no fee on what it saves you.
- Consider both if OpenRouter is already your access layer across providers. Nothing about that changes the fact that a request still needs a model chosen for it, and that's the layer Nadir sits at regardless of which gateway sits underneath.
Bottom line
OpenRouter and Nadir both put model="auto" in front of a request, but the adoption contract differs. OpenRouter is an access-and-execution product. Nadir can return an auditable model-and-effort receipt beside the gateway you already run, then optionally execute through Hosted Route after outcome-labelled shadow evidence clears the bar. Complete non-streaming proxy responses can enter the verifier; streaming bypasses it. If your problem is reaching more models reliably, that is OpenRouter's job. If your problem is proving which model and effort each task deserves, start free or read the complete guide to cutting LLM API costs.
Sources: [OpenRouter Docs, "FAQ"](https://openrouter.ai/docs/faq). [OpenRouter routing](https://openrouter.ai/blog/insights/model-routing/). Nadir's 60% / 98% figures are a reference-assisted research ceiling on 11,420 RouterBench triples; see [the corrected verifier piece](/blog/routing-without-verification-dead-reckoning).