OpenJev: A Self-Hostable Open Source Alternative to TypeSafe's Jev

On September 15, TypeSafe AI gave early access to Jev, a model that never writes a sentence. It reads a question, scores every allowed answer, and returns a decision in a single pass. Three days later, a Hacker News post describing an open clone of that approach passed 700 points in under 48 hours, and by the time the thread settled, several independent developers had already shipped working, installable versions. OpenJev is the name that stuck to that cloning effort, and the most complete one to actually run today is a small, Apache 2.0 licensed project on GitHub from a developer using the handle razorback16.

What OpenJev actually does

A normal language model call, even a fast one, generates text token by token. If you ask it "is this email spam, yes or no," it still writes out an answer, and you parse the words back into a decision. OpenJev skips that step entirely. You send it a state, a short description of the situation, and one or more typed questions with a fixed set of allowed answers: yes or no, a multiple choice list, or a numeric score. The server runs a single forward pass through the model and reads the probability it assigned to each allowed answer directly off the model's internal output, without ever generating a word.

That constraint is also the safety feature. Because the model can only answer within the options you gave it, there is no free text for it to hallucinate into. It can be miscalibrated or wrong about which option is most likely, but it cannot invent a fifth answer that doesn't exist. This is the same idea TypeSafe built Jev around: a model whose job is producing calibrated decisions rather than prose, aimed at the huge share of AI workloads that are really classification problems wearing a chatbot's clothes, things like moderation, routing, lead scoring, and safety checks.

Under the hood, OpenJev runs on DiffusionGemma 26B-A4B, a discrete diffusion model licensed Apache 2.0 by NVIDIA and Google that denoises a full sequence per pass rather than generating left to right. That licensing detail matters for a project like this: the weights themselves are as open as the wrapper around them.

Setting it up: what using OpenJev looks like

The fastest way to try it needs no local setup at all, through a free hosted instance the project links to directly. Self-hosting is the more realistic path for anyone planning to run this in production, and it needs an NVIDIA GPU with at least 24GB of VRAM. From there it's a standard Docker workflow:

git clone https://github.com/razorback16/openjev
cd openjev
docker compose up -d

On the client side, the project ships a Python SDK you install with pip install typesafe-sdk, deliberately mirroring TypeSafe's own package naming so that code written against the commercial Jev API can point at a self-hosted OpenJev endpoint with a small config change instead of a rewrite. You set the endpoint URL and an API key as environment variables, and calls go through the same shape of request either way.

The benchmark numbers, and what they actually mean

The project's own benchmarks, run on an RTX PRO 6000 at 38 percent GPU utilization with three questions per request, show a single request completing in 94 milliseconds at the median. Push it to 16 concurrent requests and throughput rises to 43.3 requests per second at a 367 millisecond median. At 64 concurrent requests, that climbs to 57.4 requests per second with a 760 millisecond median. None of that is independently verified beyond the project's own published numbers, but the shape of the result lines up with what a prefill-only architecture should produce: latency that scales with concurrency load rather than with how much text a model has to generate, because there isn't any text being generated.

For context, that is fast and cheap enough to run as a synchronous check inside a request path, something you would never do with a full chat completion call, where waiting on generated text for a yes or no answer wastes both time and tokens.

Who this is actually for

OpenJev is for a technical operator who already has, or is willing to rent, GPU access and wants classification-shaped decisions (spam filtering, content moderation, lead qualification, agent output auditing) without paying for a closed API or burning a full chat model on a task that only needs one bit of information back. The Apache 2.0 license on both the wrapper and the underlying model means there's no vendor lock-in risk the way there would be running everything through TypeSafe's paid endpoint.

It's not for someone without infrastructure experience or GPU budget: the hosted free tier exists but self-hosting is where the real cost and speed advantage shows up, and that requires the Docker and GPU setup above. It's also a young, fast-moving project. The GitHub repo has a handful of commits, there's no enterprise support, and it sits inside a swarm of similar forks that appeared in the same week, several with fewer stars and less documentation. The flagship site that first carried the OpenJev name, openjev.com, has already renamed itself to SemIf without public explanation, which is a reasonable signal that names and branding in this specific corner of open source are still shifting week to week.

Where it fits

If a meaningful share of what you're building an AI system to do is really deciding between a small set of options rather than writing anything, a typed decision model is worth trying before defaulting to a chat completion call. OpenJev is the most usable open way to do that today without paying for TypeSafe's own hosted product, provided you can put a GPU behind it.

Sources: razorback16/openjev on GitHub, TechCrunch's reporting on TypeSafe AI's Jev, and the original OpenJev Hacker News discussion.