pi-jev-router
A Pareto-optimal OpenRouter router for Pi, decided by Jev.
Philipp Dubach’s router asks Jev what a task needs, then picks the cheapest OpenRouter model on the quality-and-price frontier that meets it.
# pi-jev-router: a minimal Pareto-optimal OpenRouter model router for pi, based on Jev
pi-jev-router is a pi extension. It classifies each task with Jev (TypeSafe
System One, called through OpenRouter) and routes the task to an OpenRouter
model. The pick balances quality, cost and latency, and follows a role
policy for planning, code and writing.
The default mode is shadow: the router records what it would pick and does
not switch. Use `/router auto` or `/router auto --dry-run N` to let it switch.
## How a pick is made
1. **Continuation check.** A bare continuation ("continue", "go on", "keep
going", "yes", "ok", "do it", …) keeps the current model and skips Jev.
A continuation after an abstain or a manual pin classifies normally.
2. **Classification.** One Jev call per task, with a bounded context block
from the session and the repository. Five questions: category,
complexity, risk, brief and decompose. The categories include `planning`
and `writing`, so prose and planning tasks do not route as code.
3. **Work kind.** The category and a few text rules map the task to
planning, code, writing or other. A short continuation that Jev calls
`unclear` inherits the previous work kind.
4. **Abstain.** If Jev is confident (0.7 or more) that the brief needs
clarification, the router does not switch. The current model asks.
5. **Eligibility.** Hard gates remove infeasible models: no tool support,
context too small, a zero or sentinel price, an expired preview, a
measured pass rate under the quality floor (0.65), and, for risk 2 or
higher, fewer than three measured runs. Then the role policy applies
(see below). If nothing is left, the gates relax in a fixed order and
the ledger records which one relaxed.
6. **Frontier and pick.** The rou