Kev and NanoJev: Open Reimplementations of a Jev-Style Decision Head
Two open-source teams rebuilt Jev's typed decision head from scratch. Kev ships three model sizes with published accuracy numbers; NanoJev claims to beat Jev on ViZDoom at 0.6B params.
Jev, TypeSafe AI's typed decision model, is not open-weights. That has not stopped people from building their own. kev and NanoJev are two independent reimplementations of the same idea: a small model that answers a typed question — a choice, a score, a yes/no — in one forward pass, with no token generation. Both ship training code, both ship a benchmark suite, and both publish numbers you can check against your own hardware.
They're also the two most-starred projects in the Jev ecosystem: kev at 5,163 stars and NanoJev at 2,065, as of September 2026, according to the awesome-jev-projects radar. That's a lot of attention for reimplementations of a proprietary API released only weeks earlier. This article covers what each one actually built, what they measured, and where the two designs diverge.
Key Takeaways
- Both attach a scoring head to an open base model rather than fine-tuning it to write JSON — the same architectural bet Jev itself is reported to make.
- kev ships three sizes (0.8B, 4B, 9B) on Qwen3.5, with a published accuracy/latency table down to Apple Silicon.
- NanoJev is a single 0.6B model on Qwen3, and its README reports it beating Jev outright on some ViZDoom tasks — worth reading with real skepticism.
- Neither number set has been independently retested by this site; both come from the authors' own benchmark runs.
- Small evaluation sets. NanoJev's headline comparisons run on sets as small as 8 and 10 episodes — read the deltas as directional, not definitive.
kev: three sizes, a published accuracy table
kev builds on Qwen3.5 with a rank-16 LoRA adapter and what its README calls a "pointer head": a mechanism that scores each candidate option's hidden state against a decision token, then converts those scores to probabilities with softmax. That's what lets one request answer a yes/no, a multiple-choice, and a rating question at once, without generating a token of prose.
Three sizes ship — 0.8B, 4B, and 9B — trained for two epochs on a mix of about 10,000 public examples plus roughly 2,500 generated policy and rule-structure examples the author calls "decision-v7." The published numbers: kev-9B reaches 0.852 accuracy on held-out data with a Brier score of 0.237; the 4B model reaches 0.837. Latency ranges from roughly 120ms on an H100 to 721ms on an Apple M5 for a fresh state. The README also reports calibration error dropping from 0.106 to 0.042 after fitting a temperature parameter — and is upfront that even calibrated, the model is still overconfident on about 4% of wrong answers, against a stated 3.7% for Jev itself. It also flags that fine-tuning degraded date-arithmetic performance versus the base model, and that it was trained on states up to 384 tokens — longer contexts are unverified.
kev is Apache-2.0, listed on aiskill.market as kev.
NanoJev: smaller model, bigger claims
NanoJev takes a different bet: one 0.6B model, built on Qwen3, that batches multiple states and questions into a single forward pass and can score a dynamic candidate set of 2 to 255 options with a shared scoring head — the README's own line is "zero output-token decoding."
The benchmark table is the interesting part, and the reason to read closely rather than skim the headline. On ViZDoom Basic, NanoJev reports 128/128 successes against a stated 56/128 for Jev. On ViZDoom Predict Position it reports 27/128 against Jev's 11/128. But on Maze it reports 4/10 against Jev's 7/10 — NanoJev loses that one — and on Snake it's an 8/8 tie. Training used 18,760 mixed decision examples, including 896 expert gameplay episodes, split across Maze, Snake, Basic, and Predict Position tasks. The README is explicit that these are evaluated on a 274-case test set with a shared observation interface across the systems compared, and that the navigation demos mix learned decisions with hard-coded planning rather than being purely end-to-end.
Two things to hold in mind reading that table: a 4/10 and an 8/8 result are small enough that one flipped run changes the picture, and "beats Jev" here means beats it on this author's own reimplementation of the comparison, not a third-party bakeoff. NanoJev is MIT-licensed, listed on aiskill.market as NanoJev.
Reading two open reimplementations against one closed original
Neither project claims to be a drop-in Jev replacement, and neither exposes the same API surface Jev does — you'd wire either one in as its own thing, not swap it in transparently. What they do share with the original is the core bet this whole series keeps coming back to: a typed, closed-set answer from a small model beats asking a large model to write prose and then parsing it. See typed decisions vs. free-text agents for why that bet tends to pay off on latency and cost even before accuracy enters the picture.
What neither repo gives you is a controlled, apples-to-apples comparison against hosted Jev on your own workload. The accuracy and Brier numbers above come from each author's own held-out sets, using each author's own definition of "held out." That's normal for a young open-source project, and it's also exactly the gap you need to close yourself before trusting either one in production.
What to do next
- If you need this pattern for real work — routing, filtering, gating — read what Jev actually is first, so you know what you're comparing against.
- Run kev's or NanoJev's own eval scripts on your hardware before trusting the published numbers; both ship the code to reproduce them.
- If your interest is games and sim environments specifically, a week of Jev game demos rounds up what this cluster of projects proves and doesn't.
- Track new reimplementations as they land on the awesome-jev-projects radar.