Jev is TypeSafe AI’s System One Model: you send it program state plus typed questions, and it returns decisions with calibrated probabilities instead of prose. (This is Jev the model, not FaZe Jev the streamer or the JEV vaccine.) It’s closed weights, API only, served at POST https://api.typesafe.ai/v1/systemone as jev-latest. So “run Jev locally” can’t mean Jev. It means a cluster of days-old community projects, led by OpenJev, that reproduce the idea with open models. If you’re new to the model itself, read what Jev is first; this piece covers the imitations.
It’s a roundup and a reality check: what each README claims, how faithful it is, what hardware it wants, and how to test any of them through a local HTTP endpoint in Apidog the way you’d test the TypeSafe API. None are benchmarked by a third party, and none are from TypeSafe.
What “run Jev locally” can mean
TypeSafe’s launch post describes a model trained with Reinforcement Learning for Calibrated Decisions (RLCD), three primitives (noul, choice, score), a response time of 70ms to 500ms, and $0.042 per million input tokens with free output. Those are vendor claims; the training recipe is unpublished. A community thread says Jev was trained on 100% synthetic data. Treat that as an unverified rumor.
Because the recipe is secret, every “open Jev” takes one of three shortcuts:
- Read the logits off a frozen chat model. Pose a multiple-choice question to a small Qwen, skip generation, and turn the next-token logits per option into a probability. OpenJev and mini-jev do this.
- Train a small scorer from scratch. A model whose only job is scoring N options against a context in one pass. That’s jevlike.
- Change the decoding engine. Keep the base model, evaluate every field in parallel over constrained candidates. That’s the Apple Silicon engine on Hugging Face and the vLLM pull request.
None of them reproduce RLCD. That’s the honest headline.
OpenJev: logits off a frozen Qwen on one 3090
OpenJev asks “Can we run something like Jev on a 3090 at home?” and answers with an MIT-licensed Python package. The README is careful: it “reproduces that interface pattern with open models; it does not reproduce Jev’s undisclosed model or training.”
The mechanism is one forward pass that reads declared option logits, with no answer token sampled. Criteria and options arrive with each request, so nothing is fine-tuned per task. The primary model is Qwen3.5-4B.
Numbers the README reports on one RTX 3090 with Qwen3.5-4B:
- Direct typed logits: 1.023 s for 21 probability pairs, against 5.332 s for an autoregressive JSON array, or 5.21x slower.
- On a 102-row TypeSafe subset, modal agreement of 0.845, against 0.883 for published Jev.
Input is JSONL with id, state, question, and an options array of {id, description}; output is a probability per option. There’s no HTTP server in the repo: you run openjev-score --mode direct --model Qwen/Qwen3.5-4B --input examples/decisions.jsonl, or try the WebGPU demo at openjev.com. Hardware: CUDA and a GPU holding a 4B model in BF16.
What it leaves out: no noul or score primitive, and the probabilities are a softmax over option logits, not RLCD-calibrated confidence.
mini-jev: a preregistered study with a local server
mini-jev is an experiment more than a product. Its tagline: “What a Jev-style interface looks like on a frozen Qwen3-4B, read the option letter’s logits instead of generating JSON.” It runs Qwen3-4B-Instruct-2507 on CLINC150 intent classification and compares grammar-constrained JSON generation against reading the logit of an option letter.
The result, from 6,750 paired observations: JSON 0.909 accuracy, letters 0.907, a difference of -0.22 points inside a 95% CI of [-1.44, +1.04]. Letter reading was about 4x faster on 32-token texts.
The README maps its terms to TypeSafe’s: choice and noul are “what this study measures on a frozen model, as the letter read and the boolean; score (an ordered scale) was not measured.” It calls this “a correspondence of terms, not a reproduction of their model,” and adds the caveat every project here should copy: “The letter shares are a ranking with a confidence gap, not calibrated probabilities.”
It ships an HTTP demo. MINIJEV_DEVICE=mps uv run python demo/server.py serves 127.0.0.1:8765 with POST /run, which takes schema and text and returns per-field letter, p, gap, and answer. It needs about 8.5 GB of memory on Apple Silicon or an NVIDIA GPU. MIT, 11 stars at the time of writing.
jevlike: a from-scratch option scorer
jevlike is being shared as a “reverse-engineered Jev-like model”. The README says otherwise: “TypeSafe has not published its design. This repository is an independent starter model with the same input and output shape.” The authors add they “did not show equal quality with Jev or reproduce TypeSafe’s private training method.”
The design is small. Each option gets a query vector that attends over the context tokens; a shared dot product scores each pair; softmax turns scores into probabilities. The default encoder is byte embeddings learned from scratch, with an optional frozen Hugging Face encoder.
Reported numbers: about 98% on synthetic menus, 26% on Wikispeedia with a frozen Qwen2.5-0.5B encoder against an 8% shuffled control, and one pass “about 100 times faster than a small decoder forced to write 400 tokens.” It runs on CPU, MPS, or CUDA. MIT, 764 stars.
Faithfulness is the lowest of the group. You train it on your own labels, so it’s a classifier you built, not a decision model you can hand arbitrary criteria. No noul or score, no calibration claim, no HTTP server.
Parallel constrained decoding: the Apple Silicon engine
The Hugging Face Space parallel-constrained-decoding is circulating as a “Typesafe.ai Jev open source alternative”, but its README never mentions Jev, TypeSafe, or RLCD. Its title is “Parallel Constrained Decoding for Apple Silicon”: an MLX inference engine for structured extraction over mlx-community/Qwen2.5-1.5B-Instruct-4bit, with any mlx-lm decoder swappable in.
The method: prefill the context once into a KV cache, broadcast it across every schema field, evaluate only the valid candidate token IDs per field, softmax over that set, and assemble the JSON in code. The README reports on an M4 Max: 4-field fraud triage 420 ms autoregressive versus 75 ms parallel (5.6x), and a 28-field support triage 1,900 ms versus 270 ms (7.0x). It claims 100% schema validity, which follows from never sampling free text.
It serves HTTP on port 8000 via uvicorn, returning parsed_json plus field_telemetry with per-field confidence. Requirements: an M1 or later Mac, macOS 14+. Apache 2.0. No accuracy numbers, only latency, and “calibrated” here means an exact softmax over candidates, not a trained calibration.
vLLM PR 57250: a Jev-like mode for DiffusionGemma
vLLM pull request #57250, opened September 16 and still open, turns DiffusionGemma into what the author calls a “calibrated multiple-choice machine”: a seeded canvas with single-token answer slots, read at a step cap, with confidence from logprobs and entropy. New vllm_xargs fields include diffusion_seed_canvas, diffusion_max_steps, and diffusion_read_only, and an example structured_server.py translates a schema into a canvas.
The PR reports 8.7 requests per second on single canvas reads, 54 at 32-way concurrency, and roughly 90% accuracy on a language classification corpus. A reviewer flagged a missing race-condition test and unbounded thread spawning as blocking. Until it merges, it’s a design to read, not one to deploy.
How faithful is each one?
| Project | Base | Primitives | Calibration | HTTP server | Hardware |
|---|---|---|---|---|---|
| OpenJev | Qwen3.5-4B, frozen | choice | softmax over option logits | No (CLI + browser demo) | RTX 3090 class, CUDA |
| mini-jev | Qwen3-4B-Instruct, frozen | choice, noul | ranking with a gap | Yes, port 8765 | 8.5 GB memory, MPS or CUDA |
| jevlike | encoder you train | choice | none claimed | No | CPU, MPS, or CUDA |
| MLX engine | Qwen2.5-1.5B-Instruct-4bit | schema fields | softmax over candidates | Yes, port 8000 | Apple Silicon, macOS 14+ |
| vLLM PR | DiffusionGemma | yes/no, choice, scale | logprobs plus entropy | Yes, OpenAI-compatible | vLLM-class GPU, unmerged |
Every row is a frozen or self-trained model reading logits. That gets you Jev’s shape: typed answers, a probability per option, one forward pass. It doesn’t get you Jev’s central claim, that RLCD makes those probabilities honest. OpenJev’s 0.845 versus 0.883 is the only comparison to the real model, and it’s the author’s own eval. Setup matches our guide to running Kimi K3 locally: weights, a GPU or M-series Mac, a local port.
Test any of them in Apidog like the real Jev API
The point of a local reproduction is to swap it for the real API without rewriting your integration, so your tests should send the same body to both. None of these projects speak Jev’s {model, state, questions} schema natively. Put a thin adapter in front of whichever one you run: a 40-line FastAPI app that accepts the Jev body, calls the tool, and returns {"answers": {...}} with choice, probabilities, and confidence keys. Now Apidog sees one contract.
Two environments, one set of requests. Create Local reproduction with BASE_URL = http://localhost:8765 and no key, and TypeSafe API with BASE_URL = https://api.typesafe.ai plus TYPESAFE_API_KEY in the local field so it never syncs to teammates (scope rules here). Every request uses {{BASE_URL}}/v1/systemone and Bearer {{TYPESAFE_API_KEY}}; the local server ignores the header.
Send the Jev body. POST {{BASE_URL}}/v1/systemone with the state and questions you’d send to jev-latest:
{
"model": "jev-latest",
"state": "My card was charged twice for one order and I need this fixed today.",
"questions": {
"department": { "type": "choice", "instructions": "Which team handles this?",
"criteria": { "billing": "charges and refunds", "shipping": "delivery", "technical": "bugs" } },
"wants_refund": { "type": "noul", "instructions": "Is the customer asking for money back?" }
}
}
Assert on the probability fields. Add post-processor assertions: answers.department.choice equals billing; answers.department.probabilities.billing is greater than 0.7; answers.wants_refund.noul is greater than 0.8. Flip the environment dropdown and run the same scenario against TypeSafe. The gap between the two runs is your faithfulness number, worth more than any README table.
Save the local run as a mock so the frontend builds against a stable answers object with zero GPU time. Download Apidog to set it up; the free plan covers four users. The same pattern for chat models is in testing local LLMs as APIs.
FAQ
Is OpenJev the same as Jev?
No. OpenJev reads option logits from a frozen Qwen3.5-4B and says so in its README. Jev is a closed model TypeSafe trained with RLCD. OpenJev reports 0.845 modal agreement with Jev on a 102-row subset, by its own author’s eval.
Which one should I try first?
mini-jev if you’re on a Mac and want an HTTP endpoint today; OpenJev if you have an NVIDIA GPU and want the closest published comparison to Jev. Pick jevlike only if you have labeled data to train on.
Can I get calibrated probabilities from a frozen model?
Not by reading logits alone. A softmax over option tokens is a ranking with a gap, as mini-jev’s README puts it. Calibration needs training or a post-hoc step like temperature scaling on your labeled set, which none of these ship.
Is it cheaper to run one of these than to pay TypeSafe?
At $0.042 per million input tokens with free output, Jev already sits at the floor of the cheapest LLM API providers. Local wins on privacy and offline use, not on cost, once you count GPU time.
Where this leaves you
OpenJev, mini-jev, jevlike, the MLX engine, and the vLLM PR all prove one idea: a decision doesn’t need generated text, and reading logits in one pass is faster. None prove they’re calibrated, and none are Jev. Run one behind a Jev-shaped adapter, keep a second environment pointed at TypeSafe, and let your assertions decide how far apart they are.
