Jev Explained

How we reviewed this: we ran the real Next.js app in node:24 with its TypeSafe endpoint pointed at a local stand-in — one patched line, reverted and diffed — drove it in a real browser, and exercised its proxy route directly. We made no Jev calls.

What it is

An interactive explainer for the three primitives: Noul, Choice and Score. Four worked examples ship with it — an email spam classifier, a buy-or-sell question, an agent tool-call guardrail and a fan-out inbox triage — and the workbench shows the state, the questions, the answers and the exchange that produced them. There is a hosted version, and you bring your own key.

For a teaching artifact, showing the request and the response next to the rendered answer is the right decision: the thing people get wrong about Jev is what the wire actually carries, and this puts it on screen.

Where the key goes

The browser keeps your key in localStorage and sends it to the app’s own /api/jev route as an x-jev-api-key header; the route forwards the request server-side to the provider. The comment above it explains why the hop exists, and it is accurate — neither endpoint allows cross-origin browser calls:

// Neither TypeSafe nor AI Gateway allow cross-origin browser calls, so this
// route forwards the request server-side. The API key is passed per request
// from the browser and is never stored on the server.

We checked the route’s behaviour rather than taking the comment’s word:

request	response
valid key header, known provider	forwarded; {"ok":true,"status":200,"latencyMs":25,…} with the upstream body inlined
no key header	{"error":"Missing API key"}
x-jev-provider: evil	{"error":"Unknown provider"}

The provider must be one of two hardcoded entries, so the route cannot be used as an open forwarder to an arbitrary host — worth having in a thing that accepts a bearer token from the internet. The upstream saw exactly model, state and questions, and the key never appeared in the rendered page.

Two caveats the README does not spell out. On the hosted demo, “bring your own key” means your key travels to that deployment on every call, in a header, and is used there; the code does not store it, but you are trusting a third party’s running server with a working credential. And localStorage is readable by anything running on the page, so a key pasted into the hosted version is exposed to whatever that page loads. Running it locally — which is a npm i && npm run dev away — avoids both.

Driving it

The app builds and serves, the examples load into the workbench (the spam example fills 465 characters of state), and the provider switcher offers TypeSafe or the Vercel AI Gateway. The Run button is gated on apiKey.trim().length > 0 && state.trim().length > 0.

We could not get Run to enable from browser automation even with the key typed into its field and an example loaded, so the end-to-end click-through is unverified here; driving the same request through /api/jev worked on the first try, which is why the table above is the evidence we are publishing rather than a screenshot. If you hit the same thing by hand, the state and the key are the two fields to check.

Maintenance

MIT, Next.js 16, a live Vercel deployment, AGENTS.md and CLAUDE.md for contributors, and a code of conduct. There are no tests and no CI, which is a fair trade for an explainer, and the endpoint list is a two-entry constant — this is not a tool you point at your own server.

Verdict

The best “what does a Jev request actually look like” page we have seen, and a clean example of a browser-to-provider proxy if you are writing one. Use it to understand the primitives, then run it locally before you paste a key you care about.

For a playground that also grades your question design, see jevcal; for the primitives as a library instead, Advocaat.

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.