OpenJev and the Jev clones: what you can and cannot self-host

There are two different things called OpenJev, and neither of them is Jev. One is a website that resells access to TypeSafe's hosted model and funds the bill from cryptocurrency trading fees. The other is a GitHub project whose default backends are ordinary chat models behind an OpenAI API key. The only thing in this ecosystem that actually ships System One-style weights you can run is a third project with a different name.

If you came here to find out whether you can self-host Jev: TypeSafe distributes it only as a hosted API, publishes no model weights and documents no on-premise deployment. This post explains what the alternatives genuinely give you, including the one that publishes its own unflattering calibration numbers. All figures were read on 23 September 2026.

Is Jev open source? What TypeSafe actually publishes

TypeSafe's documentation describes exactly one way to reach Jev: POST /v1/systemone against its API, through the HTTP endpoint or a client SDK. No weights download, container image or on-premise deployment option appears anywhere in the docs. The models page states that the same weights serve every account and that Jev is not fine-tuned or LoRA-adapted with customer data; the only things you control are the state you send and the structure of your questions.

That page also sets out what TypeSafe offers teams who ask about self-hosting for data reasons: it says Jev is not trained on customer requests or responses, and points to its legal pages for a Data Processing Agreement and zero data retention for enterprise customers. For most teams that is the answer to the question they were really asking. For a few, whose data genuinely cannot leave their own network, it is not, and those teams are the ones who end up searching for a clone.

Two limits are worth fixing in your head while you are on that page, because both are widely misquoted. The request budget is 64,000 tokens covering the state plus all questions, with a separate 32,000 for the state plus the single longest question, so the common "32K context" shorthand is wrong. And the published rate limits are 250,000 tokens per second and 1,200 requests per minute, with a 429 above either.

openjev.sh is a door to the hosted model, not a copy of it

The site at openjev.sh is the first result most people find, and it is easy to misread. Its own FAQ answers the question plainly: Jev is TypeSafe's model, and OpenJEV is access to it. Its API documentation gives the endpoint as POST https://api.openjev.sh/v1/systemone with openjev as the default model name, mirroring TypeSafe's request shape.

The funding model is the unusual part. The site says creator fees from trading a token called $JEV flow into a treasury that pays for Jev inference, and that more fee revenue expands the inference capacity the treasury can support. Its own on-page meter reported $71,936 in fees generated, roughly 888 million Jev calls covered and a cost of $0.000081 per call when we read it on 23 September 2026. Those are the project's self-reported figures on its own marketing page; we found no independent audit of them, and the capacity claim is by construction dependent on trading activity continuing.

The engineering consequence matters more than the economics. If your reason for looking at alternatives is that you cannot send data to a hosted API, routing it through a second hosted party in front of the first makes that worse rather than better. You now have two processors instead of one, and the second is not the one publishing a DPA.

The GitHub project called OpenJev is a playground with three backends

The repository at SiliconLabAI/OpenJev is a different thing entirely: a local Express and Vite app that takes state and typed questions and returns structured answers. Its README documents three modes, and the difference between them is the whole story.

Mode	What it actually does	What you need
parallel	One tiny LLM call per option, then softmax over the results	An OpenAI-compatible API key
oneshot	A single structured JSON call to any OpenAI-compatible model	An OpenAI-compatible API key
decider	Calls a separate open-weights model server over TypeSafe's wire format	A GPU, or Apple Silicon, or CPU patience

The README's sample environment sets OPENJEV_MODEL=gpt-4o-mini alongside OPENAI_API_KEY, so on the default path two of the three backends are a wrapper around somebody else's chat model. That is a legitimate thing to build and a useful way to explore the question shapes. It is not self-hosting, and it is not a decision model.

The difference is what the numbers mean. A softmax over per-option scores produces something that looks like a probability distribution because it sums to one. It is a normalisation of scores from a model trained to predict the next token, not a distribution trained against outcomes. Whether the 0.82 it prints corresponds to being right 82% of the time is an empirical question, and the answer is usually no unless someone has measured and fitted it.

The project that does publish weights, and the evidence it offers

OpenJev's third backend points at Mapika/decider, which is the serious entry. It is Apache-2.0 with weights on Hugging Face, it states plainly that it is independent, not affiliated with or endorsed by TypeSafe, and that nothing was distilled from Jev: the models are fine-tunes of Qwen3.5 base models trained on public datasets plus data labelled by a local teacher model. It serves POST /v1/systemone in TypeSafe's wire format, so TypeSafe's own SDKs work against it by changing a base URL.

The question the brief for this post insisted on is whether any of this gives you calibrated probabilities, and here there is real evidence rather than a claim. Benchmark Heaven's JevBench v1.3.0, scored 21 September 2026 across 534 decisions including 220 hard ones, run one request at a time from a server in Germany, scores calibration on the hard tier as top-label expected calibration error in ten bins combined with how closely the returned distribution matches a gold distribution. Systems that return only a label and no distribution score zero on that axis.

System	JevBench score	Calibration	Cost / 1,000 decisions
Jev 1.13.0 (rank 1)	74.4	83	$0.040
decider-35b-a3b (rank 8)	67.6	72	~$0.067 est.
decider-2b (rank 23)	61.7	47	~$0.020 est.

So the gap is real and it is concentrated exactly where you would fear. The small model you can run on 4 GB scores 47 against the hosted model's 83 on calibration. decider's own README says the same thing without being asked: decider-2b's top-label expected calibration error on the benchmark's hard items is 0.30, and the README's phrasing is that the model is confident where it is wrong there. The 35B's hard-tier figure is 0.15.

Publishing that is worth more than any marketing claim on either site, and it is the reason we would shortlist this project and not the others.

One row on a leaderboard is not one project

Read that board carefully before you quote it. Among its 52 entries are rows called OpenJev, OpenJev (razorback16), openjev-sglang, Open-Jev 9B, Open-Jev 2B and openJev Verdict, scoring anywhere from 38.1 to 66.4. The board does not tell you which repository each row is, so no row there can be read as a score for the GitHub project discussed above. "OpenJev" is a name several unrelated efforts have taken, which is the single most common source of confusion in this whole topic.

What self-hosting the pattern actually costs

The hardware is the easy part to plan for. decider's README gives roughly 4 GB for the 2B model, 8.4 GB for the 4B, and 65 GB in bf16 or 19.6 GB quantised for the 35B; it also runs on Apple Silicon and on CPU. The hard parts are the limits it lists, and they are specific enough to plan around.

One forward pass cannot do multi-step arithmetic, so multi-hop and temporal reasoning have to be split into several questions. It is English only. And the most consequential for anyone porting a working TypeSafe integration: the README reports that rules written into the question are not followed at that size, scoring 0.67 on a form-filling probe for a one-sentence question against 0.24 for a paragraph of rules. The structured criteria that make hosted Jev behave — the what, the not_for, the examples — are precisely what a 2B reproduction handles worst.

Budget for an evaluation harness of your own before you budget for a GPU. The same discipline applies here as in any on-premise inference decision, and the arithmetic usually lands where we found it in our look at what self-hosted LLM cost really takes: the hardware is rarely the expensive part.

When self-hosting is the right call anyway

Three cases, and only three in our experience. Your data cannot leave your network for a legal or contractual reason that a DPA does not satisfy. You need weights pinned for years, because a hosted alias moves when a new release ships and a threshold tuned on one set of weights is not tuned for another. Or your workload is narrow and enormous enough that owning inference beats renting it, and you have labelled data to prove the smaller model holds up on your traffic.

Outside those, the better architecture is to build against the hosted model and keep the exit warm. Because decider speaks the same wire format, an integration written for TypeSafe's SDKs can be pointed at a local server by changing one environment variable. That is a genuinely useful property and the main reason to care about these projects at all: not as a replacement today, but as evidence that the interface is not a lock-in.

If you do go local, test calibration first and accuracy second. An uncalibrated model that is right 75% of the time will hurt you more than a calibrated one that is right 70%, because the routing thresholds you built on top of the hosted model silently stop meaning anything. We laid out why that uncertainty signal is the point in our comparison of a decision model against an LLM, and it is the first thing to re-measure on any substitute. Sizing that evaluation properly is where our AI engineering practice usually starts, and it is cheaper than discovering the gap in production.