Jev: A System One Model by TypeSafe AI
Jev is a new model by TypeSafe AI that I have been reading about this week.
System One vs System Two
The name comes from Daniel Kahneman’s Thinking, Fast and Slow. System 2 is slow, deliberate reasoning. System 1 is fast, intuitive gut feeling. Most frontier labs right now are pushing hard on System 2: longer chain-of-thought, bigger compute budgets, slower inference. That makes sense for hard problems.
But most decisions inside software are not hard problems. Routing a support ticket to the right team, checking whether a message contains PII, flagging a refund request — these are classification tasks. You do not need a model to think for 10 seconds and write three paragraphs to answer “is this a billing question?” You need a fast yes or no.
That is what Jev does. Someone described it well: it is a smart if statement.
How It Works
Jev takes two inputs and returns one output. No text generation, no parsing.
Inputs:
- State — unstructured text or data that you want to classify (a support ticket, a log entry, a user message, whatever).
- Questions — a set of typed queries you want answered about that state.
Output: structured values with probabilities.
The output tokens are effectively free because Jev does not do autoregressive text generation.
The Three Primitives
There are exactly three question types.
Noul
A Noul is a yes/no question. You phrase it as a statement, and Jev returns a number from 0 to 1 representing the probability that the statement is true.
{
"refund_requested": {
"type": "noul",
"instructions": "The customer is requesting a refund."
}
}0.99 means near-certain yes. 0.02 means near-certain no. 0.5 means the model genuinely does not know.
The interesting thing about Noul is that there is no separate confidence field. The value is both the answer and the uncertainty. A 0.5 is the model saying “I don’t know,” not a bug.
If you repeat the same query, the outputs vary slightly because the model is stochastic, but they stay within a consistent probability range. It does not flip between 0.1 and 0.9.
Choice
A Choice question picks one option from a list you define (up to 255 options). The response includes the selected label, a confidence score, and the full probability distribution across all options.
For example: “What language is this text?” with options ["English", "Arabic", "French", "Spanish"].
Score
A Score question rates something on a scale you define with 2 to 10 levels. For example: “How frustrated is the customer?” with levels ["Calm", "Frustrated", "Very angry"].
Mixing Questions
You can send Noul, Choice, and Score questions in a single call. Every question is evaluated independently and in parallel. Batching questions into one call is around 12x cheaper and 10x faster than sending them separately, with no change in answers.
In the demo I watched, someone ran 20 sequential classification tasks in one run. It finished fast and cost just over 0.12 cents. That is the kind of number that makes you rethink how you are doing classification today.
Speed and Cost
Latency is 70 to 500 milliseconds per call, including network round trip. Input tokens cost about $0.042 per million. Output tokens are free.
TypeSafe claims 20 to 200x faster and 40 to 400x cheaper than frontier LLMs on comparable tasks. Their website demo shows Jev returning a response in 0.114 seconds compared to 8.5 seconds for GPT-5.6 Terra on the same classification. Even accounting for marketing, the speed difference is real because the architecture is fundamentally different — single forward pass vs autoregressive token generation.
Training: RLCD
TypeSafe has not published a paper yet, but they describe their training method as RLCD — Reinforcement Learning for Calibrated Decisions. This is different from RLHF (reinforcement learning from human feedback) and from verifiable rewards RL like GRPO.
The goal of RLCD is to produce well-calibrated probabilities. Calibrated means: if the model says 0.8 across a group of similar predictions, roughly 80% of those should actually be correct. This is a statistical guarantee, not a per-answer guarantee.
The calibration is what makes the “no hallucination” claim work in a narrow sense. Since Jev only returns values from your schema — a label from your list, a score on your scale, or a probability between 0 and 1 — it literally cannot produce broken JSON, invented tool names, or out-of-schema strings. It can still be wrong, but it cannot be wrong in a way that breaks your code.
Accuracy
On TypeSafe’s own 4-workflow benchmark, Jev scores 67.8% accuracy. That is roughly tied with GPT-5.6 Terra at 67.9% and a few points below GPT-5.6 Sol at 74.1% and Opus 5 at 73.1%.
So it is not more accurate than frontier models. It is much faster and much cheaper at comparable accuracy. That is the trade-off.
What People Are Using It For
From what I have seen so far:
- Support ticket routing — which team should handle this (billing, sales, technical).
- Refund detection — is the customer asking for money back, and how urgent is it.
- PII detection — does this message contain personally identifiable information.
- Spam detection — straightforward classification.
- Prompt injection detection — checking whether user input is trying to manipulate an LLM downstream.
- Sarcasm detection — works reasonably well, though edge cases exist.
- Agent tool selection — which tool should the agent call next (though Jev does not extract function arguments, only picks the tool).
- Code review safety — flagging risky patterns before a human reviews.
The pattern that makes the most sense to me is the cascade: Jev handles the fast, cheap classification layer. Deterministic code handles what it can based on those classifications. A frontier model only gets called for the hard minority that actually needs reasoning.
This matters because right now, most agent architectures call a full LLM for every single decision, including trivial ones. That is slow and expensive for what is often just a classification task.
API
Jev is available through TypeSafe’s API and also through OpenRouter. The endpoint is:
POST https://api.typesafe.ai/v1/systemoneThe client reads TYPESAFE_API_KEY from the environment and uses jev-latest as the default model. There are official Python and JavaScript SDKs.
What We Do Not Know Yet
TypeSafe has not published a whitepaper or detailed architecture diagrams. We do not know the exact model architecture (likely transformer-based, but not confirmed). We do not know how well RLCD scales and generalizes across domains. And we do not know the specific failure modes on ambiguous or adversarial inputs beyond the demos.
It is early. But the idea of having a fast, cheap, typed classification layer that sits in front of heavier models is practical. Most of the decisions in a typical automation pipeline are simple — the hard part has been that even simple decisions required expensive inference until now.