What Is Jev? System One Models Explained

The core recipe has barely changed in twenty years: turn text into a vector, then map that vector to label probabilities. What changed is how good the vector is, and, with Jev, whether you need to train anything at all.

Knowing what came before makes it easier to see what is actually new.

Bag-of-words: counting words

The earliest practical approach simply counts words. Build a vocabulary of, say, 50,000 words, and represent each document as a 50,000-long vector of word counts. A logistic regression model then learns that “refund” and “charged” push toward billing, while “crash” and “error” push toward technical.

It is cheap and still a strong baseline. Its weakness is that word order disappears: “the dog bit the man” and “the man bit the dog” become identical vectors.

Embeddings, RNNs and CNNs: reading in order

Word embeddings replaced counts with dense vectors that capture meaning, so “refund” and “reimbursement” end up close together. Recurrent networks (RNNs and LSTMs) read text one word at a time and carry a running summary. Convolutional networks slide small filters over neighbouring words. Both keep word order, but when trained from scratch on a small dataset, they are not automatically better than counting words.

Pre-training and transformers: borrowing knowledge

The big leap came from transfer learning: first pre-train a model on huge amounts of general text, then fine-tune it on your task. ULMFiT did this with an LSTM in 2018, and BERT did it with a transformer the same year.

For classification, you add a small classification head on top of the pre-trained model: a single layer that maps its output vector to one score per class. Then you fine-tune. Modern versions such as ModernBERT remain the go-to choice for fast, accurate, task-specific classifiers.

LLMs: classification by asking

Large decoder models like GPT made it possible to classify without any training: just ask “Is this review positive or negative?” in plain English. This is enormously flexible, but you are running a text generator to produce one word, and you then have to parse that word back out.

Comparing the approaches on one dataset

How do these approaches compare in practice? An independent comparison ran most of them on the same benchmark: 25,000 IMDb movie reviews labelled positive or negative (Raschka, 2026).

[FIGURE 1: Dot plot of IMDb sentiment accuracy by approach, from bag-of-words to Jev. Caption: “IMDb results from Raschka (2026); ULMFiT from Howard & Ruder (2018); ModernBERT and GPT-2 values approximate as reported.”]

Two things stand out. First, the specialist models trained on IMDb itself top out at around 95% accuracy. Second, Jev reaches 96.47% zero-shot, meaning without seeing a single IMDb training example. Classifying the full 25,000-review test set through the API cost about $0.65 and took about 22 minutes.

This result needs careful reading. Nobody outside TypeSafe knows whether IMDb was part of Jev’s training data, and a better-tuned ModernBERT could likely close the gap. So the takeaway is not “Jev is the most accurate sentiment model.” It is that one general model, with no task-specific training, matched the specialists, and the same API can then be pointed at a completely different task.

TypeSafe has not published how Jev works. But you can build a model with the same API from standard parts: a pre-trained encoder that scores each candidate answer separately, followed by a softmax across the scores.

TypeSafe has not released a paper, a model card or weights for Jev. What it has said is that Jev uses a new architecture, a parallel sampler and a new training method called Reinforcement Learning for Calibrated Decisions (RLCD), and that all of its training data is synthetic (TypeSafe AI).

So rather than guess at Jev’s exact design, let’s work out how you could build a model with the same interface. Most of the pieces come straight from the history above.

Why a normal classification head doesn’t work

A standard fine-tuned classifier has a head with one output per class. Train it for billing, technical and account, and it has exactly three outputs, forever. Add a fourth team and you need a new head and a new training run.

That is the opposite of what we want. In a System One model, the options must be defined at request time.

The trick: score one option at a time

The fix is to give the model a head with just one output node and to feed it one candidate option at a time. If this sounds familiar, it is essentially how BERT-style models have long handled multiple-choice questions.

[FIGURE 3: Option-scoring diagram. Three inputs (state + instruction + option), one shared encoder, one shared 1-node head, three scores, one softmax, three probabilities. Caption: “A shared single-output head scores each option; softmax turns the scores into Choice probabilities. The open-weights Laya model uses a similar design.”]

Step by step:

1. Build one input per option: the state, the instruction, and that option’s name and description.
2. Encode each input with the same pre-trained transformer (for example a BERT-style encoder) to get a vector h that summarizes it.
3. Score each vector with a tiny linear layer that outputs a single number: s = w · h + b. This is really just logistic regression on top of the encoder.
4. Apply softmax across the scores, so they become probabilities that sum to 1.

Because the same weights score every option, you can send two options or two hundred, with any wording, and nothing in the architecture changes. And because the inputs are independent, they can all be processed as one batch in a single forward pass.

A minimal sketch in PyTorch

Here is the whole idea in about twenty lines. The head is untrained, so its outputs are meaningless until you train it, but the shape is exactly that of the Choice API:

import torch
import torch.nn as nn
from transformers import AutoModel, AutoTokenizer

class OptionScorer(nn.Module):
    def __init__(self, backbone="answerdotai/ModernBERT-base"):
        super().__init__()
        self.encoder = AutoModel.from_pretrained(backbone)
        self.head = nn.Linear(self.encoder.config.hidden_size, 1)  # one output node

    def forward(self, input_ids, attention_mask):
        # One row per candidate option: (num_options, seq_len)
        hidden = self.encoder(input_ids=input_ids,
                              attention_mask=attention_mask).last_hidden_state
        h = hidden[:, 0]                      # [CLS] vector per option
        scores = self.head(h).squeeze(-1)     # (num_options,)
        return torch.softmax(scores, dim=0)   # probabilities over options

tok = AutoTokenizer.from_pretrained("answerdotai/ModernBERT-base")
state = "We were billed twice for March. Please refund the duplicate."
instruction = "Which team should handle this ticket?"
options = {"billing": "Invoices, charges, refunds",
           "technical": "Bugs, outages, errors",
           "account": "Login, seats, settings"}

texts = [f"{state}{tok.sep_token}{instruction}{tok.sep_token}{k}: {v}"
         for k, v in options.items()]
batch = tok(texts, padding=True, return_tensors="pt")
probs = OptionScorer()(batch["input_ids"], batch["attention_mask"])
print(dict(zip(options, probs.tolist())))

Training is standard: for each example, compute the cross-entropy between these probabilities and the correct option, then update both the encoder and the head.

The other two primitives follow naturally. A Noul can be the same model with a sigmoid on a single score. A Score can be a Choice over ordered levels, where you report the expected level.

Why is this so much faster than an LLM?

An autoregressive LLM needs one full forward pass per generated token, one after another, and reasoning models may generate hundreds or thousands of tokens before the answer. The scorer above needs one batched forward pass with no generation at all, and an encoder with a few hundred million parameters is small by today’s standards.

That is the whole speed story in one line: fewer, smaller, parallel passes.

If it’s this simple, why can’t everyone build Jev?

Building the API is easy, as the sketch shows. Making it work well across very different tasks, zero-shot, is the hard part. That depends on the training data and the training objective, which is exactly where TypeSafe says it invested: synthetic data at scale, plus a reinforcement-learning objective that rewards calibrated probabilities.

The open-weights model Laya shows the design is feasible. It pairs a ModernBERT-large backbone with a small decision head (421M parameters in total), scores and softmaxes each option, and uses RL-style training on proper scoring rules (Laya model card). Whether Jev works the same way is unknown.