Is Jev Open Source? The Weights Are Closed, the Tooling Is Not

No. Jev 1.13 (typesafe/jev-1.13) is not open source, there is no weights repository to find, and no amount of scrolling through TypeSafe's GitHub organisation will turn up a checkpoint, an architecture document or a parameter count. What is there is the software around the model: eleven public repositories, every one of them MIT or Apache-2.0, none of them containing Jev itself. That is the honest one-line answer — the tooling is open, the model is not — and it is the half of the story a reader never gets from "closed, hosted, unpublished" alone. Two dates frame it. TypeSafe shipped the model on 2026-09-15, which is outside the seven-day window this blog writes to, so this is not a launch piece and nothing in it should be read as one. The dated event is 2026-09-24, when OrcaRouter added typesafe/jev-1.13 to its own catalogue: the first time Jev has been callable through a third-party gateway rather than only through TypeSafe's own endpoint. That is the exception this page runs on — a model that became runnable where it was not.

What that changes for a reader is narrow and practical. Before 2026-09-24, evaluating Jev meant opening a second vendor relationship before you could test a single decision. After it, Jev sits on the same key as the generative half of the same workflow: one API for 200+ models, 0% markup (provider list price passed through, so vendor price cuts are live here the same day), with the model reachable at typesafe/jev-1.13. You still call it in its own shape — POST /v1/systemone, non-streaming — because that is not the OpenAI chat-completions route, but the contract you sign and the key you rotate are the ones you already have.

The answer is two answers, and both are needed

"Is Jev open source?" reads like a yes/no question and behaves like a two-part one. Part one: the model. It is closed. TypeSafe has published no weights, no architecture, no training compute figure and no parameter count for Jev 1.13, and there is no repository named for it. Part two: the surrounding software. It is open, actively maintained, and genuinely useful, and it is the reason a reader searching for a repository is not simply out of luck.

Confusing the two produces the wrong conclusion in both directions. Assume the whole thing is open and you will spend an afternoon looking for a checkpoint that does not exist. Assume the whole thing is closed and you will miss the piece that actually matters if you are worried about lock-in — an MIT-licensed adapter that lets you build against the typed-decision interface and change what is behind it.

What TypeSafe actually publishes

Read on 2026-09-30, the organisation has eleven public repositories. Star counts and push dates move, so treat this as a snapshot rather than a fixed property of the project. Every licence is MIT or Apache-2.0 unless noted.

• skills — MIT, roughly 2.4k stars, last pushed 2026-09-12. "Agent skills for building with TypeSafe's System One API."

• system-one-adapter-python — MIT, 356 stars, last pushed 2026-09-22. "Drop-in TypeSafeClient replacement backed by LLM APIs."

• typesafe-sdk-js — MIT, 257 stars, last pushed 2026-09-15. The official TypeScript/JavaScript library for the TypeSafe API.

• typesafe-sdk-python — MIT, 254 stars, last pushed 2026-09-26. The official Python library; v0.7.2 added an `http2` extra that day, and v0.7.1 on 2026-09-21 added examples for usage with AI gateways.

• daggerverse — Apache-2.0, 23 stars, last pushed 2026-09-25. A collection of Dagger modules.

• WorkflowEvals — Apache-2.0, 7 stars, last pushed 2026-09-29. "evals.typesafe.ai workflow code published."

• n8n-nodes-typesafe-ai — MIT, 1 star, last pushed 2026-09-29.

• typesafe-ai.github.io — no licence declared, 2 stars, last pushed 2026-06-04.

Three more are forks of unrelated projects and are dealt with below: pulumi-clickhouse, LLaDA and vllm.

Nothing in that list is the model. There is no Jev repository, no weight files, no tokenizer, no serving configuration — nothing that would let you stand up a working copy. The repos are client-side furniture: two official SDKs, an agent-skills pack, a CI module collection, a published eval suite, an n8n node, the org site, and the adapter. That is a real and well-maintained surface, and it is not the model.

The one repository that matters if you are trying to avoid lock-in

system-one-adapter-python is the entry with the most consequence for anyone making an adoption decision, and its own description states the point: a "Drop-in TypeSafeClient replacement backed by LLM APIs."

Read that carefully, because it is doing something specific. The durable asset in a System One integration is the interface, not the endpoint behind it: you define a piece of state and a set of named questions, and something returns one typed answer per question. That contract is what your codebase ends up shaped around. The adapter decouples the contract from the implementation — you keep building against the typed-decision interface, and the thing producing the decisions is a swappable LLM API call underneath.

Two honest qualifications. An adapter is not the model: answers produced by a general LLM through this path are not the calibrated probabilities Jev returns, so it is a way to keep the interface portable, not a way to get Jev's behaviour without Jev. And it is explicitly a TypeSafe project — the escape hatch is built by the vendor you might want to escape, which is better than nothing and not the same as an independent one.

The two forks, and the inference they invite

Three of the eleven repositories are forks. pulumi-clickhouse is a Pulumi provider for ClickHouse Cloud, Apache-2.0, 3 stars, last pushed 2026-07-08. The other two are the ones that get read as evidence, and both readings are wrong.

• vllm — Apache-2.0, 3 stars, last pushed 2025-05-23. A fork of the high-throughput inference and serving engine.

• LLaDA — MIT, 12 stars, last pushed 2025-06-17. A fork of the official PyTorch implementation for "Large Language Diffusion Models."

The lazy inference writes itself: they forked a diffusion-language-model repository, so Jev must be diffusion-based. It is not, and the fork tells you nothing about Jev's architecture. A fork is a copy of somebody else's code under somebody else's licence, sitting in an organisation for reasons that its own last-push date makes obvious — May and June 2025, more than a year before Jev shipped publicly, and untouched since. Neither repository is part of what TypeSafe released in September. If you want to know how Jev works, TypeSafe has not published that, and no fork in its organisation fills the gap.

What closing the weights actually costs you

Four things, and they are concrete rather than philosophical.

• You cannot self-host. There is no artefact to run, so a vendor outage or an access change is not something you can route around by standing up your own copy.

• You cannot audit. TypeSafe does publish a jaggedness page for Jev 1.13 — last reviewed 2026-09-17 — that names where the model is unreliable: literal reading of wording over intent, anything involving arithmetic, date and time comparison, indirection and double negatives, large states full of irrelevant detail, adversarial content in the state, contradictory instructions and criteria, and structural invariants it does not guarantee, such as a true/false answer and its equivalent yes/no choice disagreeing. That page is unusually candid, and it is still the vendor marking its own homework. Nobody outside TypeSafe has inspected the weights.

• You cannot fine-tune. There is no base model to adapt, so a decision task Jev handles badly stays badly handled until the vendor changes it — the jaggedness page's own remedies are workarounds in your code, not training runs.

• You cannot pin a version beyond the vendor's alias. typesafe/jev-1.13 is a hosted name, so what answers a call next month is whatever TypeSafe is serving under that name then.

None of that is unique to Jev and none of it is a scandal; it is the trade a hosted decision model makes, and the counterweight is that you never carry a checkpoint, a GPU bill or an inference stack. It is worth knowing which side of the trade you are on before you build on it.

What Jev is, now that you can call it

Jev is not a chat model and does not generate prose. You send a state — the material to be judged, as text, an object or an array — plus a set of named questions, and it returns one structured answer per question. Every question is one of three primitives:

• noul — a true/false judgment, returned with a calibrated probability.

• choice — pick one of up to 255 labelled options.

• score — rate on an ordered scale of 2 to 10 levels.

TypeSafe's own documentation shows a 0-indexed score example; the Jev 1.13 model card publishes 2–10 levels. Both are the vendor's own material and this page does not invent a reconciliation between them.

The training method is TypeSafe's own coinage: Reinforcement Learning for Calibrated Decisions (RLCD), described in the launch post against RLHF and RLVR on the axis of calibrated decisions with honest probabilities. RLCD is TypeSafe's term, not a generic machine-learning acronym, and it should be read as a vendor description rather than an independently characterised technique.

Access is no longer gated: Jev has been generally available since 2026-09-21, and "waitlisted" is retired. "Early access" is still TypeSafe's own current wording on its homepage, so it is not a claim to dismiss — it is simply the vendor's label, and the operating limits it publishes alongside it are concrete.

The numbers on our card: a 65,536-token context, with the vendor documenting roughly 64K of input across the combined state plus questions. If you have seen a smaller figure quoted for Jev, that is the state budget alone rather than a competing measurement, and the two should not be presented as a contradiction. Price is $0.042 per million input tokens, with output billed at zero — there are no output tokens to meter, because a typed decision is not prose.

Our own serving data, from our traffic rather than the vendor's benchmark, over the seven days to 2026-09-30: p50 151 ms, p95 247 ms, about 349 output tokens per second, a 0.49% error rate, and 76.2M tokens served. Daily p50 across that window ran 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, with one real outlier — a 2,448 ms p95 on 2026-09-28 that belongs in the series without being the norm.

TypeSafe's headline claims, labelled as the vendor's and not independently replicated: "193.6x Faster, 444.6x Cheaper," footnoted to System One workflows; a worked example of $0.000081 in 0.114 s against $0.013880 in 8.566 s for LLMs; "$42 Per Billion input tokens"; and "Zero Hallucinations," which is a claim about confidence estimates rather than a proof of zero errors — our card's 0.49% error rate is the honest counterweight. TypeSafe also says plainly that it cannot prove its pricing is not subsidised, and that its published evals were generally run from laptops on the West Coast where the service is based. Its own benchmark card is still marked pending.

The third-party repositories exist, and we do not vouch for them

Searches for "jev github" eventually surface repositories that are not TypeSafe's: wrappers, prompt collections, adapter experiments, and the familiar "awesome" list that appears around any new model. They are not part of what the vendor publishes, they carry no vendor review, and their star counts measure curiosity rather than correctness. They may be useful; they are not documentation, and nothing in them is a statement about how Jev works.

What would change this answer

A weights release, a published architecture, or an independent evaluation of the decision quality rather than the latency. Any of the three would flip the first word of this page. Until then the search has a stable answer, and the part of it worth acting on is the toolchain: if the typed-decision interface is what you are building against, an MIT-licensed adapter that swaps the backing model is the difference between a decision you can revisit and one you cannot.

Jev 1.13 is on our catalogue under typesafe/jev-1.13, on the same key as the rest of a stack and routed through the dedicated systemone endpoint rather than the chat-completions shape. The model is closed, the tooling is open, and both halves of that are now reachable from one place.