Jev DSH Decision Engine

How we reviewed this: we ran its tests in node:24 with no network, then used the exported client’s own fetcher injection point — no patching needed — to drive it against providers that failed in five different ways, with our canary key deliberately embedded in the upstream error bodies to see whether it ever came back out. No Jev calls.

What it is

A decision service for agent harnesses: a native DeepSeek Harness plugin, an iPolloWork importable plugin, and through iPolloWork, access from OpenCode and Codex Harness. The README is careful about that last part — it says plainly that OpenCode and Codex are supported through iPolloWork, that this repository does not yet ship native packages for them, and that other harnesses would need their own adapters rather than being “automatically compatible”.

The scope statement is equally careful: Jev returns the selection, probabilities, confidence and usage, and does not execute the recommended action, switch models or route requests. The agent keeps planning and execution.

It is 200 lines of service code plus a skill, and the skill is written for the agent rather than the reader: it tells the agent to discover real candidates from the host rather than inventing them, to send minimal state and “not send credentials, entire transcripts or complete files unnecessarily”, that question IDs identify results and are not instructions, and that a noul near 0.5 “means uncertainty, not medium skill”. It also says a configured key is not proof of a working connection, and that the agent must not ask for the key in chat.

What we could break, and what we couldn’t

createJevActions takes a fetcher, so the whole client is testable without a network. We supplied one.

A normal evaluation behaved: the request carried state, questions and model and nothing else, two headers, and — the detail we look for — redirect: "error", so a redirect is a failure rather than a chance to forward the bearer token.

Then we made the provider misbehave, with sk-CANARY-dsh-0001 planted inside each failure:

the provider…	the caller sees	key in the message
401 with the key in the body	“Jev API Key 无效，请重新连接。”	no
422	“Jev 不接受此评估请求…”	no
500 echoing the key	“Jev 请求失败（HTTP 500）。”	no
throws a network error naming the key	“Jev 网络请求失败…”	no
redirects	same generic network failure	no

The comment above that code says it: “Never forward arbitrary network errors or upstream response bodies: they may contain credentials.” It holds — the guard even checks that the error it is about to re-raise does not contain the key.

Two more paths:

Timeouts are real. With a fetcher that honours the abort signal, a 1,500 ms budget produced “Jev 评估超时” at 1,501 ms.

Retries are bounded. A provider answering 429 with Retry-After: 0.3 was tried exactly three times in 832 ms and then gave up with a “busy” message. Only 429 and 529 are retried; 401, 422 and 500 fail immediately.

And status with no key returns {"configured": false, "remoteVerified": false} — it reports the absence rather than guessing, and a separate check-connection action makes the one small billable call that would prove it.

What we’d change

The model is jev-latest, a constant with no override. For a plugin whose entire output is a routing decision, that means the behaviour of your harness can change without a commit. Pinning, or at least allowing an override, is a one-line change.

There is no licence file. The package is "private": true with no license field, no LICENSE, and no mention in the README. As it stands nobody can build on it.

The tests are node --test: eight pass for the client, and the harness-level file skips two cases that need the host. That is a reasonable split for a plugin, and there is no CI running either.

Verdict

Small, sober and better engineered than its size suggests: no redirects, bounded retries, a real timeout, generic errors that cannot leak a key, and a skill that spends most of its words on what Jev will not do.

Use it if you are on DeepSeek Harness or iPolloWork. Ask the author for a licence and for a model pin before you depend on it, and read the README’s own note that OpenCode and Codex reach it through iPolloWork rather than natively.

For the same job in Claude Code and Codex, see jev-use; for routing between skills, Jev Agent Skill Router.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 21, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.