Hermes Jev Skills moves an agent's small decisions to a cheap decision model

The argument is about tokens, not about writing

The README opens with a claim about where an agent's budget goes. Your agent burns frontier-model tokens on things that are not thinking: which model should answer this turn, which of 377 skills to load, which retrieved passages matter, which turns survive a summary, which button comes next. Those are decisions, not prose.

The proposed fix is to hand those decisions to something that costs a fraction of a cent and answers in about 0.4 seconds, and let the expensive model do the writing. That framing is the whole project, and it has one hard constraint that shapes everything else: Jev never writes text.

Jev is TypeSafe's decision model, and the contract is a state plus typed questions. You ask it to pick one, to score something, or to answer yes or no, and it replies with a calibrated confidence. There is no generation step and no prose output, which is what makes it cheap and fast, and also what makes it the right tool for these particular questions and the wrong tool for anything else.

The target audience is an agent that is already capable but paying frontier prices for its bookkeeping. The README puts the context as Hermes, with the NousResearch hermes-agent repository linked, and the skills are described as also working in Claude Code and Codex, because eleven skills ship as plain SKILL.md files rather than as a Hermes-specific format, so the same folder works in anything that reads a skill file.

Eleven skills, and the measured cost of each

The README's table lists what Jev decides for each skill alongside a measured figure, and the measurements are specific enough to be useful.

Model routing picks which model is good enough for this turn from every model you can call, at about 0.4 seconds per turn. Search decides which fetched results are worth opening, whether the evidence answers the question and which candidate query to run next, at about 1.9 seconds per round as a median of five live runs across two requests, ranking then sufficiency and pick. Social research reuses the search skill, and the README notes there is no social specific benchmark yet. Memory filters retrieved passages and screens them for hidden instructions, taking 60 passages per request up to 480 per call, with an injection screen running locally even when Jev is down.

Computer use picks the next GUI action from a table of actions you already judged safe, at about 0.5 seconds per decision, and browser use does the same for page actions at about 0.4 seconds per step. Skill selection picks which of the installed skills this turn needs, 377 skills in about 2.8 seconds, with acknowledgements answered locally for free. Triage judges how urgent a message is at about 0.4 seconds and 0.00006 dollars, and mailbox sorting puts an inbox message into a lane at about 0.44 seconds median and 0.00002 dollars each.

Two of these numbers are worth pausing on, because they are the ones where the project published a negative or a limitation rather than a win.

Two of the skills were deliberately not made to work

The handoffs row is the most interesting line in the table, because the project measured the idea and then declined to ship it.

It says Jev decides nothing here, by default, followed by the reason: a handoff written from Jev's keep, summarize, drop digest recalled less than one written from the plain transcript. What ships instead is the whole dialogue, 1,200 words and a way back to the old session. The scores are given, 58.7% recall alone and 75.0% with one search, against 37.5% and 68.3% before.

In other words, the summarising version was worse than the version that simply kept everything, and the fix was to stop summarising. A project that measures its own feature and finds it does not work, then ships the opposite, is doing something rare enough to be worth noticing.

The web screening row is the other one, and it is more qualified. In-distribution planted attacks in 80 real web results, 70 of 79 were caught, against 11 for Hermes's own pattern scan, and 0 of 1,520 clean chunks were withheld, at about 0.2 seconds per result. But the README adds that it is not portable recall, and links a scorecard and public transfer evidence document.

The distinction is important. A screen that catches 70 of 79 planted attacks in the distribution it was built for is much better than a pattern scan catching 11, and it still might catch far fewer against a different attacker. The holdout document is the honest artifact to read if you are considering relying on it.

Installation is a Python script and a shadow mode

The setup is short. Clone the repository and run the installer:

git clone https://github.com/kerpopule/hermes-jev-skills ~/hermes-jev-skills && python3 ~/hermes-jev-skills/install.py

Then a key step, where jev setup-key opens a one-time page to paste the key into, followed by jev doctor to check the setup. The requirements are Python 3.9 or newer and no dependencies. If you received the project as a zip, you unzip it and run python3 install.py from that folder, or you can point your agent at the repository and tell it to install Hermes Jev Skills, and it will follow AGENTS.md.

The installer finds Hermes, Claude Code and Codex on the machine and installs for each one it finds. python3 install.py --check shows exactly what it would do without changing anything, and --uninstall reverses it. For Claude Code it also adds four lane subagents, jev-lane-small through jev-lane-escalate, each with its own model and effort, plus a short delimited lanes block in ~/.claude/CLAUDE.md, and that file is backed up first, with --no-claude-md leaving it alone.

The recommended way to start is stated plainly. Run jev models suggest --write to draft routing pools from price bands, then /jev routing shadow for a day. Shadow mode decides and logs without switching anything, so a day of decisions costs almost nothing and risks nothing, and you turn it on when the log looks right.

The slash commands give the full control surface. /jev for status, /jev routing shadow and /jev routing on for model switching, /jev skills on for skill suggestion, /jev notice on to show a marker like "[Jev] hard · coding → kimi-k3 · confidence 0.92" on routed replies, /jev screen shadow and /jev screen on for the web screening, and /jev routing on all to make it the default for every profile, where a profile's own setting still wins.

The agent itself gets five tools: jev_memory_filter, jev_compact_select, jev_choose_action, jev_supervise and jev_escalate.

The CLI is usable on its own, and the dashboard shows the decisions

The jev command works outside an agent session, and the README gives two examples that are genuinely useful on their own:

jev mail --file inbox.json             # sort a mailbox into lanes
jev mail --file inbox.json --summary   # counts per lane, what was unsure, what it cost

The summary mode is the interesting one, because it reports not only the counts per lane but what was uncertain and what the run cost. For a decision model, an explicit uncertainty report is a meaningful feature, since a confidence score you never look at is just a number.

The router-dashboard directory holds a dashboard with its own README, and the README describes what the screenshot shows: a Jev on, shadow or off switch, the routing pools as a grid, and live decisions as they happen, with the tier, the work kind, the model, which pool it came from, the confidence and the latency. That is a good design for a feature that otherwise is invisible, because you can see the model and the confidence of each routing decision while it runs.

The README is careful that the profiles and paths in the dashboard image are a demo home, and that the pools shown are a real working set. scripts/demo_home.py builds a home where nothing is real, which is how the next one is generated. The phrase about the demo home being where the next one comes from points at the workflow of generating a realistic environment for testing.

There is also a runnable design-choice example in docs/design-choice.md, about closed preset selection with deterministic rendering, two compatible layout, type and palette presets, local contrast and copy checks, offline fallbacks and an optional real-browser QA script. The README says it demonstrates the contract and not measured design-quality gains, and that it is offline by default with no new skill or routing hook.

Where the approach is the wrong one

The first limit is that a decision model is not a writer, and a lot of the value people want from an agent is in the writing. If your problem is that the model produces poor prose or reasons badly, nothing here helps, because Jev never writes text by design. The project is aimed at a specific failure mode, which is a frontier model being asked cheap questions.

The second is the trust surface. Routing decisions determine which model answers a given turn, and a model router that is wrong will send a hard turn to a cheap model. The confidence number is there to make that visible, and shadow mode exists so you can check the log before you trust it, but a miscalibrated confidence is still a miscalibrated confidence, and the README does not publish calibration data.

The third is the evidence quality. The web screening numbers come from in-distribution planted attacks, and the README is explicit that this is not portable recall. A security control that is measured in distribution is useful against attackers resembling those in the evaluation and weaker against others, and the linked scorecard and holdout document are the place to judge how far it generalises. For a system that reads untrusted web content into an agent's context, that is the part of the project to look at hardest.

The fourth is the dependency on an external decision service. The skills need a key, the key is pasted into a one-time page, and the routing latency numbers in the table assume a reachable service. The memory feature mitigates the failure mode, since the injection screen runs locally even when Jev is down, and that is the one place where the design accounts for the service being unavailable.

Editorial conclusion

Hermes Jev Skills suits a Hermes, Claude Code or Codex user whose per-turn bookkeeping is consuming a frontier model's budget and whose agent handles many installed skills, and it is the wrong tool if you want better prose out of the model, since Jev never writes text by design. Before switching routing on, run it in shadow mode for a day, as the README itself advises, and read the published scorecards, because the project's own numbers show the web screening does not transfer cleanly to other distributions. Verify first that the decision model you point it at is one you are allowed to send state to, and treat the handoff behaviour as unchanged by default, since the measured result was that it recalls less than a plain transcript.

Frequently asked questions

Official sources

1. Issues
2. kerpopule/hermes-jev-skills on GitHub
3. License: MIT
4. README
5. Releases