jevbox

How we reviewed this: we installed the repository at aaa9381, started its own PostgreSQL and SpiceDB containers, and ran its 279 tests. We then wrote two tests of our own on top of its test harness, which drives the real HTTP routes, database and SpiceDB with a fake fetch in place of every provider, and counted what went to TypeSafe. We made no Jev calls, so nothing here measures search quality.

What it is

From Extend, a document-parsing company: a full-stack document library with a Finder-style browser, viewers for PDF, Office, code, tables and media, organisations with members and roles, per-document sharing, chat with citations, a REST API and an MCP server. Permissions live in SpiceDB, and every route checks them.

Jev — or Cloudflare’s Clef, the other supported decision model — does three jobs:

• search, as a beam search down the folder tree: at each level, a choice question picks the branches worth opening, through categories, documents and sections;
• usefulness scoring of each source passage before it may reach a chat model;
• automatic filing of uploads into existing folders, keeping uncertain documents higher up.

Search and document questions do not work without a decision-model key. Plain text, Markdown, code, JSON, HTML and CSV are indexed locally; PDFs, Office files and images need an Extend API key for parsing.

Does Jev only see what you may see?

For a library with sharing, this is the question that matters. The repository’s own suite asks it many ways — “search and outbound routing exclude unauthorized source material”, “JEV rechecks membership before every outbound batch”, “context scoring rechecks permissions and excludes revoked results” — and 274 of 279 tests passed. The five failures were thumbnail and PDF rendering tests that need the Playwright Chromium the Dockerfile installs and our container did not have.

Its suite checks document text. We also checked the metadata around it. In an organisation with an owner and a member, the owner created a private folder and a private document inside it, each with a marker in the folder name, file name, heading and body. The member then uploaded a document of their own and searched for words in the owner’s secret.

who searched	owner’s folder name	file name	heading	body	results
member	not sent	not sent	not sent	not sent	three passages, all from the member’s own file
owner (control)	not sent	sent	sent	sent	three passages

The owner’s own private content does go to TypeSafe when the owner searches, as it must. Nothing of it reached Jev on the member’s behalf. That is the design working: permission filtering happens before the decision request is built, not after.

When TypeSafe is busy

At aaa9381 each decision request was made once. We had the fake provider answer the first TypeSafe call of a member’s search with 529 Overloaded:

502 {"error":"Provider request failed (529). Check your key and account limits."}

The same search a moment later returned its results. A beam search makes several decision requests in a row, so one transient error loses the whole search, and the message sends you to your settings for a problem that is not your key. TypeSafe documents 529 as transient and its official SDKs retry it. We reported it, with two smaller notes: it sends the unpinned jev-latest, so the usefulness thresholds can shift when TypeSafe moves the alias, and the TypeSafe address is fixed, so it cannot point at a compatible self-hosted server.

Fixed on 7 October (2c6bc58). A 429 or 529 from TypeSafe is now retried up to twice, honouring retry-after, and the message names the cause (“temporarily overloaded (529). Please try again shortly”) instead of your key. On 13 October we called its request function at 672668f with a fake provider. One 529 followed by an answer succeeded after about half a second. One 429 with retry-after: 1 succeeded after a second. Three 529s in a row still fail, as they should. The model is still jev-latest and the address is still fixed.

What it takes to run

Node 24.6+, pnpm 12.9, and Docker for PostgreSQL, SpiceDB and a local mail catcher. pnpm setup:local writes the configuration and an encryption key, and keys for the model providers are stored encrypted and never sent back to the browser. Render, Docker, Helm and AWS deployments are documented. The licence file is MIT, from CrowdView Inc. (Extend), though GitHub’s detector does not label it; third-party notices sit in licenses/.

Verdict

The most careful permission design we have seen in a Jev project. SpiceDB checks are woven through search, scoring, chat context and revocation, and the test suite tries to break them in the ways that matter. Our own probe, aimed at the folder names and file names its suite does not check, found nothing leaking. 672 stars, 288 of them in the last three days.

Fix one thing before relying on it under load: a single overloaded response from TypeSafe ends the search. And remember what you are configuring. The member’s own passages do go to TypeSafe, and then to whichever chat model you choose. Permissions decide whose documents leave the server, not whether any do. For another project that walks a document tree with Jev, see jev-doc-search.

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

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