JCR (Jev Capability Resolver)

How we reviewed this: we installed and built it in node:24, ran the test suite and the capability audit, then pointed the TypeSafe SDK at a local stand-in of ours with the SDK’s own TYPESAFE_BASE_URL — no patching — and ran the real resolver twice: once with a stand-in that could tell Stripe from Slack, and once with one that answered uniformly. We did not reproduce the author’s benchmark, which spends real money on two agents. No Jev calls.

What it is

An agent that needs an API usually gets a skill file: a document describing a workflow, loaded into context and carried for the rest of the task. JCR moves the lookup out of the agent. It holds a recursive tree of documented operations — the audit reports 11 groups, 960 nodes, 11,360 items, depth 6 — and exposes one tool. The agent asks for what it wants; Jev walks the tree; the agent receives only the selected operations and their context.

The capability format is deliberately separate from Jev, and the author says he would like it to become a community standard for “deterministic commands” — the individual operations a skill’s workflow calls, as opposed to the workflow itself.

The walk, watched from the other end

With our stand-in answering as a model that knows Stripe from Slack, npm run jcr:resolve -- "refund a Stripe charge" produced this:

request	options offered	bytes sent
1 — is this compound?	3	585
2 — which group?	12	3,820
3 — which provider?	2	498
4 — which section?	88	20,015
5 — which operation?	8	1,966

Five requests, four beam rounds, about 27 KB out, and what came back to the agent was 437 characters: one operation (GET /v1/application_fees/{fee}/refunds/{id}) with its required and optional parameters attached. That is the product working exactly as described — the 20 KB page of 88 options never touches the agent’s context.

Two design details stood out. Every question carries an explicit __none__ option, so “none of these” is a first-class answer rather than a low-confidence guess. And the first request is a gate that asks whether the request needs splitting at all, which is how a simple request avoids the decomposer entirely.

When the model doesn’t know, it says so. We reran the same query with a stand-in that returned a uniform distribution over every option:

{"stepsResolved": 0, "stepsUnresolved": 1, "matchesReturned": 0,
 "unresolved": [{"step": "refund a Stripe charge", "reason": "ambiguous", …}]}

No invented capability, no confidently wrong endpoint. A beam width of 3 and a band ratio of 0.6 are both configurable, which is the right place for those knobs.

What leaves your machine, and to whom

The state is small and clean: {"request": "refund a Stripe charge", "step": "…"} and the option list for that level. No file contents, no environment, no repository metadata. The request text does appear in all five requests, since each level needs it.

The thing to know before you install is that a JCR run can involve two vendors. Jev walks the tree; an OpenAI model — gpt-5.6-luna by default — splits compound requests into steps. The README’s key table says so plainly, and our single-step run never reached the decomposer, because request 1 above decided it didn’t need to. But a compound request sends your prompt to OpenAI as well as TypeSafe, and that is worth knowing if the prompt is a customer’s support ticket.

TYPESAFE_MODEL defaults to jev-latest. For a resolver whose behaviour is a routing policy, we would pin it, the way lorenzini argues for in its own script: an unpinned alias means your resolution behaviour can change without a diff.

Tests, audit and benchmarks

npm test gives 50 passing tests and tsc --noEmit is clean. The capability audit is the part we liked most: it validates the whole catalogue and prints its shape — 87 skills, 85 mapped and 2 excluded, 19 skill-backed nodes, max fan-out 175 — so a malformed or orphaned capability fails a check rather than becoming a silently missing branch.

bench/scenarios.json holds 50 realistic scenarios, written as actual support requests with account ids and payment intents in them rather than as one-line prompts. The README reports a Claude-with-Opus run dropping from 108,585 agent input tokens to 15,819, and Codex from 61,952 to 47,669, with wall times moving in both directions. Those are the author’s measurements on the author’s keys; we did not reproduce them, and the benchmark harness has a --dry-run that prints the matrix without spending anything, which is a good default to ship.

MIT, two commits (a large initial import), Node 22+, with a web page and an article behind the demo.

Verdict

The idea is right, and the implementation is careful where it matters: an explicit no-match option, an ambiguity outcome that doesn’t invent an answer, an audit that keeps the catalogue honest, and a tool boundary that actually keeps 20 KB of options out of the agent.

Two things before you adopt it: pin TYPESAFE_MODEL yourself, and decide whether you are comfortable with compound requests reaching a second vendor. If the capability format interests you more than the resolver, it is readable on its own — 1,907 JSON files, one small schema.

For the same “search outside the context” instinct applied to documents rather than APIs, see Jevify.

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.