09 Oct 2026 · artificial intelligence · 6 min

Jev: the model that decides in milliseconds without writing text

What it is, in one paragraph

Jev is a model released on 15 September 2026 by TypeSafe AI, the startup of Diogo Almeida, one of the authors of the paper behind ChatGPT’s instruction tuning. It does not generate text. You hand it a state (a text, a JSON object, a table row) and a list of questions whose possible answers are defined in advance, and it returns a typed answer with an associated probability. The company calls the category “System One Model”, a reference to the fast, intuitive thinking described by Daniel Kahneman, as opposed to the slow reasoning that chat models perform while writing.

Update: three weeks later, independent audits measured the model on public data, and some numbers contradict the launch post. They are in Jev, three weeks later.

Why it exists

Much of the work people try to delegate to a language model is not writing, it is deciding: routing a ticket, deciding whether a message is a phishing attempt, choosing an agent’s next step, scoring risk. For that kind of task, asking for a paragraph of justification is expensive and slow, and it still forces the program to parse free text to find the decision.

Jev’s proposal is the inverse: the decision comes back ready for code to consume, with a confidence number next to it. According to TypeSafe, training uses a method of its own, RLCD (Reinforcement Learning for Calibrated Decisions), which optimises calibration instead of human preference: if the model says 80% likely, the goal is for it to be right in roughly 80% of cases over time. That differs from RLHF, which is trained to produce the answer a human prefers.

The three possible answers

Every question you ask the model falls into one of these formats, and nothing else:

type	what it returns	example question
choice	one of the options you listed, with the probability of each	“is this message about payment, support, cancellation or sales?”
score	a value inside a scale you define	“from 0 to 4, how urgent is this ticket?”
proposition	the probability that a statement is true, between 0 and 1	“is this e-mail a phishing attempt?”

There is no free-text field in the answer. That is what allows the claim that the format cannot come out wrong: the set of possible outputs was defined before the call.

How to use it

Access is through an API. The documented entry point is a POST to https://api.typesafe.ai/v1/systemone, with the model jev-latest. The example below is illustrative, to show the shape of the request; check the exact format in TypeSafe’s documentation before integrating.

bash

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Customer reports that the September invoice came with a different amount than the contract and asks for an immediate correction.",
    "questions": [
      {"id": "subject", "type": "choice", "options": ["billing", "support", "cancellation", "sales"]},
      {"id": "urgency", "type": "score", "min": 0, "max": 4},
      {"id": "churn_risk", "type": "proposition", "statement": "The customer is at risk of cancelling in the next 30 days"}
    ]
  }'

The calling program receives the decisions with their probabilities and decides what to do. The model does not write the reply e-mail or the ticket text; that remains a job for a chat model, when it is needed.

Where it fits well

Support triage. Classifying and prioritising the queue before any writing happens. This is the case most cited in the documentation and in published analyses.
Agent guardrails. Before an agent performs an action, asking whether the action matches the request. A fast boolean answer is more useful than a paragraph of analysis on the critical path.
Output verification. Checking whether text produced by another model meets a condition (whether it quotes the right price, for example) and returning approved or rejected.
Classification at volume. Labelling rows of a large text corpus, where cost per decision decides whether the project fits the budget.
Moderation and filters. Deciding what passes, what goes to human review and what is blocked.

Where it does not fit

Generating text, explaining, summarising or chatting. That is not what it does.
Decisions that require long, open reasoning with written steps and justification.
A question whose set of answers cannot be defined in advance. If the possible answer does not fit a list, Jev is not the tool.

Comparison with a chat model

	Jev	chat model
output	typed value, usable by code as is	text that has to be interpreted
published latency	70 to 500 ms	seconds per answer of a few paragraphs
billing	per input token, output free of charge	input and output both billed
format	defined in the call, no variation	free-form, subject to variation
weak point	does not write, does not explain, depends on calibration	cost and latency per call, and the decision must be extracted from text

Bar chart comparing time to a usable answer: Jev between 0.07 and 0.5 seconds; a chat model answering a paragraph, in the order of seconds

Chart with two panels: on the left, cost per decision around 440 times lower for Jev; on the right, measured accuracy of 68% against 73%

The latency and cost figures above are those published by TypeSafe. Arize published an independent measurement putting Jev’s accuracy at 68% against 73% for a frontier model of the same generation, and highlights cost as the central point: the accuracy gap is small next to the price gap per decision.

How I would evaluate it before adopting

Build a set of closed questions with known correct answers, taken from your own history.
Measure accuracy and calibration, not accuracy alone: when the model says 0.9, how often was it right? A confident and wrong model is worse than an uncertain one.
Compare cost per decision with a chat model on the same set.
Check whether the decision sits on the user’s critical path. If it does, millisecond latency changes the design of the application; if it does not, the gain is only cost.
Only then choose where to use it. A new tool does not become architecture on day one.

The ecosystem around it

The launch came with an integration into Vercel’s AI Gateway, which reported usage by nearly 13% of paying teams in the first 24 hours. Within two weeks, open projects that train models for the same format appeared, such as OpenJev, along with libraries for measuring calibration, such as AnyJev. There is also a recurring criticism from part of the machine learning community that Jev’s function resembles classifiers and cross-encoders that already existed; what changed was the price and the latency, not the idea.

Worth following with healthy scepticism: the speed and cost numbers come from the company selling the model, and adoption is still recent.