A generated title card reading "Jev vs Kev" over the subtitle "A $95 fine-tune that beats Jev on support tickets", contrasting Jev (closed, hosted, undisclosed architecture, $0.042 per million input, output free) against Kev (Apache 2.0, Qwen3.5 base, 0.8B to 9B, about $95 in H100 time).
Engineering & Research

Jev vs Kev: A $95 Fine-Tune That Beats Jev on Support Tickets

Author

Alistair Wren

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

Jared Palmer released Kev on September 20, 2026, five days after TypeSafe AI launched Jev, and the important number is not in the benchmark table. It is in the README: the whole thing cost about $95 in H100 time on Modal, plus three cents of Jev API calls used to generate evaluation data. Kev is Apache-2.0, self-hostable, and comes in three sizes built on the open Qwe​n3.5 base weights — roughly 0.8B, 4B, and 9B — with a rank-16 LoRA adapter and a pointer head bolted onto a frozen base rather than a from-scratch decision model. It mirrors Jev's typed-decision API exactly: Choice, Score, and Noul, close enough to be compatible with TypeSafe's own Python SDK. Jev, for its part, launched September 15, 2026 as TypeSafe AI's closed, hosted System One model, returns typed answers with calibrated confidence and no text at all, and has never published its architecture, parameter count, training compute, or weights. The comparison is therefore not really a model comparison. It is a test of how much of Jev's value survives being reproduced in an afternoon for the price of a used laptop. Neither model is new — Jev 1.13 (typesafe/jev-1.13) is the September 15 release and Kev followed five days later — but one thing about this comparison did change recently: on September 24, 2026, OrcaRouter added Jev 1.13 to its catalogue, so the decision half of the pairing now answers on the same key as the generative half instead of only through the vendor's own endpoint.

What the benchmarks actually say

A screenshot of the TypeSafe AI documentation for Jev, showing the typed Choice, Score and Noul primitives, the calibrated probability returned with every answer, free output, and the roughly 32,000-token request budget with a 255-option Choice cap.

The headline is that Kev gets close, and on one narrow task it wins. On Kev's locked new-source test set, Kev-9B scored 0.837 against Jev's 0.857. On support-ticket routing across 900 tickets — the scienthoon set — Kev-9B scored 0.952 against Jev's 0.897, which is the one published result where the open reproduction beats the model it reproduces. Kev also edges ahead on some logic-recognition tasks. On SemiF decision sets, a 144-question structured set, Jev takes it 0.965 to Kev-9B's 0.917.

Where Kev loses, it loses badly. Out-of-domain accuracy: Kev-8B at 79.6% against Jev's 85.7%. MMLU: 70% against 90%. MMLU-Pro: 0.515 against 0.840. Date arithmetic at day precision: 60% against 93%. The pattern is consistent — Kev is competitive on narrow routing and classification where the label set is small and the domain is fixed, and it falls apart on anything that needs world knowledge or multi-step arithmetic, because a rank-16 adapter on a frozen small base model is not where world knowledge lives.

Every one of those figures comes from Kev's own harness or from third-party trackers, and Palmer's README says plainly that it is not a controlled comparison — Jev's training data is undisclosed, so there is no way to build one. The README also states that no Jev outputs were used for training. Both disclaimers are the kind that make the numbers more trustworthy, not less: the person publishing the comparison is the one telling you what it cannot prove.

What you get for $95 that you cannot get from Jev at any price

A screenshot of the Kev repository page for jaredpalmer/kev, showing the Apache-2.0 licence, the Qwen3.5 base weights, the rank-16 LoRA and pointer-head recipe, the about-$95 H100 training cost, and the README statement that no Jev outputs were used for training.

The cost comparison is where the two products stop being comparable at all. Jev is $0.042 per million input tokens with output free — the rate on TypeSafe's own price sheet, and the one our model card for typesafe/jev-1.13 carries — which is cheap in a way that is genuinely hard to beat on a per-call basis. It is a hosted API, and TypeSafe's own homepage still describes it as in early access; that is the vendor's own wording, and the waitlist that used to sit behind it is gone — TypeSafe removed it on September 21, 2026, and what its model documentation publishes now instead is the serving limit itself: 100,000 tokens per second and 40 requests per second per account, adjusted dynamically and subject to change without notice. Kev is weights you download. The marginal cost of the ten-millionth classification is your own electricity.

Four things follow from that and none of them are about benchmark scores.

• No data leaves your infrastructure. Jev is a hosted endpoint; every state you send it — the support ticket, the log line, the medical record — goes to TypeSafe. Kev runs on your own GPU, which for regulated workloads is not a preference but the deciding factor.

• No third-party rate limits, no gated access, no deprecation risk. TypeSafe's own documentation reserves the right to adjust those published limits at any time, which is a real difference from a checkpoint on your own disk. A local checkpoint has no such clause.

• You can fine-tune it. Kev is a base to specialise, and the LoRA recipe that produced it is public. If your routing taxonomy has 40 classes that no general model handles well, you can train on your own labels — which is exactly what Palmer did, at a cost measured in tens of dollars rather than in an ML team.

• The context ceiling is yours to change. Jev's documented request budget is 64K tokens, of which 32,000 is the state plus the single longest question rather than a separate allowance, and Choice fields cap at 255 options. Kev inherits Qwe​n3.5's window, which is far larger, and the option cap is an implementation detail of your own serving stack rather than a vendor limit.

What Jev still has that Kev does not

The calibration claim is the one that does not transfer cleanly, and it is the heart of TypeSafe's pitch. Jev is trained with a method TypeSafe calls RLCD — Reinforcement Learning for Calibrated Decisions — which optimises for the confidence value being honest rather than for the answer being preferred. Every Jev answer ships with a probability distribution over the options, so your code can set thresholds: act automatically at the top band, flag in the middle, escalate at the bottom.

Kev produces the same typed shape and the same probability outputs, because the API is deliberately compatible. Whether those probabilities are calibrated is a different question, and the honest answer is that nobody has published a reliability diagram for either model. A separate calibration audit reported Jev scoring 44.7% accuracy with an expected calibration error of 0.325 on a hidden-policy priority task, which suggests calibration on Jev varies sharply by task rather than being a universal property — and TypeSafe itself tells users to test confidence thresholds against their own labelled examples rather than trusting the published behaviour.

The other thing Jev has is that it was not trained on Qwe​n3.5. A 9B model with a rank-16 adapter has a knowledge ceiling, and the MMLU-Pro gap of 0.515 against 0.840 is that ceiling made visible. If your routing decision occasionally requires knowing what a thing is, Jev's larger undisclosed architecture is doing work that Kev's adapter cannot.

Latency and the deployment shape

Jev's documented end-to-end latency is 70–500ms against 3–329 seconds for frontier LLM calls in TypeSafe's own comparison, and adding questions to a call barely moves it because every question is evaluated in parallel against one shared read of the state. There is one measured counterpart to that vendor claim, and it is ours rather than TypeSafe's: across the seven days our model card for typesafe/jev-1.13 has been serving the model, from September 24, 2026, the median request took 151 ms and the 95th percentile 247 ms. That is a serving record of one route, not a benchmark. Kev-9B on an H100 will be in the same order of magnitude for a single forward pass, but the comparison is not apples to apples in either direction: a self-hosted 9B on a shared GPU under load is not the same latency as a hosted endpoint, and a hosted endpoint is not the same as a box in your own rack. What can be said without hedging is that both are fast enough for per-turn use in an agent loop, and that Kev's latency is a function of hardware you control rather than a service level you are promised.

The honest read on the reproduction

The fact that Kev exists at all is evidence about Jev, and it is worth naming. A closed model whose behaviour can be approximated in five days for $95, by one person, on public base weights, is telling you something about how much of its advantage is architecture and how much is training data and serving. It does not follow that Jev is easy to build — the API surface is easy to copy, and the calibration is not. But it does mean the moat is not the interface, and anyone evaluating Jev for a production path should price in the possibility that a fine-tune of an open base gets them most of the way for a fraction of the commitment.

Which is also the argument for not betting a production path on either one yet. If you are evaluating Jev, the sensible posture is to try it without committing to it — and since September 24, 2026 that is something you can do on our key: OrcaRouter serves Jev 1.13 as typesafe/jev-1.13, called through the same POST /v1/systemone endpoint and the same non-streaming request shape it uses everywhere, against a 65,536-token context at $0.042 per million input tokens with output billed at zero. The decision layer and the generative layer now sit on one account: 200+ models behind one OpenAI-compatible key at provider list price passed through with 0% markup, with automatic failover. A two-model architecture where a cheap decision layer sorts traffic and a generative model handles the remainder is testable on our side without a second vendor contract, and if the decision component turns out to be badly calibrated on your data, the failover path is what stops that from becoming an incident.

The verdict

If your decision task is narrow, fixed-domain, high-volume, and privacy-sensitive, Kev is the more defensible choice today and it is not close — you own the weights, you control the data path, you can fine-tune on your own labels, and on support-ticket routing the 9B checkpoint already beats Jev on its own published numbers. If your decision task needs world knowledge, multi-step arithmetic, or a confidence value you intend to automate against, Jev's larger undisclosed model and its RLCD training are doing real work and Kev's adapter is not a substitute for either.

The one thing neither comparison settles is calibration, because nobody has published a reliability diagram for either model. Test that on your own labelled cases before you automate against either — the confidence value is the part of both products that has to be earned per deployment, and the speed is the part that is already commoditised.

A generated two-column scoreboard comparing Jev and Kev across the same six labelled dimensions, with a footer reading "Kev figures per its own README and harness; not a controlled comparison."