Selectia - build your own Jev

YESMOM is now reborn as Selectia

Some time ago I needed to steer an LLM in AI Harness to fix 3D models in code, or to start a 3D tool (takes ages) and edit it there.

So I was trying to create a YESMOM API with just a YES / NO logit, in AnyJev style.

Then Jev showed up and really expanded that idea. Same trick, much bigger stage: TypeSafe's System One takes a little yes/no logit readout and generalizes it. Instead of two tokens at one slot you get typed questions (Choice, Noul, Score), a probability distribution over whatever options you define, calibrated confidence, and many questions over one shared state in a single pass with no generation. My YESMOM turns out to have been the Noul-only special case sitting inside the full Decision API all along.

So YESMOM is reborn as Selectia: the same one-pass, no-generation readout, grown from a binary gate on tiny LFM2.5 bases into a family that does full typed decisions on the 1.2B and 2.6B. The yes/no head did not disappear, it just got company. The small gate's own story lives in the YESMOM section; the API shape lives in Selectia API.

YESMOM

The first thing that actually worked was YESMOM: one state, one yes/no question, and a number you can trust. Instead of hoping the model writes "yes" or "no", you read the logits for those two tokens at a fixed answer slot and turn their ratio into a probability. The model never generates anything, so the answer cannot wander off.

It stayed deliberately small: only the 230M and 350M LFM2.5 bases, only Noul yes/no questions, no Choice, no Score, no wide label table. That narrowness is the point. A binary gate is a much smaller function than routing or rubric scoring, so the model fits in a few GB of VRAM and trains on a single RTX 4070, which means a reasonably equipped PC can own one.

What is it for? Cheap on-device gates: policy checks, safety, entailment, answerability, a form-fill skip. Ask "does this need a human?", get P(yes), move on. Training runs and benchmark numbers live in The Selectia Way section; this page is yesmom.selectia.dev because this small gate was the start of the whole thing.

Liquid AI LFM 2.5 models

They have a hybrid architecture and they are trained on a very large number of tokens in comparison with their weight.

The hybrid part is concrete: every layer block mixes short double-gated convolutions with plain GQA attention (the 2.6B model is 30 layers, 22 conv + 8 attention), which is why decode stays fast on CPU with a small memory footprint, and on GPU too: the 2.6B reaches almost 15K output tokens per second at high concurrency on a single H100, about 1.3B tokens per day.

Training scale matches the claim: pretraining went from 10T to 28T tokens for the 1.2B family, the 2.6B checkpoint alone got 34T tokens, and post-training adds SFT rounds plus agentic reinforcement learning run inside real agent harnesses.

It is a whole edge family, not one size: 230M / 350M / 1.2B / 2.6B text models, an 8B-A1B MoE, plus VL, audio, encoder and retriever variants, with 128K context and 16 languages on the bigger text models.

Selectia fine-tunes exactly four of them: full typed decisions on the 2.6B and 1.2B, YESMOM (Noul only) on the 350M and 230M. Pretraining budget, vocabulary size and context window per base:

LFM2.5-2.6B-Base - 34T training tokens, vocabulary 128,000, context window 131,072 tokens (128K) on the model card (config says max_position_embeddings 128,000); the long length comes from a dedicated mid-training context-extension phase, the LFM2 predecessor shipped 32K, and rope stays type "default" so nothing is stretched at inference time
LFM2.5-1.2B-Base - 28T training tokens, vocabulary 65,536, context window 32,768 tokens
LFM2.5-350M-Base - 28T training tokens, vocabulary 65,536, context window 32,768 tokens
LFM2.5-230M-Base - 28T training tokens, vocabulary 65,536, context window 32,768 tokens

Runs where you need it: day-zero support for llama.cpp (GGUF), MLX, vLLM, ONNX and Liquid's own LEAP; about 220 tok/s decode on an M5 Max and 113 tok/s on a Ryzen CPU in under 2.5 GB of memory.

Minus - not OSI open source: the custom LFM Open License v1.0 (tagged lfm1.0 on Hugging Face) lets you download, fine-tune and use the models commercially only while your legal entity's annual revenue stays under $10,000,000; at $10M or more, commercial use is simply not licensed, and qualified non-profits are exempt for non-commercial or research use.

So can we use LFM models to create our own Jev-like models?

Smaller Qwen models (under 8B?) are distilled models. LiquidAI LFM models are in opposite built for embedded edge use cases, so they can take advantage of wider knowledge.

They are small enough so we can retrain them on 4070 / 4090 hardware, so a reasonably equipped PC gamer can experiment with them.

Rumor corner: the unofficial probing of Jev puts it in the sparse MoE camp, with latency that fits roughly a 10B-class mixture of experts rather than a dense frontier model (see the architecture speculations). If that is the shape of the real thing, the closest we can get today on the open side is LFM2.5-8B-A1B: an edge-optimized 8.3 billion parameter Mixture-of-Experts (MoE) hybrid model by Liquid AI that activates only about 1.5 billion parameters per token for fast on-device inference. Same MoE + GQA + short-conv family as the dense LFM2.5 bases we already fine-tune, 38T training tokens, 128K context, and a base checkpoint published for exactly this kind of repurposing.

So yes, within the limits of what is public: it is the right size class, the right sparse shape, and the right edge deployment story to stand in for a rumored Jev backbone. What it does not ship with is the System One part: no RLCD, no calibrated decision training, no letter-logit readout. That is still our job, the same Selectia recipe, just pointed at the MoE base instead of the dense 2.6B. The catch is hardware: 1.5B active means it already runs anywhere (253 tok/s on an M5 Max, under 6 GB), but a full fine-tune still stores 8.3B of weights plus optimizer state, so training wants an 80 GB or larger card.

For repo see: github.com AISidesKicks selectia.

What is Jev

It's not a Decision per se model, it helps you make one (it's like IF but still not 100% predictable) - because it's still too random, so you must decide based on 3 classification types.

Jev is still a model, it's still just an AI model!

Officially: Jev is TypeSafe's first System One model. The class name comes from Kahneman's fast, intuitive System 1 thinking, and Jev itself is named after William Stanley Jevons, because TypeSafe expects cheap intelligence to work like cheap coal: every order of magnitude drop in cost unlocks a new pile of use cases.

The pitch in one line is a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out. You send text, JSON or arrays plus questions built from three primitives (Choice, Noul, Score), and you get typed answers with calibrated probabilities back in 70ms to 500ms, all probabilities sampled in one parallel query instead of written token by token. Output tokens are billed as free, because there are none to speak of, and since the answer space is defined in advance the model cannot make a type error or wander into free text.

Training is TypeSafe's own RLCD (Reinforcement Learning for Calibrated Decisions), aimed at epistemically honest probabilities on System One tasks rather than at human-preferred prose. It is early access, closed weights, no paper and no parameter count published, which is exactly why this page and the whole clone scene around it exist: everyone is rebuilding the idea in the open because the original will not show its work.

Unofficial Jev architecture speculations (no official paper yet)

TypeSafe published no paper, no layer counts, no base model name. The best public reconstruction is Jev's architecture unmasked (archerhume.com), built from about 10,000 probed API calls. Everything below is speculation, sorted from strongest evidence to pure guess.

Readout, not a decode loop (strong). The API still reports an output_tokens field, but it is a billing figure: the count tracks text the model never sees, a 200-option answer returns as fast as a two-option one, and server time grows with input length, not with "generation". TypeSafe says outright that Jev outputs all probabilities in parallel instead of autoregressively generating by token. The computation ends at prefill plus a readout over the answer slot.

Shared state, isolated question branches (strong). Token accounting is exactly additive (common prefix plus per-question suffixes), and moving a secret code from one question to the sibling changed nothing (probability 0.00) while putting it in the shared state jumped it to about 0.90. Request limits fit one packed sequence: roughly 65k tokens for the whole request counting the state once, about 32k per state-plus-question branch. Fifty questions on one long incident report would be over 100 million tokens if each branch re-read the state, so the natural design is a prefix KV cache with batched, mutually blind suffixes. Prior art for that serving pattern exists (Hydragen, DeFT); that does not prove TypeSafe uses it.

A causal transformer of unknown origin (medium). Breadth like 84.6% MMLU-Pro needs frontier-scale pretraining, every model at that scale is a causal decoder, and TypeSafe describes RLCD as post-training a pretrained language model. The tokenizer matches none of 192 public tokenizers probed (Qwen is closest at 348 of 415 checks), which rules out an unchanged public tokenizer, not a public base: a replaced vocabulary or continued pretraining would look the same.

Options interact before choosing (medium). Appending an irrelevant fifth option ("bad weather caused it") shifted the log-odds between two existing options from about +0.38 to +0.11, a decrease in all ten randomised blocks. Fixed independent logits plus one softmax cannot do that, because the shared denominator cancels. A reference card hidden after the candidate list still works (16 of 16 when placed last), so the decision reads the full option list: either a final-position slot head or a pointer-style scorer over each option, and the API's 255-option cap is request validation, not a model limit.

RLCD trains the distribution, confidence is arithmetic (medium). Calibration on a 1,200-item MMLU sample came out at ECE 0.031. Separately, the official adapter computes the Choice confidence field as (pmax - 1/K) / (1 - 1/K), pure math over the returned distribution, not a second learned estimate. The distribution is the trained object; the confidence field is a summary of it.

Sparse MoE backbone (weakest, a guess). About 30k tokens processed in roughly 160ms fits a MoE with around 10B active parameters, not a dense 70B, and prefill-only serving removes most of MoE's usual decode costs. Nothing else in the reconstruction depends on it: swap in a dense transformer and the interface, sharing, isolation and readout all still stand. TypeSafe could settle every open question tomorrow with a tech report; until then, grain of salt.

What alternatives we have

From the ML world: BERT-like systems like Layla. From the LLM world: decider.

Zooming out, the high-level solutions (alternative approaches) to "I need typed decisions with probabilities" today:

Multi-label BERT style - Layla: classic encoder classifiers, one sigmoid head per label, cheap and boring; no generation, but also no shared-state multi-question readout, so you wire one classifier per decision yourself.
Buy the original - TypeSafe's Jev: closed weights, RLCD-trained, fastest route if you only need the API and accept the dependency.
Train your own clone - open fine-tune pipelines on small bases, decider on Qwen3.5 (our pick) or Selectia on LFM2.5: full control and in-house calibration, costs GPU days.
Read a frozen model, no training - SemIf, ruling: options defined per request, logits scored once, optional temperature; cheapest to keep alive, weaker calibration than a real fine-tune.
Diffusion readout - open-jev on DiffusionGemma: denoise a fixed canvas, then read answer logits; a different compute shape, zero training.
Tiny scorer heads - jevlike, NanoJev: educational starters or domain-specific control, not a general routing model.
Prompt a frontier LLM anyway - JSON schema or constrained decoding (TypeSafe ships an adapter that forces other LLMs into the same wire format): you get general intelligence, but generation cost, latency and "confidence" written as text stay your problem.
Plain binary gates - when the decision really is yes/no, a YESMOM-style Noul head or any calibrated yes/no classifier is the whole solution, no Choice table needed.

Maps of the ecosystem:

The Selectia Way

Trained part, see github

YESMOM, the technical part: trained on 38.9M tokens of class-balanced Noul data (279,032 rows, half yes / half no), yesmom-230m in about 35 minutes and yesmom-350m in about 47 on one RTX 4070 at 3-4 GB VRAM. The product gates improved with size on thousands of items each: abstain 0.720 to 0.841, off-topic 0.673 to 0.838. On JevBench's 74 public Noul items accuracy sits within noise (plus or minus 0.11) but ECE more than halves against the own bases (0.383 to 0.179 on the 230M, 0.221 to 0.151 on the 350M). The saved config sets yesmom: true, so the runtime answers with P(yes) and rejects Choice and Score questions outright. From that binary head the rest of Selectia grew: the same readout generalized from two tokens to the full typed Decision API on the 1.2B and 2.6B bases.

Selectia Decision API

Selectia is a family of System One-style models fine-tuned from LFM 2.5, designed for one-pass typed decisions with calibrated probabilities. The Decision API (Choice, Noul, Score) is powered by open LLMs. For repo see: github.com AISidesKicks/selectia.

You give it a state (any text or JSON) and a set of typed questions; one forward pass later you get a probability distribution per question over its own options. No decoding, no parsing, no generated text, and no answer outside the options you defined.

The three question types, exactly the System One primitives:

Choice - options come from the criteria keys at request time, rendered as narrow (A)..(J) letters or wide single-token labels up to 255; a null description renders as a bare label.
Score - 2 to 10 ordered levels, or a numbered legend; the full models turn on isolated_levels, so each level is scored alone and never sees its own number or its neighbours, and fit_mass tells you when no level, or several, fit.
Noul - the yes/no head YESMOM uses, returns P(yes); criteria are optional.

How the readout works: every question gets an answer slot like "... Answer 2: (", the hidden state at that slot is projected onto the lm_head rows of the single-token option labels, invalid options are masked to -inf before the softmax, and a fitted temperature from selectia_config.json is the calibration control. Because nothing is generated, all N questions cost one forward pass and question order cannot change any answer.

Answers come back typed and normalized: choice plus confidence, certainty and a full probabilities map; score plus the legend; noul as P(yes). Two shapes of model serve it: full typed decisions on the 2.6B / 1.2B (up to 255 labels), and YESMOM on the 350M / 230M (Noul only, rejects everything else).

Two consequences worth knowing: each option label must be a single token in the tokenizer (all four LFM2.5 tokenizers supply the full 255), and these are full fine-tunes, not prompted general models with a grammar constraint.

Benchmarks / JevBench

The map we use for decision models, plus what our own JevBench runs have taught us so far:

Lesson 1: accuracy and calibration are different products. Our 2.6B base beat the 1.2B on JevBench public accuracy (0.541 vs 0.338) yet was worse calibrated on the hard tier (ECE 0.316 vs 0.210), so it is confidently wrong more often. One fitted temperature per checkpoint, around 2.3 to 2.5 on every base, cut ECE 2.5x to 3x without touching a single weight. A leaderboard number alone never tells you whether you can trust the probability that comes with it.

Lesson 2: more training is not automatically better calibration. The 55 minute teacher-only run doubled JevBench accuracy (0.338 to 0.628) but pushed the hard tier deeper into confident wrongness (ECE 0.210 to 0.343). Only the full 695,795 example mixture fixed it: overall ECE landed at 0.113, hard Brier matched the base again, and the fitted temperature fell from 2.50 to 1.55, which says the overconfidence was mostly gone. The held-out calibration gate in the plan earned its keep there.

Lesson 3: some tasks are shape-limited, not size-limited, and small slices are noise. The easy tier saturates at 1.000 after a short run, so it stops discriminating between models; meanwhile paws, tweet_hate, wic and msmarco_rel sit at or below chance for both 230M and 350M identically, which means the prompt shape fails, not the parameter count. JevBench also only publishes 231 of its 534 decisions, and only 74 of those are Noul, so accuracy on that subset moves plus or minus 0.11 and the thousands-item regression gates are where the real signal lives.

Jev-like systems with LLMs

Good map of the September clone wave: I read 7 clones of Jev (note.com). Short version below, each one next to decider. BERT-style encoder clones are left out on purpose.

decider - Mapika/decider (I choose this one) - family of Qwen3.5 fine-tunes (0.8B up to 35B MoE) trained on ~95 public decision datasets plus labels from a local 27B teacher, nothing distilled from Jev. One forward pass reads letter logits per question, serves TypeSafe's wire format, and the 2B got a calibration RL stage. It is the most complete "train your own" pipeline of the group; on JevBench the 35B sits mid-table because cost and calibration drag the geometric mean, same weak spots as the rest.

Kev - jaredpalmer/kev - small Qwen3.5 family (0.8B/4B/9B) with LoRA plus a pointer head and the only serious question isolation (block-causal mask, questions cannot see each other). Trained on a public ~10k-example suite with per-checkpoint temperature; 9B hits 0.852 on new sources vs Jev 0.857. vs decider: narrower data and no RL stage, but cleaner architecture fidelity to Archer Hume's writeup and a polished playground; decider wins on breadth and open training code.

SemIf - TheoLeeCJ/SemIf - no training: frozen Qwen3.5-4B (or smaller/bigger) reads option logits at request time, criteria defined per call, shared state prefetched once. JevBench #2 overall, but calibration (72.6) still well under Jev (82.7). vs decider: zero recipe to maintain and trivial to run, where decider ships a whole mixture + server; same "no generation" trick, opposite end of the effort spectrum.

Bespoke Nimble - bespokelabsai/nimble - Qwen3.5-9B + LoRA trained on only 2,676 contrastive pairs (near-identical examples, one fact flips the label) plus a fitted temperature. Scores 90.1% on its own 324-example holdout vs Jev 93.2%. vs decider: tiny but carefully curated data instead of decider's million-example epoch; great data-curation recipe, narrow domains, ~18 GB to run.

ruling - bradAGI/ruling - default is no training: any open chat model, state encoded once, option-letter logits averaged over 3 cyclic orderings to kill position bias, optional LoRA + cascade (can even escalate to typesafe:jev-latest). On TypeSafe's 102 rows the 35B scores 0.892 vs Jev 0.882 (difference not significant). vs decider: debiases after the read instead of training calibration in; Mac/MLX-first, one request at a time.

jevlike - vinnylarouge/jevlike - research starter: option-attention scorer over byte embeddings or a frozen encoder, not a full LLM fine-tune; ~98% on synthetic menus, 26-29% on Wikispeedia vs ~8% controls. Author says "research starter, not a copy of Jev". vs decider: teaches the readout idea cheaply, nowhere near production accuracy; the jevbetter follow-up trades ~115x throughput for better calibration.

NanoJev - TianyuCodings/NanoJev - Qwen3-0.6B with decision heads, open weights/data/pipeline, aimed at game and agent control (ViZDoom, maze, snake) with dynamic 2-255 candidates; beats Jev on some game tasks. vs decider: domain-specific control decisions rather than general judgment; smaller, task-tuned, not a Jev replacement for text routing.

More to map here (TBD).

Diffusions, Gemma style

Same survey also separates the diffusion clones properly: note.com clone review. Two real projects, both zero-training on DiffusionGemma - different bet from decider's trained causal models.

JoshuaSP/open-jev - JoshuaSP/open-jev - DiffusionGemma-26B denoises a fixed JSON canvas, then final logits pick allowed answer tokens; no training. On 337 public Jev questions: 86.1% (1 step) / 87.8% (2 steps) vs saved Jev 90.8%, with grouped 2-step ~4.85x faster / ~79% cheaper than naive per-question runs. vs decider: diffusion readout instead of one-pass letter logits, solid public-set accuracy, probabilities explicitly uncalibrated.

razorback16/openjev - razorback16/openjev - Jev-wire-compatible server on DiffusionGemma NVFP4 via vLLM (PR #57250) or MLX on Mac; adds images, steps, samples, think; TypeSafe SDK works unchanged; throughput numbers (up to ~57 req/s) but no published accuracy table. Apache-2.0. vs decider: infra/serving play around a diffusion backbone vs decider's trained weights; both drop into the same System One API.

Inspiro

Videos that inspired this page:

System 1 vs System 2 Explained

Every Jev Concept Explained (use with Claude)

Build Your Own Jev With Claude Opus 5.5

Futures

Jev-style decisions are moving from text to images: same one-pass candidate readout, but the state is a picture and several questions usually share it. Three projects map that corner so far.

Visual Jev - arxiv.org/html/2609.25845v1 (paper under review), project page, guanxuyu-sv/Visual-Jev - the research writeup: Qwen3-VL-4B/8B with a frozen vision tower and LoRA on the language side, image encoded once, isolated question suffixes run as one batch, probabilities read from the plain LM head. Answer SFT lifts four-benchmark macro accuracy 0.706 to 0.761, but only on the two trained families (GQA, SNLI-VE); held-out TextVQA and TallyQA barely move. A matched typed decision head scores the same as the LM head, so the simple readout wins. At 32 questions per image the shared batched path is 8.9x faster than serial (176 vs 20 questions/s) for about 1.7 GiB extra peak memory; at N=1 sharing is slower. Their evidence-sufficiency head detects removed evidence yet still costs accuracy, a useful negative result.

visual-jev (andrueandersoncs) - andrueandersoncs/visual-jev - the production-shaped take: Qwen3-VL backbone, isolated packed question branches, a learned pointer head with LoRA and held-out temperature calibration, serving choice/score/noul without generating answer text. Candidate-token scoring stays available only as an explicit uncalibrated baseline, the server fails closed on missing or mismatched checkpoints, and the ops guide includes an exact-input comparison against pinned OpenJev. Still early, but the closest thing to a Jev-style vision server.

jev-visual (hr98w) - hr98w/jev-visual - the educational one for Apple Silicon: MLX plus Qwen3.5-0.8B-4bit, no training at all, shared multimodal prefill then direct candidate scoring for choice/noul/score, with a local browser UI and game demos (sorting lanes, breakout by region, camera gestures). On an M4 it cut 64 decisions from 37.3s independent to 2.4s shared, and generated JSON failed its own schema at 4 decisions and up, which is the generation-vs-readout argument in one number. MIT, openly not a reproduction of TypeSafe's architecture or calibration.

vs Selectia: the readout and isolation ideas port directly, and LFM2.5 already ships VL sizes (450M / 1.6B / 3B), so a vision YESMOM gate on a small VL base is the natural next experiment once the text mixture is settled.