Jev Router vs Auto Router: Which OpenRouter Router Saves More?

OpenRouter's Auto Router classifies each prompt into one of about 30 fine-grained task types. For that task, it picks the models the OpenRouter community actually spends on over a trailing seven-day window. It routes on what the market pays for, and it follows migrations within days without retraining.

Jev Router asks TypeSafe's Jev decision model to judge the task type, its difficulty, the precision needed and how much a stronger model would help. It then picks the cheapest candidate that clears that bar, together with a reasoning effort. It is built to reason about the whole session, not each prompt in isolation.

Auto Router's cost_tier setting chooses a market band: low, medium, high, xhigh or max. With no setting, it routes roughly as low. A tier is a band, not a ceiling, so models cheaper than the band are excluded as well as pricier ones. Combine it with allowed_models, excluded_models and provider.max_price to cap spend.

Jev Router has no tier dial. You shape cost by narrowing the candidate pool with the jev-router plugin and by excluding premium families. If your lists leave too weak a tier for a hard request, the router uses the strongest tier left and reports list_tier_cap. That keeps the bill predictable at some cost to quality on the hardest turns.

For long agent sessions, the most expensive routing mistake is switching models. Each switch discards the provider's prompt cache, and the new model re-reads the conversation at full input price. Jev Router keeps a model that works, raises or lowers effort instead of switching, and switches only when the expected gain beats the cost of the lost cache.

Auto Router classifies prompt by prompt. That is fine for independent requests such as support answers, summaries or classification, where there is no long history to lose. For a 200,000-token coding session, every unnecessary switch costs about $0.80 of input on Claude Opus 5.5 or $0.40 on GPT-6.1 Sol.

Auto Router is designed never to fail because routing broke. If classification or rankings are unavailable, it degrades to a default model set. Jev Router fails the request if the Jev call times out or returns invalid output. It also fails with a 404 if your exclusions leave no eligible model.

Both behaviours have a price. Graceful degradation can quietly serve a model you did not plan for. Failing closed forces a retry path in your client. Choose deliberately, and include the retry or fallback model in your cost-per-task maths.

OpenRouter says Jev Router solved 237 of 423 tasks across four agent benchmarks, against 130 for Auto Router — 82% more. That is a meaningful vendor result for agentic work, which is where session-level routing should matter most.

It does not say which router is cheaper per completed task on your traffic, and it does not cover single-turn workloads. Enable router metadata with the X-OpenRouter-Metadata header on both and log the served model per request. Then compare cost per accepted outcome on a sample you have labelled yourself.

Use Auto Router with an explicit cost_tier for independent, high-volume prompts where market-proven models are good enough and a request must never fail on routing. Use Jev Router for coding agents, long research sessions and multi-step tool use, where effort control and cache retention drive the bill.

Use neither on OpenRouter's US or EU regional domains, where router models are not available. Keep a fixed model for any workload where reproducibility or a signed-off model list matters more than routing savings.

For Auto Router, set cost_tier explicitly rather than relying on the default, which routes roughly as low. Add excluded_models for any family your compliance team has not approved, and set provider.max_price to cap what any resolved endpoint may charge. You can save these as account defaults on the workspace routing page and enable the prevent-overrides toggle so individual requests cannot widen them.

For Jev Router, restrict the pool with the jev-router plugin. A common pattern includes one cheap family, one standard family and one heavy model you have priced, and excludes everything else. Log list_tier_cap to see how often your cap holds back a hard request. If capped requests fail more than they save, add one stronger model rather than removing the cap entirely.

In both cases, put routed traffic in its own workspace with a budget. That way a change in the router's choices shows up as a budget alert rather than a surprise on the monthly invoice.