"Jev Claude Code router" means two different things, and confusing them wastes real setup time. Model routing is grading how hard a request is and sending it to a cheaper or stronger model accordingly. Skill-list routing is cutting down the list of skill descriptions Claude Code loads into context on every turn. They solve different problems, and as of this writing, they have very different track records. One has a published, checkable methodology that works. The other was tried by its own author and walked back, in writing, in favor of a setting Claude Code already ships.
The framing that applies to everything below, repeated because it matters here specifically: Jev is not a replacement coding LLM, and it does not power Claude Code. It's a narrow decision layer some of these tools call mid-turn. Claude Code's own model still writes every line of code, whichever model gets picked or whichever skills get shown to it.
Key Takeaways- "Router" means two different things: sending a request to a cheaper or stronger model (model routing), or cutting the skill descriptions loaded into context (skill-list routing).- Model-routing savings figures circulating right now are self-reported by the projects publishing them, not independently verified; treat "30-50%" and "60%" claims as vendor or author estimates, not measured facts.- One skill-list routing project has a real, checkable published eval: a 75% token cut with a higher accuracy score than a non-Jev baseline, on the project's own test set.- A second skill-list routing project tried the same idea, walked it back in its own README, and now recommends Claude Code's built-in `skillOverrides` setting instead.- Insight: The project that walked back its own idea is more useful to read than most of the ones claiming success. An author publishing "this didn't work, use the built-in setting instead" is rarer than a launch post, and it's exactly the kind of source that keeps you from rebuilding something Claude Code already does.- A Jev-free, embedding-based router exists for the skill-list problem and reports similar-magnitude savings without calling Jev at all.
Key Takeaways
- "Router" means two different things: sending a request to a cheaper or stronger model (model routing), or cutting the skill descriptions loaded into context (skill-list routing).
- Model-routing savings figures circulating right now are self-reported by the projects publishing them, not independently verified; treat "30-50%" and "60%" claims as vendor or author estimates, not measured facts.
- One skill-list routing project has a real, checkable published eval: a 75% token cut with a higher accuracy score than a non-Jev baseline, on the project's own test set.
- A second skill-list routing project tried the same idea, walked it back in its own README, and now recommends Claude Code's built-in `skillOverrides` setting instead.
- Insight: The project that walked back its own idea is more useful to read than most of the ones claiming success. An author publishing "this didn't work, use the built-in setting instead" is rarer than a launch post, and it's exactly the kind of source that keeps you from rebuilding something Claude Code already does.
- A Jev-free, embedding-based router exists for the skill-list problem and reports similar-magnitude savings without calling Jev at all.
Model routing decides which model handles a request. Skill-list routing decides which skill descriptions the model even sees before it starts. Both get called "routing" and both get pitched as Jev use cases, but they touch completely different parts of a Claude Code session, and the evidence for each is not remotely at the same stage.
By scoring how hard a request looks before it runs, then sending it to a model sized to match. `jev-router` (github.com/gargpratyush/jev-router) is the clearest example. It supports both Claude Code, via a `jev-claude` command, and Codex, via `jev-codex`. It also ships a `/jev-explain` skill that shows the factors behind a routing decision. It adds a statusline showing the live decision, something like "haiku p=0.98, my-project, 8% context," visible on every turn. Setup is a global npm install plus an API key in an env file, then launching `jev-claude` instead of `claude` directly.
What it doesn't ship is an independently verified savings number. Coverage of the project (emergent.sh, September 2026) reports a vendor-claimed 30-50% cost reduction and a roughly 50-100 millisecond latency overhead per routed request. Those are the project's own reported figures, not something Maxpertise has tested or can vouch for; treat them as a starting estimate to validate against your own workload, not a guarantee.
A second project, `jev-codex-router` (0xNatoshi, listed on aiskill.market), is worth citing specifically for how it handles its own number. Its backtest reports roughly 60% lower list-price cost, computed from 237 turns in a single person's seven-day session replay, totaling $0.69 in combined Jev list-price estimates and OpenRouter-reported charges. The project's own page states this plainly: it's "a list-price estimate from one person's session replay, not independently retested by this site," and it excludes host inference, funding fees, and taxes entirely, meaning it isn't a real bill either. That's a more honest framing than most launch posts offer, and it's worth reading precisely because of the caveat, not despite it.
Installation is a global npm install, per the project's own README, followed by adding your Jev API key to its env file and launching `jev-claude` in place of `claude` for the session you want routed. Don't replace your `claude` alias on day one. Keep both commands available side by side, and use `jev-claude` deliberately for a batch of real tasks, so a routing mistake doesn't take over every session you run before you've seen how it behaves.
The `/jev-explain` skill is the fastest way to check a specific decision. It lists the factors behind that one routing choice on demand, so you can spot-check a call you disagree with instead of reading back through a whole session's transcript. The statusline is a second, passive signal, showing something like "haiku p=0.98, my-project, 8% context" on every turn. If you notice the router consistently picking the cheapest model on requests you already know are hard, that's a reason to lower your trust in it before it costs you a redo, not after. Only fold `jev-claude` into your default workflow, aliasing over `claude` itself, once you've watched it make calls you'd have made yourself across a range of request types, not just the easy ones.
It depends entirely on which project you're looking at, and the two clearest examples point in opposite directions.
`jev-skill-gate` (github.com/ShivamPansuriya/jev-skill-gate) works, with numbers you can check yourself. It scores every installed skill for relevance to the current request and hides the rest using Claude Code's own `skillOverrides` mechanism. On a 217-skill installation, its published eval cuts the skill manifest from 12,750 tokens to 3,185, a 75% reduction, at roughly $0.0009 in Jev API cost for a session. The same eval reports a mean pairwise AUC of 1.000 for Jev against 0.948 for a local TF-IDF baseline scorer on matched test cases. On those cases, Jev hid zero skills the eval expected to be kept, against one for the TF-IDF approach. That's a real, checkable methodology behind the number, not just a headline claim, and it's the project's own published result, not something Maxpertise re-ran.
`jev-skill-router` (github.com/shimo4228/jev-skill-router) tried the adjacent idea and reversed course, in writing. Its own README states the limitation directly: a `UserPromptSubmit` hook "can add text to a turn, or block the prompt, but it cannot change the skill listing," in the README's own words. As a result, "the tokens spent on the skill listing do not go down by one," the README states plainly. The project's companion writeup (zenn.dev/shimo4228/articles/jev-retrofit-limits, September 21, 2026) goes further, recommending Claude Code's own built-in `skillOverrides` setting instead of adding Jev for this specific job. Testing on the author's own sessions found the approach reached only 50% accuracy on the follow-up, conversational prompts that make up most real sessions, performing meaningfully better only on the first, single-intent request of a session. The project is published as a reference and a measurement exercise, not as something the author recommends running in production.
The difference between these two isn't Jev being good or bad. `jev-skill-gate` changes what the model actually sees, via `skillOverrides`, before the turn starts. `jev-skill-router`, by its own account, only touches the prompt text, which is a different lever that doesn't move the number that matters.
Start by checking what `skillOverrides` is already set to. `off` means every skill description loads into context on every turn, regardless of relevance. `on` or `name-only` narrows what loads without any Jev call involved at all. `user-invocable-only` narrows further, to skills you have to ask for by name. If your skill count is small, under a few dozen, a static setting here often solves the whole problem for free, with no per-request model to run and no API cost added.
Only move to `jev-skill-gate`'s relevance-scoring approach once you've confirmed a static configuration doesn't generalize. Watch a week of real requests and note when the model reaches for a skill that wasn't visible because a static setting hid it. Treat repeated misses, not a single one, as the signal that per-request scoring is worth its cost. `jev-skill-gate`'s own reported $0.0009-per-session figure only makes sense to pay if the static alternative is actually failing you on your own traffic, not because a per-request approach sounds more sophisticated on paper.
Not necessarily, for the skill-list problem specifically. A Jev-free, embedding-based approach exists and reports comparable-magnitude results. An article on semantic routing for Claude Code skills (hackernoon.com, May 26, 2026) describes an approach that separates skill metadata into an embedding index, rather than loading every name and description into the system prompt upfront. It reports roughly a 456x context-window reduction, from about 228,000 tokens down to about 2,000 for each task turn, with the right skill landing in the top five candidates seven times out of eight. No Jev call is involved anywhere in that approach. If your actual problem is "the skill manifest eats too much context," it's worth knowing a non-Jev solution exists and has its own reported numbers before you add a new API dependency to solve it.
For model routing, there's no documented native Claude Code alternative as of this writing. If request-complexity-based model selection is the problem you have, a Jev-based router is one of the few options that exists. The caveat: its savings claims are self-reported, and worth validating on your own traffic before you trust them for budgeting.
For skill-list routing, start with what Claude Code already ships. `skillOverrides` is the built-in setting (`on`, `name-only`, `user-invocable-only`, `off`) that `jev-skill-gate` itself routes through, and it's also what `jev-skill-router`'s own author recommends after trying the alternative. If a static configuration already gets you most of the way, you may not need Jev, or any router, running per-request at all. Add `jev-skill-gate`'s relevance-scoring approach specifically if your skill count is large enough, and varied enough, that a fixed configuration doesn't generalize across the requests you actually get.
By measuring your own before-and-after numbers, not by trusting a project's headline figure. The self-reported numbers above come from other people's traffic, on other people's tasks, and neither project claims otherwise. Before adopting either kind of router:
Two different things, depending on the source. It can mean routing a request to a different model based on how complex it looks, or it can mean routing which skill descriptions get loaded into context for that turn. Check which problem a given tool is solving before assuming it addresses yours.
No, not independently. The figures circulating (30-50% from one project's coverage, 60% from another's self-reported backtest) come from the projects themselves or press coverage of them. The more careful project explicitly labels its own number a list-price estimate from a single session replay, not a verified reduction in an actual bill.
Sometimes, depending on the implementation. One project (`jev-skill-gate`) has a published eval showing a real 75% token reduction with better accuracy than a non-Jev baseline. A different project tried a similar idea and found, in its own testing, that it doesn't reduce the token count at all, because a prompt-level hook can't change what Claude Code actually loads.
No. A Jev-free semantic router built on embeddings exists for exactly this problem and reports similar-magnitude savings in skill-list tokens without calling Jev. Whether you need Jev specifically depends on whether you want relevance scoring on each request or a static embedding index is enough for your skill set.
Different problem entirely. Routing decides which model or which skills apply to a turn. Compaction decides what to do with a conversation's history once it grows large. See do you need fast-jev-compaction, or is /compact enough for that separate comparison.
For the official, stable way to get Claude Code writing correct Jev integrations in the first place, see how to use Jev with Claude Code. For the same official-versus-experimental distinction applied to OpenCode instead, see how to use Jev with OpenCode.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.