What Is Jev? TypeSafe's System One Model, Explained
Jev is an AI model that never writes a sentence. You give it something to read and a question with a fixed set of answers, and it gives you back one of those answers with a probability attached. Here is how it works, how it differs from a language model, what people have already built with it, and where it falls down.
What Is Jev?
Jev is the first System One model from TypeSafe AI, released on 15 September 2026. It does not generate text. You send it a piece of state plus one or more typed questions, and it returns a decision with a probability attached: a yes/no likelihood, a choice from a fixed list, or a position on a rubric you define. It is designed to be called from software, thousands of times, rather than talked to.
The company was founded by Diogo Almeida, who worked on ChatGPT at OpenAI. The launch post claims Jev is 20 to 200 times faster and 40 to 400 times cheaper than existing models on the kind of work it targets, with output tokens billed at nothing. Those are the company's numbers; the ones we measured ourselves are further down.
The quickest way to understand it: every time you have written a prompt that ends with “respond only with JSON” and then written code to parse, validate and retry that JSON, you were using the wrong tool. Jev is built for that job.
Why a Model That Doesn't Write Text?
The name borrows from Daniel Kahneman's two systems of thinking. System Two is slow, deliberate reasoning: working through a problem step by step. System One is fast, intuitive judgment: the answer that arrives before you have thought about it.
Large language models are System Two machines. They produce an answer by writing it out one token after another, and that sequence is what makes them powerful — and slow, and expensive. If you want an essay, that is exactly right.
But most decisions inside software are not essays. Is this ticket urgent? Which of these six teams should handle it? Does this review complain about billing? Is this comment spam? These need a label, not a paragraph. Until now the only way to get one from a model was to ask a text generator for text and then convert it back into a value your code could use. That round trip costs latency, money and a parsing layer that can fail.
TypeSafe trained Jev with a method they call Reinforcement Learning for Calibrated Decisions (RLCD), and it samples in parallel rather than generating a sequence. The result skips the text entirely. When Jev went live on OpenRouter, the description was blunt about why this matters: there is no JSON prompting, no parsing layer, and nothing to validate against.
How Jev Works: The Three Primitives
Every Jev request has two parts. The state is whatever you want it to read — a support ticket, a product review, a page of a document, a snapshot of your app. The questions are what you want decided, and each one is a noul, a choice or a score. You can ask several in a single call, and since the state is only sent once, extra questions are close to free.
Noul: a probability that a statement is true
The yes/no primitive. You write a statement, and Jev returns how likely it is to be true, from 0 to 1.
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Cancelled in March, still getting billed every month.",
"model": "jev-latest",
"questions": {
"billing": {
"type": "noul",
"instructions": "The customer is complaining about billing or charges."
}
}
}'
{"answers": {"billing": {"type": "noul", "noul": 0.99}}}
Note what you get back: 0.99, not “Yes, this customer appears to be describing a billing issue.” There is nothing to parse. You compare it to a threshold and move on. A Noul returns no separate confidence value, because the number itself is the confidence — 0.5 means genuinely unsure.
Choice: one option from a list you define
You supply the options and a short description of each. Jev picks one and gives you a probability for every option, not just the winner.
{
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"returns": "Exchanges, wrong or damaged items",
"shipping": "Delivery status, delays, lost packages",
"billing": "Charges, invoices, payment problems"
}
}
{"choice": "returns", "confidence": 1.0,
"probabilities": {"returns": 1.0, "shipping": 0.0, "billing": 0.0}}
This is the primitive that cannot go wrong in the structural sense: the answer is always one of your three keys. It can never be a fourth team you do not have. A Choice supports up to 255 options.
Score: a position on a rubric
You define an ordered list of levels, from low to high, and Jev places the item on that scale. The returned score is a float, so it can sit between two levels.
{
"type": "score",
"instructions": "How severe is the reported issue?",
"criteria": [
"Cosmetic; no impact to functionality",
"Broken or degraded feature, but a workaround exists",
"Blocking issue; no workaround exists"
]
}
{"score": 1.43, "confidence": 0.35,
"probabilities": {"0": 0.0, "1": 0.57, "2": 0.43}}
A 1.43 with 0.35 confidence tells you something a single label would hide: the model is genuinely torn between “has a workaround” and “blocking.” That is a case to send to a human.
One rule runs through all three, and TypeSafe's documentation is firm about it: each question should ask exactly one thing. We ignored this at first and paid for it, as described near the end of this post.
Jev vs. an LLM
| Jev | A chat model (GPT, Claude, Gemini) | |
|---|---|---|
| What comes back | A typed value plus probabilities | Text, code or JSON |
| Parsing layer needed | None | Yes, plus validation and retries |
| Can it write? | No | Yes |
| Can it explain itself? | No, you get a number | Yes |
| Latency we measured | 296 ms median per call | Not measured in this post |
| Price | $0.042 / 1M input, output free | Varies; output billed, usually at a premium |
| Invalid answers possible | No — always one of your options | Yes — can invent categories or fields |
| Built for | Many small decisions inside software | Writing, reasoning, conversation |
They are not competitors. The common pattern is both together: Jev decides what to do, the language model does the part that needs words.
The Advantages, and What Each One Actually Means
We spent a few days testing Jev before writing any of this, so each claim below comes with what we saw rather than what the launch post said. The main test: 290 GitHub issue threads read in parallel, with seven typed questions per thread.
No parsing layer. This is the one developers react to most, and it is not really about tokens. When a model returns text, you write a parser, a validator, a retry path and a fallback for the day it returns something almost-but-not-quite valid. With a typed decision, none of that code exists. That is the part you feel.
Speed. TypeSafe states 70–500 ms. We measured a median of 296 ms per call, best case 253 ms, from Turkey. One warning if you benchmark it yourself: our first script opened a new HTTPS connection for every call and showed about 720 ms, of which 434 ms was TCP and TLS setup. Reuse your connections or you will mostly be measuring your own network.
Throughput. 290 calls at 100 concurrent finished in 2.5 seconds with zero errors and no rate-limit responses. This is what makes the difference in practice: it is not that one call is fast, it is that a thousand calls are also fast.
Cost. Those 290 calls carried 372,480 input tokens and cost $0.0156. Output being free changes how you design: adding a sixth question to a call, or a fiftieth option to a Choice, barely moves the bill.
Calibrated probabilities. A probability is only useful if it tracks reality. We checked Jev's answers against an independent record from GitHub's API that the model never saw. Where Jev was at least 80% sure, it was right 97% of the time (119 of 123 cases). At 60–80%, 91%. That means you can route the confident cases automatically and send the uncertain ones to a human, which is the whole point of getting a number instead of a label.
No option-order bias. Language models are known to favour answers by their position in a list. We ran twelve classification tasks with their six options in four different orders — original, reversed, rotated and shuffled. The answer was identical in all twelve, and the probabilities moved by 0.015 at the median. That is the same amount they move between two identical calls, so reordering had no effect beyond ordinary noise. If you have been shuffling options as a defence, you can stop.
Stability. Five identical calls gave the same answer in twelve of twelve cases. The probabilities underneath wobble slightly, by about 0.02, so an item sitting right on your threshold can still flip between runs. Keep that in mind when you pick a cutoff.
The honest limit of “no hallucination”
You will see this claim repeated a lot, and it is true in a specific, narrow way: Jev physically cannot return an option you did not define. No invented category, no invented field, no made-up citation. That is a real guarantee, and it is the reason the parsing layer disappears.
It is a guarantee about the shape of the answer, not its correctness. Jev can still pick the wrong option from your list. In our testing we asked it to identify the SQL dialect of a query using a QUALIFY clause. It answered “SQL Server” every single time, in every option order, with no hesitation in the probabilities. QUALIFY does not exist in SQL Server; it belongs to Snowflake, BigQuery, Teradata and DuckDB. Consistency makes errors easier to catch in testing. It does not make them stop being errors.
What People Have Built With Jev
Jev has only been public since mid-September, but a lot has already shipped. Grouping it by shape is the fastest way to see where your own problem might fit.
Real-time control
Things that need a decision several times a second, which no chat model can do.
- Playing Doom. TypeSafe's own demo runs at 10 queries per second, with the game state as the input and the next move as a Choice.
- Wikiracing — getting from one Wikipedia page to another using only links. The founder highlighted this one for a specific reason: each page offers hundreds or thousands of links, so every step is a high-cardinality choice, and the benefit of never picking an invalid one compounds over a long chain.
Reading a lot of text quickly
Work that was previously skipped because reading it all was too slow or too expensive.
- Semantic find in the browser. An open-source Chrome extension replaces ⌘F so it matches meaning instead of characters. You type “refund policy” and it finds the relevant paragraph even if those words never appear. The shape is one yes/no question per block of text on the page, all at once.
- Auditing GitHub's “good first issue” label. This was our own test. GitHub lists over 321,000 issues as open and unassigned. We had Jev read 290 of them — comments plus linked pull requests — in 2.5 seconds for $0.0156. It turned out 73% already had someone working on them and only 15% were genuinely free.
- SEO and content workflows. One team published seven, including scoring competitor pages for depth and freshness, returning keep-or-change for every title, meta description and FAQ on a page, and classifying an entire Search Console export by whether each query comes from a buyer.
Matching and routing
The classic classification jobs, now cheap enough to run over everything rather than a sample.
- Matching 3,675 people to each other. Someone took every maker who introduced themselves in one X thread, read their bios, interests and posts, and matched each person with who they should meet. It took 40 seconds and $3.74.
- Support ticket triage, résumé screening, lead scoring. The pattern is the same: a Choice for the category, a Score for priority or fit, a Noul or two for flags like “this customer is angry.”
Checking other AI
Using a fast model to guard a slow one.
- Gating AI-written content. In the SEO workflows above, every draft passes 20 yes/no checks and only the ones that pass reach a human reviewer.
- Approving what an agent is about to run. Before a command or query executes, ask whether it matches what the user asked for and whether it touches personal data. This only works if the check is fast; a few hundred milliseconds is tolerable in a loop, several seconds is not.
Coding agents
On 21 September the founder published his notes on this area and invited the community to build in it. The argument: today's agents lean too heavily on one context that grows forever. If context were instead selected per task and managed explicitly, a fast decision model could improve which model gets routed to, which tool gets called, and how sub-agents divide work.
There is also a community benchmark suite, Jev Benchmark Lab, with 200 ground-truth cases across 20 test suites, if you want to measure it against your own bar.
When Not to Use Jev
- Anything that produces text. Writing, summarising, translating, generating code. Jev has no mechanism for it.
- When you need the reasoning. You get a probability, never a because.
- Arithmetic, counting and dates. Listed as weak spots in the official integration docs. Do these in code.
- Anything you can determine exactly. If a parser, a regex or a database column answers the question, do not ask a model.
- Adversarial input. The docs flag text written to manipulate the answer as a known weakness.
- When there is no room for “unsure.” In our GitHub test, roughly one item in four had at least one answer landing between 0.35 and 0.65. Plan a path for that middle band.
One more thing we cannot tell you: we have not run Jev head-to-head against a language model on the same task and scored both. So we can say it is much faster and much cheaper. We cannot say it is more accurate.
Two Mistakes Worth Avoiding
Asking two things in one question. Our first version asked “someone asked to be assigned, but no work has started.” On issues with no comments at all, the second half is technically true, so Jev leaned yes and mislabelled 25 of 28 empty threads. Splitting it into two single-fact questions and doing the AND in our own code fixed it completely. When the docs say one question asks one thing, this is what they are protecting you from.
Asking questions in isolation when the question is comparative. We needed to rank 56 database tables by relevance to a question, and asked one independent yes/no per table. It failed badly: required tables sank as far as rank 46, while decoys scored 0.86, because “is this table relevant?” asked alone has nothing to compare against. A single Choice with all 56 options put every required table in the top four, for a tenth of the tokens. If a question is really about ranking, the options need to be in the same request.
Getting Started
There is no waitlist as of 21 September 2026. Create a key at console.typesafe.ai, or reach Jev through OpenRouter, which has it in beta.
pip install typesafe-sdk
export TYPESAFE_API_KEY="..."
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
with TypeSafeClient() as client:
response = client.system_one(
state=ticket,
questions={
"urgent": Noul(instructions="This needs a reply today."),
"team": Choice(
instructions="Which team should handle this?",
criteria={"returns": "...", "shipping": "...", "billing": "..."},
),
},
)
print(response.answers["team"].choice, response.answers["urgent"].noul)
If you use Pydantic AI, there is a first-party integration where you describe the decision as a Pydantic model and Jev fills it in:
from pydantic import BaseModel, Field
from pydantic_ai import Agent
class Triage(BaseModel):
urgent: bool = Field(description="Does this need a reply today?")
agent = Agent("typesafe:jev-latest", output_type=Triage)
Install it with pip install "pydantic-ai-slim[typesafe]". Only bounded types work: booleans, enums, literals, floats between 0 and 1. Unbounded strings, integers and dates are refused before the request is even sent, which is the library keeping you honest about what this model is for.
If you want to see Jev applied to a specific domain with all the measurements in one place, we wrote that up separately in Jev for SQL: 5 data use cases and what we measured.
Frequently Asked Questions
What is Jev?
Jev is the first System One model from TypeSafe AI, released in September 2026. Unlike a chat model, it never writes text. You send it a piece of state plus one or more typed questions, and it returns a decision with a probability attached: a yes/no likelihood, a pick from a fixed list of options, or a position on a rubric you define. It is built to be called from software many times per second rather than talked to.
Is Jev an LLM?
No. A large language model predicts text one token at a time, which is why it can write and why it is slow. Jev produces no text at all. TypeSafe calls it a System One model, trained with a method they call Reinforcement Learning for Calibrated Decisions (RLCD), and it returns typed values with calibrated probabilities instead of prose.
Can Jev write code or SQL?
No. Jev cannot produce any free-form text, so it cannot write code, SQL, summaries or explanations. It is used alongside a language model, not instead of one: the LLM writes, and Jev makes the fast decisions around it, such as classifying, routing, ranking and verifying.
How much does Jev cost?
TypeSafe charges $0.042 per million input tokens, and output tokens are free. In our own testing, 290 calls carrying about 1,300 input tokens each cost $0.0156 in total. A short text with a single question uses roughly 300 input tokens, so classifying 10,000 short rows costs about $0.13.
Is there a waitlist for Jev?
Not anymore. Jev launched in early access with a waitlist on 15 September 2026, and TypeSafe announced on 21 September that it is open to everyone. You can create an API key at console.typesafe.ai. It is also available through OpenRouter in beta.
How fast is Jev?
TypeSafe states 70 to 500 ms per call. Measuring from Turkey in September 2026, we saw a median of 296 ms on a reused HTTPS connection. Opening a fresh connection for every call added about 434 ms of TCP and TLS setup, which is worth knowing before you benchmark it. With 100 concurrent requests, 290 calls completed in 2.5 seconds with no errors.
Does Jev hallucinate?
It cannot answer outside the options you define, so it cannot invent a category, a field or a fact the way a language model can. That is a real guarantee about the shape of the answer, not about its correctness: Jev can still select the wrong option from your list, and it does so consistently. In our testing it identified a QUALIFY clause as SQL Server syntax every single time, and QUALIFY does not exist in SQL Server.
Should I use Jev or GPT for classification?
Use Jev when the answer is a label, a yes/no or a score, when you have many items to get through, and when latency or cost matters. Use a language model when you need an explanation alongside the answer, free-form extraction, arithmetic or date logic, or any generated text. We have not run a head-to-head accuracy comparison, so we can say Jev is faster and cheaper, not that it is more accurate.