Self-hosted Jev: what you can actually run, and on what hardware
TypeSafe Jev is a hosted API — the SDK is only a client, and its terms forbid building lookalikes from its outputs. What you can self-host is the open ecosystem around it. One matrix, ten routes, and a minimum runnable install for each.
Quick answer
No GPU at all? Von — 395M parameters, ~1.5 GB on disk, under 15 ms on a CPU. MacBook? Kev on MLX (47 ms) or Laya-MLX (13.4 ms p50 on an M3 Max). One consumer GPU? cbjev for speed, Laya to fine-tune, SemIf to reuse a 4B with zero training. Server budget? Kev or JevK5 on an H100, DiffusionGemma on a 24 GB card, openjev-sglang on a B200. And Jev itself: hosted, closed-weight, not self-hostable.
Every number on this page is a third-party published figure or a read of a public repository (snapshot 2026-09-23/26) — not a benchmark we ran. This ecosystem changes weekly; re-verify anything you plan to rely on.
First, the honest answer
What you cannot self-host
Jev itself. TypeSafe serves it as a hosted API; the Python and TypeScript packages are clients that call that API over the network. There are no public Jev weights and no offline mode, and the Master Customer Agreement 2.3(b) forbids using the service or its outputs to develop a similar product.
What you can self-host
The open ecosystem that grew around it, in three families: trained decision models (Laya, Von, cbjev, NanoJev, JevK5), adapters that read option logits from models you already host (Kev, SemIf, AnyJev, simple-jev), and diffusion-based servers (OpenJev, openjev-sglang). Most expose the same /v1/systemone contract, so an existing TypeSafe SDK call survives a base-URL swap.
The install and hardware matrix
Ten routes, one row each: the minimum hardware, the footprint, the latency its authors or testers report, and the one-line install. Internal links go to our per-project teardowns; the rest go straight to the source repository.
Whatever already serves your open LLM (vLLM, HuggingFace, llama-server)
No new weights (simple-jev); AnyJev heads are ~100 KB each
AnyJev L2 head costs less than one extra forward pass
pip install "anyjev[hf]"
Zero training: turn the model you already self-host into the decision layer
Latency figures are each project’s own or a named third party’s, on the hardware stated — treat them as hypotheses, not guarantees. Independent 49-task testing puts the best open model (Von, 395M) at about 0.704 against hosted Jev’s 0.966, so plan for calibration and a fallback either way.
Eight routes, eight minimum installs
The shortest path from nothing to a first typed decision, per route. Commands are shared across languages; the notes around them are what differ.
Von
route 1 · no GPU
When to pick it
When there is no graphics card in sight. Von is a 395M ModernBERT-Large encoder with three decision heads — about 1.5 GB on disk, under 15 ms per decision on a CPU — and it leads the open field on the independent 49-task benchmark (≈0.704). Its recorded failure mode: on unfamiliar domains it collapses to a single mode, so point it at the job you hired it for.
# Von needs no GPU: 395M params, ~1.5 GB on disk,
# each decision under 15 ms on a CPU.
git clone https://github.com/wfzyx/von.git && cd von
# follow the README to serve or call it in-process
# JavaScript callers can use the published SDK:
npm install von-sdk
The Node SDK call shape: decide({ state, question, options }) returns { choice, confidence }. Escalate below your own threshold.
Laya
route 2 · laptop or free-tier GPU
When to pick it
When you have a few hundred labelled examples and intend to fine-tune — that is the job Laya is good at. Zero-shot it is near chance (0.362 on typed decisions), so treat the pip install as step one of a training project, not as a finished replacement. The multilingual Router is the reason to pick it over cbjev for non-English text.
pip install laya
# python: load and predict — one forward pass, N questions
# import laya
# agent = laya.load("convaiinnovations/laya")
# answers = agent.predict(state, questions)["answers"]
# serve the /v1/systemone contract for existing SDK callers:
laya-serve
Serving takes about four seconds on a laptop since v0.3.7. Refit a temperature on a held-out slice before trusting any confidence it prints.
cbjev
route 3 · one consumer GPU
When to pick it
When the encoder route is right but Laya is too slow or flips too many answers on option reordering — cbjev is fine-tuned from Laya and reports 0.2% answer flips against Laya’s 7.8%, at 1.5–6.9× the speed on a 4090. Two catches: it is GPL-3.0-or-later, and its English checkpoint is English-only, so route other languages to the multilingual checkpoint.
git clone https://github.com/tomek7667/cbjev.git && cd cbjev
pip install -e ".[serve]"
# GPL-3.0-or-later — check licence compatibility before adopting.
Keep each question to 30 options or fewer; beyond that its accuracy drops off faster than Jev’s does.
Kev
route 4 · MacBook MLX or H100 drop-in
When to pick it
When you want the shortest migration: Kev speaks the same /v1/systemone contract, so the TypeSafe SDK call survives a base-URL change. It trains and fine-tunes on a MacBook (MLX 47 ms on a repeated state) and reaches 12–26 ms on an H100. Read its own numbers before adopting: 0.822 on held-out new sources against Jev’s 0.857, and a confident-error rate of 4.0% versus 3.7%.
git clone https://github.com/jaredpalmer/kev.git && cd kev
uv sync --extra serve
# serve the 0.8B checkpoint on your own hardware
KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve \
--run jaredpalmer/kev-0.8b --port 8009
# the same request shape Jev uses
curl -s localhost:8009/v1/systemone \
-H 'content-type: application/json' \
-d '{"model":"kev-latest","state":"...","questions":{...}}'
0.5B was the original release; the current lineup is 0.8B/4B/9B on Qwen3.5. Memory: 4B ≈ 9 GB bf16, 9B ≈ 17–19 GB.
SemIf
route 5 · zero training, one 3090
When to pick it
When you already host an open model and refuse to train anything. SemIf is a readout harness: it scores your declared options from a frozen Qwen3.5-4B’s logits in one forward pass — the project’s reference run is a single RTX 3090, and the same trick runs 5.21× faster than asking the model to write JSON. A CPU backend via llama.cpp, MLX/MPS and even a WebGPU browser demo exist, so the GPU is convenient rather than mandatory.
git clone https://github.com/TheoLeeCJ/SemIf.git && cd SemIf
# reference run: one RTX 3090, frozen Qwen3.5-4B, BF16
# also runs on CPU via llama.cpp; MLX / MPS on Apple Silicon
#
# the idea, in three lines:
# probs = read_option_logits(model, state, question, options)
# decision = max(probs, key=probs.get)
# if probs[decision] < 0.85: decision = "human_review"
The author is candid: it reproduces the interface pattern, not Jev’s accuracy — 0.845 vs 0.883 on the 102-row aligned subset. Calibrate per workload before shipping.
JevK5
route 6 · open weights, vLLM / GGUF serving
When to pick it
When you want open weights that still speak the Jev wire format. JevK5 (Apache-2.0, 4B/9B, Qwen3.5 + distilled LoRA) serves through jevk5-serve with the /v1/systemone contract, and its JevBench v1.2 score of 62.04 against Jev’s 63.29 is the closest open number on that board. The GGUF builds (2.0–9.5 GB) run on CPU and Apple Silicon via llama.cpp at ~0.25–0.6 s per short decision. Limits to know: English-only, 16 options per question, and a 16,384-token input ceiling.
git clone https://github.com/allebee/jevk5.git && cd jevk5
# weights on Hugging Face:
# alibiserikbay/JevK5 (4B) · alibiserikbay/JevK5-9B · JevK5-GGUF
#
# jevk5-serve speaks /v1/systemone — Jev-wire-compatible.
# bf16 needs ~9 GB (4B) or ~19 GB (9B) of GPU memory;
# the GGUF route runs on NVIDIA / AMD / Intel / Apple via llama.cpp.
Its own hard-tier run reports 0.784 against Jev’s published 0.730 on the public hard half — but that is its own run, not an official JevBench score. English-only; cap questions at 16 options.
NanoJev
route 7 · CUDA research rig
When to pick it
When you want to train your own decision model, not just serve one. NanoJev (Qwen3-0.6B + decision heads, MIT per third-party listings) ships the full training and evaluation pipeline, and it is the only open project that has genuinely beaten Jev somewhere: ViZDoom Basic 128/128 against Jev’s 56/128 on its own harness. The honest boundary: those four games are also its training domain — Jev wins the maze test set back 7/10 — so do not point it at ticket triage.
git clone https://github.com/TianyuCodings/NanoJev.git && cd NanoJev
# Qwen3-0.6B backbone + decision heads.
# The inference script expects CUDA — there is no Apple Silicon path.
# Training + evaluation pipeline ships with the repo
# (a Chinese README is available).
Evaluate in your own environment before trusting any number: the published harness results come from the same domain the model trained on.
OpenJev + openjev-sglang
route 8 · diffusion: workstation to datacenter
When to pick it
When your state includes images or your option lists run into the hundreds — the diffusion route is the only one that takes image input, and OpenJev (razorback16) serves DiffusionGemma 26B-A4B with up to 255 choices at p50 27 ms on an RTX PRO 6000. One caveat from the LocalJev README applies to the whole family: these servers are wire-compatible, not mathematically equivalent. At datacenter scale, openjev-sglang serves Qwen3.6-35B-A3B on SGLang for B200-class batch throughput.
# workstation scale: DiffusionGemma 26B-A4B on a 24 GB+ NVIDIA GPU
# (~18 GB weights, NVFP4) or ~16 GB Apple silicon via MLX
git clone https://github.com/razorback16/openjev.git && cd openjev
# datacenter scale: Qwen3.6-35B-A3B on SGLang, B200-class
git clone https://github.com/ekzhang/openjev-sglang.git && cd openjev-sglang
Both expose /v1/systemone-style endpoints, so the SDK-side swap is the same as everywhere else on this page. OpenJev can also proxy Laya and Verdict behind the same API.
Pick by the hardware you already have
Decision models span four orders of magnitude in footprint. Your hardware picks the shortlist before accuracy ever does.
No GPU at all
Laptop CPUs, old office machines, edge boxes, CPU-only containers
Run Von — 395M parameters, ~1.5 GB on disk, under 15 ms per decision on a CPU. Verdict (ONNX int8) answers in under 2 ms for the simplest label sets, and JevK5’s GGUF builds cover the wire-compatible case at ~0.25–0.6 s per short decision. SemIf also runs on a CPU through llama.cpp when the 4B quantized model is acceptable.
Apple Silicon
M-series MacBook and Mac Studio, 16 GB+ unified memory
Kev on MLX answers in 47 ms on a repeated state (77 ms fresh) and trains on the same machine. Laya-MLX measures 13.4 ms p50 on an M3 Max at under 1 GB. OpenJev runs DiffusionGemma on ~16 GB of unified memory. Von remains the zero-setup fallback.
One consumer GPU
RTX 3090 / 4090 / T4-class cards, 8–24 GB VRAM
cbjev for raw speed (3 ms single questions on a 4090), Laya as the fine-tuning base (33–40 ms on a T4), SemIf on a 3090 with a frozen 4B in BF16, JevK5-4B in ~9 GB of bf16, and NanoJev when the CUDA training pipeline is the point.
Workstation or server
RTX PRO 6000 / H100 / B200-class hardware
Kev runs 12–26 ms and JevK5 13.2 ms p50 on an H100; OpenJev’s DiffusionGemma server wants a 24 GB+ card (p50 27 ms); openjev-sglang targets B200-class batch throughput; and if the open LLM you already serve should simply become the decision layer, AnyJev or simple-jev over vLLM costs no training and almost no extra latency.
A five-step adoption path
The same sequence whether you land on a 1.5 GB CPU model or a B200 server.
01
Decide which layer you are replacing
Jev the API cannot be hosted. Pick consciously: the model itself (trained encoders), the serving layer (wire-compatible servers), or nothing at all — just borrow logits from the open model you already run (adapters).
02
Match the route to your hardware
Use the matrix above. 1.5 GB and no GPU means Von; a single 3090 means SemIf or a small encoder; a 24 GB card unlocks DiffusionGemma; batch serving at datacenter scale means SGLang on B200-class hardware.
03
Install with the minimal command
Every block below is the shortest path to a first answer — clone, sync, serve, curl. Resist building a platform before the first request returns.
04
Calibrate on your own labels
Self-reported confidence is not calibrated confidence. Fit a temperature on a held-out slice of your own workload before trusting any probability: on SemIf’s own numbers this moved ECE from 0.208 to 0.069, and on Laya it fixed the calibration while accuracy did not move at all.
05
Shadow-test, then gate on confidence
Run the self-hosted route next to your current setup on real traffic and compare on your own labels, not the project’s benchmark. Route low-confidence decisions to a human or a fallback chain before you delete the old path.
Self-hosted Jev: frequently asked
Is Jev open source?
No. TypeSafe Jev is a hosted, closed-weight API; the Python and TypeScript SDKs are clients that call it, and the Master Customer Agreement 2.3(b) forbids using the service or its outputs to build similar products. What is open is the ecosystem around it: Laya, Von, cbjev, NanoJev and JevK5 are trained open models, Kev, SemIf, AnyJev and simple-jev adapt models you already host, and OpenJev with openjev-sglang serve the diffusion route.
Can you self-host Jev itself?
Not the model. There are no public Jev weights and no offline mode. What people usually mean by "self-hosted Jev" is one of the open replacements above — and most of them expose the same /v1/systemone request shape, so an existing SDK integration survives changing the base URL.
What hardware do I need to self-host a Jev-style decision model?
Anywhere from 1.5 GB and no GPU to a B200. Von runs on a CPU in under 15 ms; Laya installs with pip and serves on a laptop; SemIf’s reference run is a single RTX 3090 holding a frozen Qwen3.5-4B in BF16; Kev wants Apple Silicon MLX or an H100 (12–26 ms); the DiffusionGemma servers need 24 GB+ cards; openjev-sglang targets B200-class hardware.
Which should I run locally — Laya or Kev?
Different jobs. Kev is the drop-in: the same /v1/systemone contract, LoRA adapters on Qwen3.5 (0.8B/4B/9B), trains on a MacBook, and it publishes its own losses — 0.822 on held-out new sources against Jev’s 0.857. Laya is the fine-tuning base: near-chance zero-shot (0.362 on typed decisions against a 0.461 majority baseline), genuinely competitive after fine-tuning on your labels, with a measured option-position bias in ordinal score questions. If you want zero training at all, SemIf reads logits from a 4B you already host.
What is JevK5?
An Apache-2.0 open-weight decision model (4B and 9B, Qwen3.5 plus a distilled LoRA) that stays Jev-wire-compatible through its jevk5-serve endpoint. On JevBench v1.2 it scored 62.04 against hosted Jev’s 63.29 — the closest open number on that board — with p50 latency of 13.2 ms on an H100 for easy and standard questions. GGUF builds (2.0–9.5 GB) run on CPU and Apple Silicon via llama.cpp. It is English-only and caps a question at 16 options.
Is a self-hosted replacement as accurate as hosted Jev?
Not on zero-shot, out-of-domain work. On the one independent benchmark with no stake in any project (49 tasks, 869 cases), the best open model — Von, at 395M — scores about 0.704 against Jev’s 0.966: a roughly 26-point gap. What open wins is latency on your own hardware, cost per call after the hardware is paid for, and data residency. Budget for temperature calibration and a confidence-gated fallback either way.
