He pulls one lever. Your task rides the right track.
A Claude Code mod that asks TypeSafe Jev which Claude model and effort each task needs.
Rename a variable on Haiku. Redesign the queue on Opus. Never pay castle prices for a hut.
You know the problem. You rename one variable and your most expensive model thinks about it for a minute. Or you start a gnarly refactor and a bargain model happily shrugs.
jev-router puts a switchman in front of your session. Before every task he reads it, asks Jev, pulls the lever, and the turn runs on the model and reasoning effort that fit. He is smug about it. You will see.
A live band above your prompt shows what he picked. Colour coded, with a spinner while a task runs.
| Part | Meaning |
|---|---|
balanced |
Routing mode: efficient, balanced or cheap |
sonnet ▂▄__ |
The model the task runs on, with its tier. Green haiku, blue sonnet, purple opus, gold fable |
medium ▰▰▱▱▱ |
Reasoning effort, low to max |
conf ▮▮▮▮▯ 88% |
How sure Jev is. Green from 70%, amber from 50%, red below |
cache 🔒 warm 42k |
Whether the prompt cache is still worth protecting, and how big it is |
When the cache wins, the band says so: opus (kept 🔒 cache warm; wanted haiku).
- Picks the model and the effort, before every task, from haiku, sonnet, opus and fable. You can narrow the pool.
- Three routing modes.
efficientfor the best result,balancedfor quality and cost evenly,cheapfor the cheapest model that can plausibly succeed. - Guards the prompt cache. Switching models throws the cache away. While it is warm and big enough to matter, he stays put unless Jev confidently asks for something stronger.
- Caps the effort. Jev's effort pick is limited to
highby default, because effort drives token use far more than the model does. Start a prompt with!full(or run/jev full) to lift the cap for that one prompt. - Never blocks you. Jev slow or down? The session model keeps working.
- Routes every step. Before each step after the first, Jev is asked again, so a task that turned out easier or harder moves to a fitting model (the cache guard still applies). Turn it off with
routeSteps. - Routes subagents. Each subagent gets its own model and effort, picked once from what its Agent call says it is for. Turn it off with
routeSubagents. - Keeps score.
/jev statusshows how often each model was used this session.
Two benchmarks. First, 30 single-prompt tasks: 270 calls to Jev for the picks, then 147 real runs for token usage and cost, with the effort cap at its default (high) and uncapped. Second, 6 multi-step tasks with tools on a fixture repo, 72 real runs, checking per prompt against every-step-and-subagent routing.
| Cost vs always opus (no plugin) | efficient | balanced | cheap |
|---|---|---|---|
| Trivial tasks | -97% | -97% | -97% |
| Standard tasks | -65% | -65% | -68% |
| Hard tasks, cap high (default) | +43% | +24% | -56% |
| Hard tasks, uncapped | +242% | +207% | -39% |
| All 30, cap high (default) | -1% | -13% | -64% |
| All 30, uncapped | +123% | +101% | -53% |
The honest read: the model switch saves a lot on easy and mid tasks, and the default cap of high brings every mode to or below always-opus overall. Hard tasks still cost 24% to 43% more in efficient and balanced, because Jev picks opus there and asks for deeper reasoning. !full lifts the cap for one prompt when you want that. The cap changes tokens spent, not answer quality, and that is not measured.
| 6 tasks × 3 runs, real runs with tools | tasks done | cost | vs always opus | vs always sonnet |
|---|---|---|---|---|
| no plugin: always opus | 18/18 | $2.46 | ||
| no plugin: always sonnet | 18/18 | $1.29 | -48% | |
| jev-router, per prompt | 18/18 | $1.27 | -48% | -2% |
| jev-router, every step + subagents | 18/18 | $1.15 | -53% | -11% |
Routing every step and subagent saved 11% on top of per-prompt routing. Most of that comes from one task: asked to use a subagent, it paired a sonnet main thread with a haiku subagent where per-prompt routing sometimes left the subagent on opus. On the other five tasks it matched per-prompt routing. Honest limits: these are easy tasks on a small repo, three runs each, and every strategy finished all of them, so this shows nothing was lost here, not that nothing is lost on hard work. Jev picked sonnet for nearly every one of these tasks, so against always-sonnet the gain is small.
Without the cache guard, following every pick in a long warm session cost 3x more than just using opus. Inside one long warm session the guard keeps you on the first model, so the savings above show up mostly when the cache is cold or the context is small. Method, per-tier tables and all caveats: benchmarks/.
Per prompt, the mod sends Jev the routing mode, the current model, the cache state, the last few messages and the task text, and asks two choice questions: which model, and how much effort. The answer is applied to every step of that task. After each step the mod notes which model the API cached and how many tokens, so the next task knows whether a switch is worth losing the cache.
Sent to api.typesafe.ai: the task text, recent conversation, and subagent descriptions. Each step and subagent adds one call (about 250 ms). Your API key travels in the request header and nowhere else.
Needs a Claude Code version with mods (hooks modules) and a TypeSafe API key.
/plugin marketplace add dominicrico/jev-router
/plugin install jev-router@jev-router
Update:
claude plugin marketplace update jev-router
claude plugin update jev-router@jev-router
Any one of these, checked in this order:
- The plugin option
apiKey(/config) /jev key <key>, stored by the mod across sessions (/jev key clearremoves it)- The
TYPESAFE_API_KEYenvironment variable
That was it. He'd be proud. He won't say it.
| Command | What it does |
|---|---|
/jev or /jev status |
Settings, cache state, last decision and per-model usage |
/jev efficient | balanced | cheap |
Set the routing mode, from the next task |
/jev sticky off | auto | strict |
Set cache stickiness |
/jev cap low | medium | high | xhigh | max | none |
Set the effort cap |
/jev full |
Lift the effort cap for the next prompt only |
/jev on / /jev off |
Enable routing / use the session model |
/jev key <key> |
Store the TypeSafe API key |
┌ Jev router ────────────────────────────┐
│ state ● on mode balanced │
│ pool haiku · sonnet · opus · fable │
│ sticky auto cache ● warm │
│ last sonnet / medium ▮▮▮▮▯ 0.88 │
│ usage haiku ░░░░░░░░░░ 0 0% │
│ sonnet ██████████ 1 100% │
│ opus ░░░░░░░░░░ 0 0% │
│ fable ░░░░░░░░░░ 0 0% │
│ key …fd1c (TYPESAFE_API_KEY) │
└────────────────────────────────────────┘
| Option | Default | Meaning |
|---|---|---|
mode |
balanced |
Routing mode |
models |
all four | Aliases Jev may choose from |
effortCap |
high |
Highest effort the router applies. none follows Jev. Per prompt: start with !full or run /jev full |
routeSteps |
true |
Ask Jev again before every step after the first. Off: one call per prompt |
routeSubagents |
true |
Pick a model and effort for each subagent from its description |
stickiness |
auto |
off: always follow Jev. auto: while the cache is warm, only upgrade on high confidence. strict: never switch while warm |
minConfidence |
0.7 |
Confidence needed for a warm-cache upgrade |
minContextTokens |
8000 |
Below this a switch is free and stickiness is skipped |
cacheTtlMs |
300000 |
Time after the last request when the cache counts as cold |
timeoutMs |
4000 |
Keep the current model when Jev takes longer |
Does it need a config file? No. Set a key, pick a mode, done. Everything else has a default.
Why not just always use the best model?
You can. /jev efficient and a pool of opus and fable. Your invoice will have opinions.
Why not just always use the cheap one?
/jev cheap. The hard task will have opinions.
He kept my old model even though Jev wanted a cheaper one. Is it broken? No. Your cache was warm and a switch would have rewritten it. He did the maths. He was right.
What if Jev is down? Then you get your session model and one polite toast. He never blocks a turn.
Why a raccoon? Because he is a small creature that gets very serious about picking the right track.
claude plugin validate .
claude plugin test .
Benchmarks: see benchmarks/.
MIT.