Jev, Explained Simply

An AI that ticks boxes instead of writing sentences, and tells you how sure it is about each tick. What Jev is, where it earns its place, and where it is confidently wrong.

The short version

Jev is an AI that answers multiple-choice questions instead of writing essays. You hand it some text and an answer sheet you printed yourself. It ticks the boxes and tells you how sure it is about each tick.

It was released on 15 September 2026 by TypeSafe AI. It answers in about a fifth of a second, costs almost nothing per question, and cannot write a single sentence. It is built to sit inside software, not to chat with people.

How to read this guide. Plain words come first. Jev's own word follows in brackets, like this: the text you hand over (state). If you only remember the plain words, you have understood it. The bracket words are there so you can read TypeSafe's documentation afterwards.

What Jev is

Jev is a well-read clerk who is only allowed to fill in a form. Picture two people in an office.

The first is a brilliant writer. Ask her anything and she hands you a page of prose. That is ChatGPT, Claude, Gemini. The trouble starts when the reader is a computer program rather than a person, because a program cannot read a page of prose. It needs a tick in a box.

The second person has read just as many books, but works differently. You give him a letter and a form you designed. He may only tick boxes you printed. He cannot add a box, and he cannot write in the margin. Next to every tick he writes a percentage: how sure he is. That is Jev.

The fork in the road

TypeSafe calls this "smart if-statements". Every program is full of forks in the road (if-statements): if this, go left, otherwise go right.

Ordinary forks can only ask things a calculator could answer. Is the total more than 100? Is the box ticked? They cannot ask "is this customer angry?" or "does this email look like a scam?" Those need judgment.

Jev lets a fork in the road ask a judgment question.

Where the name comes from

Jev is named after William Stanley Jevons, a 19th-century economist. He noticed that when steam engines became more efficient, Britain burned more coal, not less, because engines became worth using everywhere. TypeSafe's bet is the same: make judgment cheap enough and software will use vastly more of it.

How it works

You hand Jev two things: the situation (state) and the answer sheet (questions). The situation is any text or structured data: an email, a support ticket, a log line. The answer sheet is where all the design work happens.

There are only three kinds of question you can print on the sheet.

A Noul has no separate confidence, because the number already is the confidence. One caution on Score: use it to ask "is this past the line?", not as a precise ruler.

Three things worth knowing

Twelve clerks, not one. Imagine photocopying the letter twelve times and giving each copy to a different clerk with one question each. Nobody peeks at anyone else's answer. Jev works like that: every question is answered at the same moment and on its own (in parallel, in isolation). In our test, 1 question took 103 ms and 12 questions took 111 ms.

How sure is "sure"? Look at how the percentages are spread. If one option holds nearly all the weight, Jev is sure. If the weight is spread evenly, Jev is guessing. That spread is what the confidence number measures.

Ask small questions. Each question should be a gut-check a knowledgeable person could make in a few seconds. If it needs working out, split it into smaller questions and let your code combine the answers (decomposition). Jev does the small judgments. Code does the sums.

How it differs from today's models

The difference is what each model was graded on at school. All three kinds start from the same place: a model that has read a great deal of text. What happens next is different.

The chat model was graded on "did people like your answer?" (RLHF, reinforcement learning from human feedback). That produces a pleasant conversationalist. It can also reward flattery (sycophancy) and mistakes delivered with a straight face (hallucination).

The reasoning model was graded on "did you get the checkable answer right?" (RLVR, reinforcement learning from verifiable rewards). That produces a careful problem-solver for maths and code, who thinks for a long time first.

Jev was graded like a weather forecaster (RLCD, reinforcement learning for calibrated decisions). A forecaster who says "70% chance of rain" is good if it rains on about 70 of every 100 such days. Being honest about doubt is the skill being trained. TypeSafe calls this property calibration.

TypeSafe's founder, Diogo Almeida, is credited as a co-inventor of RLHF. So this is partly a critique from the inside.

One honest note. The writer can be made to fill in forms too. Most chat models now offer a mode that guarantees a valid form (structured outputs). The difference is that for Jev the form is the native language, not a costume.

What kind of model it is

Jev reads like a language model but answers like a classifier. There are two names for this, one from TypeSafe and one from the textbooks.

TypeSafe's name: a fast-thinking model (System One model). The psychologist Daniel Kahneman described two ways we think. Recognising a friend's face is instant and effortless: that is System 1. Doing long division is slow and deliberate: that is System 2. Reasoning models are built for System 2. Jev is built for System 1.

The textbook name: a judging model, not a making model (discriminative, not generative). A making model produces new things: text, images, code. A judging model looks at something and says what it is. Jev is a very general judging model. You do not train it on your own examples. You describe the categories in plain words and it judges straight away (zero-shot).

A thermometer, not a thermostat

Jev makes judgments. Your code makes decisions. People call Jev a "decision model", but that blurs something important.

A thermometer reads 19 degrees. It does not switch on the heating. The thermostat does that, because someone set it to 21. Change the setting and the same reading gives a different action.

Our test showed this exactly. Jev said the chance of a refund request was 0.78. The decision not to refund automatically was made by one line we wrote: refund only above 0.90. Set that line to 0.75 and the same answer from Jev produces the opposite action.

This split is where the safety comes from. The rule that decides is short, written by a person, and readable by an auditor.

What is known about the inside, and what is not

TypeSafe has not published how Jev is built. They say it uses a new design and answers everything at once instead of word by word (a parallel sampler). Size and training data are not disclosed.

The open-source copies give a clue, because they had to build the same thing from known parts. Some start from a reading-only model (an encoder, as in Laya). Most start from a small chat model and replace the writing step with all-at-once scoring of the printed options. Outside analysts who probed the API came to a similar view of Jev itself. TypeSafe has confirmed none of this, so treat "new class of model" as their framing for now.

Why it is needed

TypeSafe's argument is that AI is already clever enough, but too hard to build on. Most software you use today is no smarter than it was five years ago, even though the models are remarkable. So cleverness is not the bottleneck. Plumbing is.

The horseless carriage. The first cars looked like carriages with the horse removed, because that was the only shape people knew. TypeSafe says chat assistants are the same stage. Models trained to be good conversation partners assume a human on the other end. That gives you AI that needs a person watching it, not AI that quietly works in the background.

The 95% problem. Suppose an assistant gets 95 of every 100 jobs right, but never tells you which 5 are wrong. You have to check all 100, so you have saved nothing. Now suppose it says "I'm not sure about these eight." You check eight. That honest doubt (calibrated confidence) is what makes automation possible.

With it, code can take three roads instead of one: act when sure, ask when unsure, hand to a human when lost. The bar can be higher for risky actions than for harmless ones.

Databases before SQL. Early databases were powerful, but every use was custom work. Then a standard way of asking questions arrived and everybody built on top of it. TypeSafe wants a judgment to be as dependable and boring as a database query, so that people stack them by the thousand.

Their slogan for all this is "build prod, not God": stop chasing a machine that can do everything, and ship the small reliable part that software needs now.

One task, two ways

We gave the same job to a chat model and to Jev, and the results were more mixed than the sales pitch. The numbers below come from a run of our own, using OpenAI's GPT-5.6 Terra and Jev 1.13.

The job. A company receives thousands of customer messages a day. For each one, software must decide with nobody reading it: is this a refund request, which team owns it, and how upset is the customer? We used three messages. One was an angry customer charged twice. One was a calm bug report. One was deliberately vague: "I'm not happy with how this has gone. What are my options here?"

The chat model's way. A chat model only knows how to write. So we wrote it a letter: "Read this ticket and reply with only a filled-in form." It wrote back text that looked like a form. Our code then had to check it really was a valid form, with a real team name, and ask again if not. We also asked it to write down how sure it was.

Jev's way. We handed over the ticket (state) and three printed questions: a yes/no (Noul), a pick-one (Choice), and a how-much (Score). Here is the whole thing:

r = client.system_one(
    state=ticket,
    questions={
        "is_refund":   Noul(instructions="The customer is asking for their money back"),
        "team":        Choice(instructions="Which team should handle this ticket",
                              criteria={"billing": "Payments, charges, refunds",
                                        "technical": "Bugs, errors, integrations",
                                        "account": "Login, profile, access"}),
        "frustration": Score(instructions="How frustrated the customer appears",
                             criteria=["Calm", "Frustrated but civil", "Very angry"]),
    },
)
if r.choices["team"].confidence < 0.5:
    route_to_human(ticket)

What happened

The two surprises, explained

The vague ticket. This was partly our fault. We printed three teams and no box for "can't tell". A pick-one question forces a pick among the boxes offered. It tells you which option fits best, not whether any option fits. The fix is to print a fourth box, "unclear, send to a human", or to ask a yes/no first: "does this message say enough to route it?"

The refund. The customer wrote "Fix it or I'm cancelling." They never said "refund" or "money back". We asked Jev whether the customer was asking for money back, and it said 78%. The chat model read between the lines. You could call that Jev being careful or Jev being obtuse. Either reading gives the same lesson: Jev answers the question you wrote, not the one you meant. A better question would have been "does the customer report being charged incorrectly?"

They work as a team

Jev cannot write the apology email. So the natural design is simple: Jev judges, code decides, and the chat model gets called only on the branch where words are the product. The slow, expensive writer is kept for the moments that need writing.

When to use Jev, and when not to

Use Jev when you can print every acceptable answer before you see the input. One practitioner's summary is a good compass: reasoning models plan and generate; Jev classifies, ranks, verifies and routes; code owns the rules and the actions; humans take the uncertain and high-stakes cases.

Three questions that settle most cases

1. Can I list every acceptable answer in advance? If no, you need a writer, not Jev.
2. Could a knowledgeable person answer in a few seconds without working anything out? If no, you need a reasoning model or plain code.
3. If the model is unsure or wrong, is there a safe place for the case to go? If no, do not automate it yet.

Good fits

Poor fits

Two uses that sound good but need testing first

Re-ranking search results. One measured run over 33,047 catalogue entries found Jev re-ranking alone did not beat ordinary vector search. Another project reported a gain. Test against what you already have.

Pruning an agent's memory. Several plugins use Jev to decide which old conversation to drop. Critics argue that tidying memory is rebuilding, not filtering, so this asks Jev the wrong question.

Never hand these over, whatever the confidence

Logins, permissions, arithmetic, business rules and anything that cannot be undone belong in ordinary code. Jev can say a transfer looks legitimate. Code decides whether money moves. The trading bots that let Jev's buy or sell answer place real orders directly are the counter-example: a thermometer wired straight to the furnace.

What to be sceptical about

A ticked box is not a correct box, and most of the hype rests on blurring the two.

"It can't hallucinate." True in a narrow sense: Jev cannot leave the form. It can still tick the wrong box, confidently. TypeSafe's own docs say the zero figure is a guarantee about the form, not a measurement of accuracy. Our vague ticket is the proof.

"193 times faster." The headline tests were run by TypeSafe, on workflows their own team wrote. The "correct" answers were the average of two frontier chat models, GPT-6 Astra and Fable 5.1. TypeSafe says the 193x and 444x figures sit at the high end of what to expect. We measured 10 to 16x. Independent testers report a typical response of 236 to 276 ms.

"It knows when it doesn't know." Sometimes. Calibration is a promise about many predictions together, not about any single one. Outside measurements quoted on the Laya model card put Jev's calibration error at 0.246, worse than the launch material implies. I have not verified that figure myself.

"Just split the question up." Splitting helps, but it is not free. One evaluation split a judgment into 12 to 14 scored parts and accuracy rose from 0.84 to 0.91. It also flagged about 25 times more harmless rows as attacks. Errors moved. They did not vanish.

The rough edges TypeSafe admits to

TypeSafe publishes a page of known weak spots (model jaggedness), which is to their credit. Jev reads instructions very literally. It cannot count or do arithmetic reliably. It compares dates poorly. It loses accuracy when a question needs several hops or the situation is cluttered with irrelevant detail. Text planted in the situation can steer its answer. It handles text only, is strongest in English, and is not tuned per customer.

The open-source copies

Within a week, several free imitations appeared with the same three question types. The best documented is Laya, from Convai Innovations.

The fair summary: Jev is a large generalist you can point at anything. Laya is a small specialist you train and tune, which then runs very fast on your own hardware. Its README compares its 83.8% against Jev's 67.8%, but those numbers come from different tests. Its model card is far more candid than its README.

A note on unofficial sites

Fan sites have appeared to catch search traffic. One of them, jevai.org, shows sample code that does not match the real software kit at all and would fail on the first line. Trust TypeSafe's documentation for how to call Jev, and never paste your API key into a third-party playground.

Jev's words in one place

Jev does not make decisions. It makes judgments that your code turns into decisions.

Sources

As of 21 September 2026. This field moves quickly; check the dates before relying on any of it.

• TypeSafe AI manifesto
• Introducing System One models and Jev (launch post)
• TypeSafe documentation, including System One, the machine learning primer, confidence, models and pricing and model jaggedness for Jev 1.13
• Laya on GitHub and the Laya model card
• 30 useful Jev use cases, a field guide by Shrey Shah
• awesome-jev, a community index. Entries were read as one-line summaries and not individually checked.
• jevai.org, an unofficial community site
• Our own test run, GPT-5.6 Terra against Jev 1.13, three tickets. The notebook is not published. Three tickets show the shape of each tool. They prove nothing statistically.