OpenJev reproduces TypeSafe's Jev decision interface on an open 4B model
Can we run something like Jev on a 3090 at home?
At a glance
- What is it?
- OpenJev reads typed decision probabilities straight from a frozen Qwen3.5-4B forward pass, with no JSON generation loop. The benchmarks are committed, and so are the caveats.
- Who is it for?
- OpenJev suits engineers building agent decision loops who want typed probabilities from a small local model, value committed evidence over marketing numbers, and can hold a 4B BF16 model on a CUDA GPU. Skip it if you need a supported product, multi-model guarantees, or the exact fast-path latencies in production, since those paths are flagged experimental with known drift.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The question in the repo name: Jev, at home
The README opens with a direct question: can we run something like Jev on a 3090 at home? Jev, in this telling, is TypeSafe's closed service for runtime-defined semantic decisions, the small judgments agent software makes constantly: route this ticket, retry that call, does the evidence support the claim. OpenJev's scope is stated with equal directness. It reproduces the interface pattern with open models. It does not reproduce Jev's undisclosed model or training, and it says so in the second paragraph.
The bet underneath is architectural. A chat model answers these decisions by generating prose that software immediately parses back into a branch. OpenJev skips the prose entirely and reads the answer where it already lives, in the model's logits.
Probabilities without generating a sentence
The mechanism is a single forward pass over three inputs: unstructured state, runtime-defined criteria, and a set of typed options with descriptions. The model's native option logits become the probabilities, and no answer token is ever sampled. Nothing arrives as text that a parser has to repair.
Runtime-defined matters as much as decision-native: the criteria and option descriptions travel with each request, so the same frozen model serves a routing table today and a moderation grid tomorrow without retraining. The README also describes shared-state handling: one long state can be prefetched once and branched across many criteria, which is where most of the speed story comes from. Every row of output carries the typed scores, timing, the exact model revision and a prompt hash, so a decision can be audited after the fact.
Quick start on a single GPU
The stated floor is Python 3.10+, CUDA, and a GPU that can hold a 4B BF16 model; the benchmarks were run on one RTX 3090. Setup follows the README verbatim:
python -m venv .venv
. .venv/bin/activate
export HF_HOME=/path/to/large-drive/huggingface
pip install -e '.[test]'Dependencies are pinned hard in pyproject.toml: torch 2.10.0, transformers 5.17.0, accelerate 1.12.0 among them. The scored example runs one command:
CUDA_VISIBLE_DEVICES=0 openjev-score \
--mode direct \
--model Qwen/Qwen3.5-4B \
--revision 851bf6e806efd8d0a36b00ddf55e13ccb7b8cd0a \
--input examples/decisions.jsonl \
--output results.jsonlWhen every row shares the same state, the README says to switch to --mode shared, which prefills the state once and evaluates criteria in parallel.
What the numbers claim, stated with their conditions
The speed table compares output paths on the same frozen Qwen3.5-4B, state, and 21 binary criteria on an RTX 3090. Direct typed logits: 1.023 seconds at the median, zero output tokens, 21 probability pairs. An autoregressive JSON array, even a compact one emitting only yes and no values: 5.332 seconds and 111 tokens, 5.21 times as long. The two agreed on 18 of 21 criteria, and the README is explicit that this is a systems comparison, not a claim of semantic equivalence.
Reuse scales further on a 37-state by 21-criterion workload: fresh direct scoring runs 2.33 decisions per second, serial prefix reuse 10.75, parallel suffixes 20.03. The experimental label on the fast paths carries a real cost the README does not hide: BF16 execution changed 5 or 6 of 777 argmaxes relative to fresh scoring. Quality rows put direct logits at 0.813 balanced accuracy on authored decisions and 0.845 modal agreement on a TypeSafe subset, against a published Jev figure of 0.883 read from TypeSafe's records over 102 aligned rows, not their 711-row aggregate.
The audit trail is the actual feature
What separates this repository from a benchmark screenshot is what got committed alongside the numbers. The 37 by 21 fixture, both runners, raw timings, row-level predictions, the decision-versus-array comparison with its prompt and token timeline, and the known failures all sit in the repository, with checksums. Three documents, RESULTS, METHOD and REPRODUCE, cover quality, frozen prompts, the exact environment and verification steps.
This is a claim discipline worth naming. The project never asks you to trust a summary; it hands you the fixture and the pinned commands and lets your own run disagree with theirs. For anyone wiring model judgments into software that acts on them, that habit, row-level outputs with revisions and prompt hashes, is transferable regardless of whether OpenJev's particular numbers hold on your hardware.
Where the edges are
The constraints are the ones the README admits first. The fast reuse paths are experimental, with that 5-to-6-argmax drift in BF16. The quality comparison to Jev covers 102 rows that could be aligned from public artifacts, a fraction of TypeSafe's reported aggregate, and no live Jev endpoint was queried. The model work is one frozen 4B family, Qwen3.5-4B plus a Qwen3-Reranker-4B for comparison, so nothing here establishes how the approach transfers to other models.
There are no releases or tags, so reproduction means pinning the commit yourself. The reranker comparison is quietly honest: native rerankers stayed strong at retrieval ranking but lost to direct logits as a general-decision baseline, which is a real negative result committed in public.
Positioned against the alternatives
Three other routes solve the same problem. Plain generation asks a chat model for a JSON answer and parses it; OpenJev's tables show that path costing five times as long on identical hardware, with parsing failures as a standing risk. Hosted decision APIs, Jev among them, outsource the judgment to a closed model; the README's own quality table is the honest scoreboard, 0.845 against 0.883 on the aligned subset, and running at home removes the waitlist and the per-call meter.
Reranker models are the third route, and the repository includes one in its comparison. For pure ranking tasks they remain strong. For declared-option decisions with typed outputs, the committed results favor reading logits directly. The open question, which these fixtures do not settle, is whether the gap holds on bigger models; the fixtures are there for whoever runs that experiment next.
Editorial conclusion
OpenJev suits engineers building agent decision loops who want typed probabilities from a small local model, value committed evidence over marketing numbers, and can hold a 4B BF16 model on a CUDA GPU. Skip it if you need a supported product, multi-model guarantees, or the exact fast-path latencies in production, since those paths are flagged experimental with known drift. Verify before adopting: run the pinned openjev-score command on your own GPU against examples/decisions.jsonl, then compare its 21 probability pairs against your current parsing pipeline on your real workload.
Frequently asked questions
What hardware does OpenJev need?
Python 3.10 or newer, CUDA, and a GPU that can hold a 4B BF16 model. The README's benchmarks were run on a single RTX 3090.
Does OpenJev reproduce Jev's model?
No. The README states it reproduces the interface pattern of TypeSafe's Jev with open models; Jev's model and training are undisclosed and are not reproduced.
Is OpenJev free to use?
The project code is MIT licensed. Model weights and third-party records without a redistribution grant are excluded, and the upstream models keep their own licenses.
Community notes