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 only while provider, endpoint, host model and outgoing request model remain unchanged. A mismatch disables routing for the rest of that turn, including an A → B → A return, without buying another classifier answer. If the first outgoing model disagrees with host metadata, retain the outgoing request and do not classify; equivalent provider prefixes are normalized. The next turn resets the decision. Endpoint bindings stay in memory and are not written to telemetry. 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.