Open-Weights Jev Alternatives (2026): Which Decision Model To Actually Ship

TypeSafe released Jev on 15 September 2026 — a "System One" model that returns typed, calibrated probabilities instead of text, at $0.042 per million input tokens with free output. Within eight days the open-weights field filled in: Laya (421M, Apache-2.0), Kev-9B (Apache-2.0, 0.852 accuracy vs Jev's 0.857), openjev (MIT), and open-alternative-jev. Rank them by accuracy and Kev wins. Rank them by calibration and open-alternative-jev wins with an ECE of 0.020. For routing and guardrails you act on a threshold, so calibration is the number to buy on. Skip self-hosting if you make under roughly two million decisions a month.

By Rohit Raj — Founding Engineer · 10+ yrs MVP shipping · LinkedIn

On 15 September 2026, TypeSafe AI released Jev, built by Diogo Almeida — previously at OpenAI and a co-author of the InstructGPT paper. Jev gives up text generation entirely. You hand it a *state* (an email, a support ticket, a JSON blob) plus a list of typed questions, and it returns floating-point numbers: a yes/no with a confidence between 0 and 1, a probability distribution over a fixed set of choices, or a score on a described range. No tokens, no parsing, no JSON.parse in a try/catch.

The capability that changed is not accuracy — it is the shape of the output. A chat model that classifies is a text generator you have coerced into behaving, and the coercion leaks: it hallucinates a category that was not in your enum, it returns "yes." with a trailing period, it drifts when you change the prompt preamble. A decision model cannot produce a type error, because its output space *is* the type. It is also cheap: $0.042 per million input tokens with output unmetered, which TypeSafe puts at roughly $0.0004 per decision, and 70–500ms end to end.

What matters right now is that this stopped being one vendor's product within a week. Jev is a closed API. By 23 September the open-weights replications are real, downloadable, and in several cases genuinely competitive — Convai Innovations' Laya is the #1 trending model on Hugging Face as I write this, and Jared Palmer's Kev has 4.6k GitHub stars. If you were about to wire a paid classification API into the hot path of your product, the honest question is no longer "is Jev good" but "which of these five things should carry my routing decisions, and how would I even tell."

Four serious projects, plus a long tail of weekend reproductions. These are the ones with real numbers attached.

Laya (Convai Innovations, Apache-2.0). A non-autoregressive decision model: 421M parameters on a ModernBERT-large backbone, with a decision head of two transformer layers and an option-marker scorer. Every option is scored at its own [MASK] token, then softmaxed within that question. The multilingual variant swaps in mmBERT-base (322M) and covers 100+ languages. Checkpoint is ~808MB; the multilingual one ~647MB. It reports 32.8ms per question on GPU (tested on a Tesla T4) and 193–464ms on CPU. Accuracy on the typed-decisions benchmark is 0.766 — above its own teacher's 0.735 ceiling, which is the genuinely surprising result here and the reason a 421M encoder is in this conversation at all.

Kev (Jared Palmer, Apache-2.0, 4.6k stars). Three sizes on Qwen3.5 bases: Kev-0.8B, Kev-4B, Kev-9B. Kev-9B scores 0.852 accuracy with a Brier score of 0.237, trailing Jev's 0.857 by half a percentage point. Runs on CUDA, ROCm and Apple Silicon via MLX; the 4B and 9B both fit a 32GB Mac. Five-question requests take tens of milliseconds on an H100. This is the closest thing to a drop-in Jev.

open-alternative-jev (Apache-2.0). Not a model — a layer that extracts typed, calibrated decisions from *any* open-weights LLM with a ChatML template, in one forward pass, via HF or vLLM. Tested against Qwen2.5-0.5B, Qwen3.5-4B and Qwen3.6-27B. On the 400-case typed-decisions benchmark with Qwen3.6-27B it hits 73.7% accuracy at 582ms per case — and an expected calibration error of 0.020. It also reports RACE-H at 92.9% (4.55 questions/sec) and MMLU at 84.2% (6.71 q/s, 12 packed).

openjev (AlexWortega, MIT). A cross-encoder fine-tuned from Qwen3.5-4B-Base doing three-way NLI — entailment, contradiction, neutral — with last-token pooling and plain cross-entropy. MNLI 0.91, ANLI r3 0.63 (up from 0.42), WANLI 0.77 (up from 0.63), image claims 0.84 (up from 0.52), ARC-Challenge reranking 0.72 (up from 0.59). A 35B MoE variant exists on Qwen3.5-35B-A3B. Narrower than the others — it is an NLI model, not a general typed-question engine — but excellent at reranking and grading against a reference.

One table, every figure sourced from the project's own card or README. Where a project does not publish a metric I have left it blank rather than guessing — the blanks are themselves information.

Now read that table twice, because it says two different things depending on which row you sort by.

Sort by accuracy and the ranking is Jev 0.857, Kev-9B 0.852, Laya 0.766, open-alternative-jev 0.737. Kev is the answer; it is within half a point of the commercial model and you can run it on a laptop.

Sort by calibration and the ranking inverts at the top. open-alternative-jev reports an ECE of 0.020 — four times better than Laya's post-fit 0.081, achieved on a Qwen3.6-27B it never trained, purely by reading logits properly in a single forward pass. It is simultaneously the *least* accurate option in the table and the best-calibrated one.

That is not a contradiction, and it is the thing every listicle on this keyword has missed. Accuracy is how often the argmax is right. Calibration is whether a reported 0.7 actually means seven-in-ten. If you are picking a label and displaying it, you want accuracy. If you are routing — auto-approve above 0.9, escalate to a human below 0.6, retry in the middle — you are acting on the *number*, not the label, and a miscalibrated 0.9 quietly routes garbage straight to production. Most decision-model use is routing. So most of the time, the calibration column is the buying criterion and the accuracy column is a tiebreak.

The uncomfortable follow-up: every ECE number above was measured on someone else's benchmark. Yours will differ, sometimes badly, because calibration is a property of the model *and the distribution you feed it*. So measure it. Expected calibration error is twenty lines, no dependencies beyond numpy.

import numpy as np

def ece(probs, labels, n_bins=15):
    """Expected calibration error. probs = confidence of the predicted class."""
    probs, labels = np.asarray(probs), np.asarray(labels)
    edges = np.linspace(0.0, 1.0, n_bins + 1)
    total = 0.0
    for lo, hi in zip(edges[:-1], edges[1:]):
        m = (probs > lo) & (probs <= hi)
        if not m.any():
            continue
        conf = probs[m].mean()        # what the model claimed
        acc = labels[m].mean()        # what actually happened
        total += m.mean() * abs(acc - conf)
    return total

# 300 hand-labelled rows from YOUR queue is enough to rank two models.
print(f"ECE = {ece(model_conf, was_correct):.3f}")

Run that against 300 rows of your own labelled traffic for each candidate and you have a ranking that means something, in an afternoon. Anything under ~0.05 is usable for threshold routing; anything over ~0.15 means your thresholds are fiction.

Then the part that changes the decision entirely. Laya's own card reports ECE dropping from 0.466 to 0.081 — a 5.7× improvement — from a post-hoc temperature fit. That is one scalar, fit on a held-out set, dividing the logits before the softmax:

from scipy.optimize import minimize_scalar
from scipy.special import softmax

def fit_temperature(logits, labels):
    """One scalar, fit on held-out data. Does not touch the weights."""
    def nll(t):
        p = softmax(logits / max(t, 1e-3), axis=-1)
        return -np.log(p[np.arange(len(labels)), labels] + 1e-12).mean()
    return minimize_scalar(nll, bounds=(0.05, 10.0), method="bounded").x

T = fit_temperature(val_logits, val_labels)
calibrated = softmax(test_logits / T, axis=-1)   # same weights, honest numbers

The implication is uncomfortable for anyone shopping this category on a comparison table: a badly calibrated model plus a temperature fit often beats a well-calibrated model you dropped in raw. "Which model" matters less than "did you calibrate on your own distribution," and almost nobody does the second thing because it is not a purchase, it is a Tuesday afternoon.

I would rather lose this argument honestly than sell you a migration you do not need.

Run the arithmetic. Jev costs roughly $0.0004 per decision on TypeSafe's own benchmarks. At 100,000 decisions a month that is $40. At one million, $400. A single always-on A10G on a cloud provider runs an order of magnitude past $400/month before you have written a line of serving code, added a health check, or been paged at 3am because the model pod OOMed during a traffic spike. The crossover is somewhere north of two million decisions a month, and it moves further out if your traffic is spiky, because you pay for the idle GPU and TypeSafe does not.

Laya is the exception that genuinely changes the math, because it runs on CPU at 193–464ms. A 421M encoder on the CPU you are already renting for your API servers has a marginal cost close to zero. If your latency budget tolerates a third of a second, self-hosting Laya is cheap at almost any volume — that is the single strongest practical argument in the open-weights column, and it is the reason the r/LocalLLaMA demo of Laya driving Flappy Bird through OpenVINO INT8 on a CPU got attention.

Pay for Jev when: you are under ~2M decisions/month, your team has no GPU serving experience, or you need the 64k context window (32k of it for state) that none of the encoder-based alternatives come close to.

Self-host when: your data cannot leave your infrastructure (this is the reason that actually wins arguments — a decision model sees every ticket, every email, every document you classify); you need to pin a version forever; you want to fine-tune on your own labels; or your volume is genuinely large.

And be honest about Jev's limits either way. Simon Willison's write-up flags that it does poorly with numbers, dates and adversarial content, offers no interpretability into why a decision came out the way it did, and in his own testing showed unexplained geographic bias — Cupertino rated favourably, East Palo Alto unfavourably. The open-weights models inherit exactly the same class of problem, with the one advantage that you can at least inspect the weights and probe them. None of these models belongs anywhere near a hiring, lending or moderation decision that affects a person without a human in the loop and an audit trail.

Here is the wiring nobody puts in the README, from having built exactly this shape of router before — most recently the classification layer that decides which documents get machine-handled versus queued for review in a compliance workflow.

Do not let the model pick the action. Let it pick a number, and let config pick the action. The thresholds belong in a config file you can change without a deploy, because you will change them in week two when you see the real distribution. Ship with three bands: auto-handle above high, human-queue below low, and cheap-retry-with-more-context in between. That middle band is where a decision model earns its cost, and it is the band most teams forget to build.

Log the probability, not the decision. Every routed item should persist the raw confidence alongside what the system did. Six weeks of that log *is* your calibration dataset — you can re-fit the temperature scalar or swap models with real evidence instead of re-reading benchmark tables. Teams that log only the final label have to start data collection from zero every time they want to change anything.

Shadow-run the replacement before you cut over. Both models score every request; only the incumbent acts. Compare after a week on your traffic. This costs almost nothing when the challenger is a 421M CPU model, and it is the only way to find out that a benchmark-leading model is mediocre on your specific weird distribution of half-formatted vendor emails.

Watch the drift, because calibration rots. Your input distribution moves — a new customer segment, a new template, a product launch — and the temperature scalar you fitted in March stops being right. Re-fit monthly against the logged outcomes. An uncalibrated router does not fail loudly; it quietly starts auto-approving things it should have escalated, and you find out from a customer.

The failure mode I would actually worry about: a decision model that cannot hallucinate *types* can still be confidently wrong about *content*, and because the output is a clean float it looks more trustworthy than a chat model's hedged paragraph. The type safety is real and the epistemic safety is not. Threshold accordingly.

This is the kind of plumbing — probability logging, shadow evaluation, threshold config, drift re-fitting — that turns a weekend model swap into something you can operate. If you are wiring a decision layer into an agent pipeline and want it built properly the first time, that is the work I do as an MCP integration consultant, and it is a natural fit inside a 6-week MVP build.

Q: Is Jev open source? No. Jev is a closed commercial API from TypeSafe AI, released 15 September 2026, priced at $0.042 per million input tokens with output unmetered. The weights are not published. Everything described as an "open Jev" is an independent reproduction of the *interface* and the behaviour, not a release of TypeSafe's model.

Q: Which open-source alternative is closest to Jev? Kev-9B, on accuracy: 0.852 against Jev's 0.857, a gap of half a percentage point, under Apache-2.0. If you care more about honest probabilities than argmax accuracy, open-alternative-jev's ECE of 0.020 is the better match to what Jev is actually selling.

Q: Can these run fully offline, on CPU? Yes. Laya is the strongest CPU option at 193–464ms per question with a ~808MB checkpoint, and has been demonstrated running through OpenVINO INT8. Kev-4B and Kev-9B run on Apple Silicon via MLX and fit in 32GB of unified memory. No network call is required for any of them once the weights are local.

Q: Do I need to retrain a model to get good calibration? Almost never. Temperature scaling fits a single scalar on a held-out set and leaves the weights untouched — Laya reports its ECE falling from 0.466 to 0.081 that way. Fit it on a few hundred rows of your own labelled traffic and re-fit monthly as your inputs drift.

Q: Which of these work with an existing TypeSafe integration? Several of the reproductions expose a /v1/systemone-compatible HTTP schema, so you can repoint your base URL and keep your client code. Verify the confidence semantics before you trust your thresholds, though — the same field name does not guarantee the same calibration behind it.

Q: How many decisions per month justify self-hosting? Roughly two million on GPU, given Jev's ~$0.0004 per decision against a persistently-running accelerator. CPU-only Laya changes this completely — if a third of a second is acceptable latency, self-hosting is cheap at nearly any volume.

The decision-model category is eight days old and already has a credible open-weights tier — that is unusually fast, and it means paying for a closed classification API is now a choice rather than a default.

Pick on calibration, not on the accuracy column everyone quotes. Measure ECE on three hundred rows of your own traffic before you commit to anything. Fit a temperature scalar regardless of which model wins, because it is twenty lines and it is worth more than the gap between most of these models. And if you are under a couple of million decisions a month, paying TypeSafe is very likely the correct engineering answer, which is not a sentence content-farm listicles are incentivised to write.

If you are building the agent or workflow this decision layer sits inside and want it wired with the logging, shadow evaluation and drift handling that make it operable, I take on exactly this work — as a founding engineer for hire for teams building it in-house, or as a scoped build.