Jeview

How we reviewed this: we ran its suite, then put the real gateway between a client we loaded with six distinct canary strings and an upstream we controlled and logged byte for byte. We made no Jev calls.

What it is

your code  →  Jeview (127.0.0.1:4777)  →  TypeSafe (api.typesafe.ai)

Point your Jev client at Jeview instead of TypeSafe and it relays each call, keeps it in a local SQLite database, and draws the calls on a live map in a browser. No dependencies, no SDK, no code change beyond a base URL. The README is explicit that it is unofficial and answers nothing itself.

Where each thing went

We sent one request through it carrying our own Authorization header, a cookie, a custom header, a state and an instruction — each a distinct string — and then grepped both the upstream’s log and Jeview’s own store:

canary	reached TypeSafe	stored by Jeview
the key set in the viewer	yes, as the Authorization	yes
our own Authorization: Bearer …	no	no
our Cookie: header	no	no
a custom X- header	yes	no
the request state	yes	yes
the question instructions	yes	yes

The second row is the one worth dwelling on. A gateway that saw a bearer token in a request and passed it along would be the obvious implementation, and it is what we found solar-mini4-jev doing earlier this month. Jeview drops it on a deny-list alongside cookie, origin and referer, and substitutes the key you gave the viewer.

It goes further than dropping it. With no key set in the viewer, the call is not forwarded at all:

{"error":"No Jev key: add one in the viewer at http://127.0.0.1:4777/"}

Nothing reached the upstream. The caller’s own token is not a fallback, so a key that lives in your application’s environment cannot accidentally become the one Jeview spends.

The viewer is the only way in

A plain curl cannot set the key:

$ curl -X POST .../_/api/settings -d '{"jevKey":"…"}'
{"error":"Settings can only be changed from the viewer"}

It requires a same-origin Origin header, JSON, and a key of 8–400 visible characters. Reading the setting back gives {"set":true,"ending":"NARY"} — the last four characters, never the key. The read API also refuses sec-fetch-site: cross-site requests, so a page on another site cannot make your local Jeview search its own history.

On disk, the store directory is 0700 and the database 0600. Your key and every state you have sent are in that file in plain text, which is the honest trade for a local recorder, and worth knowing before you point it at production traffic.

It relays, and does not improvise

Against an upstream we made misbehave:

what the upstream did	what the caller got
HTTP 500 with a JSON error	HTTP 500, that same body
a 302 to another host	HTTP 302, not followed
a non-JSON 200	HTTP 200, that same body

The redirect is the interesting one: the fetch is made with redirect: "manual", so Jeview hands the redirect back rather than chasing it to wherever it points. For a component whose whole job is to sit in the middle of your credentialled traffic, that is the right default.

It also refuses to be pointed at itself — jeview: the Jev endpoint http://127.0.0.1:4779 is this proxy — which is a small thing that would otherwise be an infinite loop found the hard way.

One thing it adds

The response is not byte-identical: every answer comes back with an extra events object beside answers, so a later call can name the answer that triggered it with a Jeview-Trigger header and the viewer can draw it as a branch. This is documented in the README and in llms.txt, and the request body is passed on exactly as it came — we diffed it. But if you validate response shapes strictly, that is the field to know about.

Engineering

MIT, Node 24+, zero dependencies — npm ci installs three dev packages and nothing else. 12 tests pass and tsc --noEmit is clean. The tests are written as sentences about behaviour rather than units: two Jeviews sharing a folder never hand out the same call id, the Jev key is set from the viewer only, never shown, the llms.txt in the repository is the one a Jeview at the default address serves.

That last one is a nice habit: the machine-readable instructions it serves to agents are tested against the copy in the repository, so they cannot drift apart.

Two days old, twenty-four stars, version 0.1.0.

Verdict

The smallest useful thing in this directory: one file, no dependencies, and you can see what your code is actually asking Jev within a minute of starting it.

What makes it worth listing rather than merely working is the key handling. It would have been easier to forward whatever Authorization arrived, and easier still to read a key from the environment. Doing neither — and refusing to forward at all until you have given the viewer a key — is a decision somebody made on purpose.

Weigh the store against your data: your states and your key live in a SQLite file on your machine. If that is fine, this is the cheapest observability in the directory.

For a tool that measures the questions themselves rather than watching them, see jev-calibrate; for a gateway that gets key handling wrong, solar-mini4-jev.

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

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