Everyone Is Talking About Jev — Here Is What It Actually Changes in Hermes

If you have opened Hacker News or any AI newsletter in the last week, you have seen the word “Jev” a few dozen times. It is a model that does not write prose — it returns decisions with confidence scores — and the reaction has been split between “this is a new shape of LLM” and “this is a classifier with good marketing”. Your honest question is narrower than either camp: does any of it matter for the agent I already run?
For Hermes users the answer is yes, and sooner than you would expect. The plugin catalog already carries eleven Jev entries, most of them merged in the last week.
What Jev actually is
Jev comes from TypeSafe AI, which describes the category as “System One models”; Simon Willison’s write-up uses the plainer term decision models, and it is the better one. The mechanics are simple to state:
- You send text, or a small structured state — a string, a list of strings, or name/value pairs describing a ticket, a customer, a diff.
- You ask a typed question: a yes/no, a rating, or a choice between options you supply.
- You get back numbers. A choice question returns a probability distribution across your options plus a confidence score, not a sentence.
That is the whole trick, and it is why the design is interesting for agent work. An agent constantly needs small, boring judgments — is this command destructive, which of my forty skills fits this turn, does this diff need a second pair of eyes — and it currently pays a full text-model call for each one, complete with tokens of reasoning you throw away.
A decision model answers in one cheap call and cannot wander off into a chatty paragraph. Willison’s own framing is worth keeping in mind: the model is so cheap that running hundreds of experimental prompts costs a few cents, which makes the “try it and measure it” loop practical. The same write-up flags the current limits from TypeSafe’s own model notes — numbers, dates and adversarial content are weak spots — so the honest picture is “narrow question, fast answer, verify anything numeric”.
Eleven entries, and they decide different things
This is where it gets practical. Search the catalog and you find Jev spread across the whole turn lifecycle rather than in one “Jev plugin”:
| Catalog entry | Who maintains it | What it decides | Where it hooks in |
|---|---|---|---|
jev |
ourines | Explicit decision sidekick. Gives you one jev_evaluate tool; advisory only, no automatic tool gating. |
Tool |
jev-judge |
DoGMaTiiC | Destructive / exfiltration / impact questions about terminal, write_file and patch calls — shadow mode by default, enforce escalates. |
pre_tool_call |
jev-skill-router |
DoGMaTiiC | Names the one skill from your live roster that fits this turn, before the model call. | pre_llm_call |
jev-effort-router |
AlphaPerseii3000 | Per-turn model and reasoning-effort choice, rewriting the outgoing request itself. Ollama:Cloud only. | llm_request middleware |
jev-typesafe |
Anders Jensen-Waud | Atomic yes/no checks, routing, rubric scoring and mixed typed questions as four tools. | Tools |
jev-curator |
anpicasso | Relationships between complete skill packages, producing fail-closed consolidation plans. | on_skill_lifecycle, pre_tool_call |
jev-approvals |
anpicasso | Jev as the smart-approval reviewer only — it refuses every other task and fails closed to ESCALATE. | Approval path |
jev-model-router, jev-mcp-router, jev-memory-selector, jev-agent-router |
Pinutss | Routing to a model, an MCP server, a memory backend or an agent — each shipped as a skill plus a stdio MCP server run with uv run. |
MCP |
nerve |
keeltrace | A supervisory layer: context governance, token-budget trajectory control, Kanban supervision, remote SSH workers, with provider-neutral Jev / Laya / OpenJev backends. | Nine hooks |
nerve is worth a note of its own: it used to be listed as Hermes-Jev and was renamed to Nerve at v0.2.2 last week, so if you remember a Jev entry with a different name, that is the same project.
Installing one
hermes plugins search jev
hermes plugins install jev-judge
Two details make that safer than a raw git clone:
- A catalog name resolves to the entry’s repository at a pinned 40-character commit SHA, and the installer records that provenance in its
.install-metadata.json. A pinned plugin does not move under you; moving it takes an explicit--force --ref <sha>, which is also how you review an update on your own schedule. hermes plugins searchmatches entry names, descriptions and declared tools, so you can see what a plugin claims before it is on disk. The catalog is curated in-repo and refreshed from the live repository with a six-hour cache, falling back to the in-tree copy when offline.
Two rules before you install any of them
Cataloged is not audited. Admission to the catalog reviews the entry — its metadata, disclosures and declared capabilities — not the plugin’s code. Treat a catalog install as “someone read the manifest carefully”, not “this is safe”.
Read the disclosure line, because these send your data somewhere. Every entry carries an explicit statement of what leaves the machine, and they differ a lot:
jev-judgesends each judged call’s tool name and redacted arguments — up to 600 characters each, at most 12 arguments — to TypeSafe or your configured gateway, using your key. In shadow mode it only logs.jev-skill-routersends your message (up to 4,000 characters) plus skill names and shortSKILL.mdexcerpts from your local roster.jev-effort-routersends the current message and up to four previous turns to OpenRouter’s Decisions API, billed to your OpenRouter key, on every routed turn.nervedefaults to a hosted Jev backend and sends each turn’s prompt (up to 12,000 characters) plus redacted tool and result previews; Laya and OpenJev can be configured as local or self-hosted backends.
The failure behaviour is just as important. jev-judge fails open on every error path — a Jev outage never blocks your tools. jev-approvals fails closed, escalating to a human rather than allowing a command it could not judge. Both are reasonable; picking the wrong one for your threat model is not.
Which one to start with
Start with jev-judge in its default shadow mode. It logs one JSONL line per decision without blocking anything, so a week of normal work gives you real data about how often it would have escalated — and you can read the log before you grant it any authority.
Then resist the urge to stack routers. jev-skill-router, jev-effort-router, jev-model-router and jev-agent-router all want to decide “what happens next” for the same turn; installing three means three models voting on one request and a bill you cannot attribute. Pick the single routing decision that is actually costing you money.
Where this stands today
All eleven entries are community-tier plugins that declare a minimum Hermes version — from 0.19 up to 0.21.4 for jev-effort-router — and they land on main after the v0.21.4 tag, so the catalog is their distribution channel rather than a release.
Jev is not yet a first-class provider, and the open requests show people want it to be: issue #113008 asks for a typed probabilistic decision-provider runtime for bounded agent decisions, issue #113837 asks for Jev support in Hermes, and a pull request to add TypeSafe Jev to the model-provider list is still open. Until one of those lands, the plugin catalog is how Jev gets into your agent — which, given the catalog pins commits and prints disclosures, is not a bad place to start experimenting.
If the hook lifecycle in that table is new to you, our plugin catalog guide covers how entries get admitted and installed, and the MCP catalog security guide is the companion read on trusting a third-party server. For the two knobs these plugins most often touch, see the reasoning effort guide and the unattended approvals guide.