/jev-model-routing

name: jev-model-routing
description: Use to pick the cheapest good-enough model or effort for a turn or a delegated task (lanes small to escalate), to decide continue/retry/verify/escalate/complete after each cycle, or to tune routing.
version: 0.2.0
license: MIT
metadata:
  hermes:
    tags: [jev, typesafe, model-routing, cost]

Model routing with Jev

Jev reads a turn and answers three questions in one ~0.4 s request: how hard is it, what kind of work is it, and would a mistake be costly. Code then walks your pool for that tier and specialty and takes the first model that fits (images, context size). You do not pick models by feel; you ask.

On Hermes it is automatic

With the `hermes-jev` plugin enabled, each fresh user turn is routed once, before the first model call. Tool-loop follow-ups reuse that decision. Switches, per profile:

/jev                    status
/jev routing shadow     decide and log, but do not switch (start here)
/jev routing on         switch models
/jev routing off
/jev notice on          show "[Jev] medium · coding → kimi-k2.7-code · confidence 0.97" on routed replies

A plugin can swap the model, not the provider connection. On OpenRouter that still means every vendor (DeepSeek, GLM, Kimi, MiniMax, Grok, Qwen, Gemini, GPT). If you run `/model` yourself, your choice wins and Jev stays out of the way.

For a Hermes `custom` provider, the plugin cannot infer the backing models.dev provider. It now keeps the current model and logs `custom provider needs an explicit provider_aliases.custom` instead of blaming an unrelated pool. If and only if that endpoint actually serves the pool's models, set `"provider_aliases": {"custom": "venice"}` (replace `venice` with the real pool prefix) in `routing.json`. Check the endpoint and every pool model before enabling routing; an alias is an operator assertion, not cross-provider discovery. This does not edit any live routing mode.

Asking directly (any agent)

Before delegating a task or spawning a sub-agent, ask which model should get it:

jev route --prompt "<the task, in the person's words>" --current "<provider:model you are on>"

Use `model_id` from the reply. `routed: false` means stay where you are; `reason` says why. Relay `notice` if the person likes to see routing.

Lanes: delegating a task, and every step after it

For work you hand to a sub-agent or worker, finish with the smallest model and lowest effort that still gets it right. Jev decides; it never writes code, patches or designs.

jev lane classify --task "<the work, in the person's words>"        # first lane + model/effort
jev lane step --task "..." --lane <lane> --attempt <n> \
    --run "<test cmd>" --run "<lint/typecheck cmd>" --scope "<path glob>"   # after each cycle

| Lane | Claude Code (subagent) | Hermes Kanban card (default map) | |---|---|---| | `small` | `jev-lane-small`: Haiku, low | `gpt-5.6-luna`, medium | | `medium` | `jev-lane-medium`: Sonnet, medium | `gpt-6-sol`, medium (today's default) | | `high` | `jev-lane-high`: Opus, medium | `gpt-6-sol`, medium | | `escalate` | `jev-lane-escalate`: Opus, high | `gpt-6-astra`, high |

`jev lane targets --host hermes` shows the map in force; `<hermes root>/jev/lanes.json` (or `~/.config/jev/lanes.json`) overrides any field. The Hermes map was calibrated on one fleet's own history (see `docs/lanes.md`); re-measure yours with `jev lane replay-build` / `replay-report`.

• **One request, all questions.** `classify` asks the lane (with an `other` escape: work a person should see first), security sensitivity and underspecification together. Code applies the thresholds: a `small` pick needs 0.7 confidence; a `medium` pick below 0.5 goes to `high`; security ≥ 0.7 is at least `high`. `keep_current` means keep the model you had (do it yourself, or ask).
• **Code first.** A model the person named, two failed attempts, or your own security-path check decide without asking Jev.
• **Deterministic checks first.** `step` runs the tests, compiler, type checker and linter you name and reads `git diff`. A failing check is `retry` (and `escalate` once the same lane failed twice); files outside `--scope` are `retry`; unrun checks are `verify`; security files changed on small/medium are `escalate`. Jev is asked only what is left: is it implemented, is it in scope, what next.
• **Escalate one lane at a time, on evidence only.** `escalate` from the top lane returns `person`.
• **Complete is earned.** `complete` is refused (becomes `verify`, with `complete_refused`) unless the checks ran and passed and the diff stayed in scope. Say when a check failed; never hide it.
• Only the tail of each long check output goes to Jev. Never compact or filter the agent's own reasoning.
• Jev down: `classify` keeps the current model, `step` says `verify`.
• **Make `--run` a script, not a one-liner.** It runs under a shell, so pipes and `&&` work, but the evidence prints the command cut short and a reader cannot tell what passed. A small script that checks the exact commit and each exit code, and prints `ok:`/`FAIL:` per gate, keeps the evidence legible. Make sure it reads only this cycle's results: an earlier failed attempt left in the same log will fail (or pass) the wrong run.
• **Read-only work: `--no-changes-expected`.** For a review or report, say so; otherwise an empty diff reads as nothing done.
• **`escalate` with a decision still open means `person`.** After a review whose facts are verified but which leaves the owner a choice (a risk to accept, an approach to pick), a stronger model cannot settle it. Put the decision to the person rather than re-running the work a lane up.

On Hermes, `jev lane shadow` (from cron) classifies new Kanban cards and logs what it would choose; `/jev lanes shadow|on|off` is the switch and `<hermes root>/jev/LANES_OFF` wins. `on` sets the card's model and effort before dispatch; turn it on only after `jev lane shadow-report` shows fewer tokens at the same