Jev Router in Claude Code: does picking a model per task really save tokens? 6 tests with and without Jev

Jev Router promises to save tokens in Claude Code by picking a different model for each task: a cheap one for trivial edits, a powerful one for work that needs reasoning. The idea makes sense, but the savings are not guaranteed: the router adds a decision to every message, and a cheap model that gets it wrong needs fixing. To find out whether it pays off, I compared Claude Code with Opus 5.5 against Claude Code with Jev Router across 6 tests, measuring the cost of the same task with and without Jev.

What is Jev and how do you use it inside Claude Code?

Jev is a model from TypeSafe AI built to make fast, structured decisions that software can use directly. Jev does not write code and does not chat: it reads a situation and returns a choice.

There are several ways to use Jev inside Claude Code. One of the most popular is letting Jev pick the model based on the task you are giving Claude Code.

How does model routing with Jev work?

The principle is simple:

• if you ask Claude Code to change the color of a button on your web page, Jev points to a cheaper model;
• if the task is complex and needs reasoning and planning, Jev points to a more powerful model.

There are several implementations of this technique. One of the most popular on GitHub is Jev Router, an open source project that does exactly this. Jev Router runs on your machine as a proxy between Claude Code and the model APIs. On every new message it asks Jev what tier the task needs and forwards the request to Haiku, Sonnet or Opus.

One design detail says a lot: in Jev Router the model is chosen once for every new message, and it stays the same while Claude Code works on that message. When Jev is not confident about its choice, Jev Router never drops to a cheaper model. Its author chose to stop Claude Code from jumping between models halfway through a job.

Why might Jev Router fail to save tokens?

The question is fair: does this technique really save tokens, or do you risk burning even more?

There are two reasons the math is not a given:

1. Every message goes through one extra decision. Before any work starts, Jev Router queries Jev. The call is small, but it adds up over a whole session.
2. A cheap model can cost more when it gets things wrong. If Haiku does not solve the task on the first try, the retries and the fix by a stronger model eat the tokens the router meant to save.

That is why the only serious way to answer is to measure: the same task, run with and without Jev, with the costs side by side.

How did I test Claude Code with and without Jev Router?

I ran 6 tests comparing Claude Code with Opus 5.5 and Claude Code with Jev Router. For each test I measured the cost of the same task in both setups. The full experiment, with results test by test, is in the long video on my YouTube channel.

The same logic applies to any cost-saving strategy: splitting light work from heavy work only pays off if you check it against the numbers. I did the same with Grok 4.5 in Cursor, separating planning from execution.

Is Jev Router worth using with Claude Code?

Automatic model routing is a good idea on paper. The real savings depend on the tasks you run every day and on how often the cheap model needs correcting. Before you put a router on your subscription, measure the cost of your typical tasks with and without it: that number is the only one that tells you whether Jev Router is working for you.