Contents
On September 15, TypeSafe AI released a new model called Jev, and developers have been talking about it all week, because it doesn’t generate text at all. The ChatGPT, Claude and Gemini you use every day answer one token at a time. Jev doesn’t. You give it some data from your program plus a few questions with fixed options, and it hands back every answer at once, each with a probability.
Think of it this way: a regular LLM writes an essay; Jev fills in an answer sheet. Below I cover what it is, how to use it, why it’s fast, what people have built with it, and where it falls short.
So who made it?
The founder is Diogo Almeida, previously at OpenAI and Google Brain, where he worked on InstructGPT, RLHF, ChatGPT and GPT-4. He was one of the people who taught large models to chat, and now he’s left to build a model that doesn’t chat, which is kind of fun.
In the launch post he asks: models have been better than people at chatting for a while, so where did all the automation go? The company raised a $40 million seed round led by DCVC, and the team is in San Francisco.
Where the name comes from
They call this kind of model System One, after Kahneman’s Thinking, Fast and Slow. System 1 is the brain’s fast, unreflective judgment. Their view is that most decisions in software are questions like that, such as which category is this or is this urgent, and we’ve been paying top dollar for slow-thinking LLMs to answer them.
The name Jev comes from the economist Jevons. The Jevons paradox says that the more efficiently steam engines used coal, the more coal got burned. TypeSafe is betting on the same thing: make intelligence ten times cheaper and it’ll be used in a hundred times more places.
How the two kinds of model answer the same message
Say you run an online shop and this message arrives in your support inbox: the box of my brand-new headphones was crushed, the left earbud has no sound, refund me.
Give it to a regular LLM and you get a paragraph back, something like: this issue concerns product quality and shipping packaging; the buyer is upset; recommend prioritizing and starting a refund. Well written, but your program can’t read it. You still need code to parse the paragraph, or you ask it for JSON and pray it never adds an extra comma or invents a new field.
What your program actually needs is three things: which category, how angry the buyer is, and whether to refund. Jev gives you those three values directly, each with a probability.
You define the options in advance, and it can only pick from them. It won’t write you an essay or come up with a category you’ve never seen.
Only three question types
Jev’s API has just three question types, deliberately.
The first is Choice, a single choice from up to 255 options. For example, should this ticket go to finance, engineering or sales? Always add an “other” option; otherwise, when nothing fits, it will force-pick the closest wrong answer.
The second is Score. You describe a few levels in words and it tells you where the input falls, which can be a decimal like 1.035. For example, how angry is the user, from calm, to annoyed but holding it in, to furious.
The third is Noul, a yes-or-no judgment that returns a number from 0 to 1: the probability of yes.
One request can pack in many questions, all computed at the same time. Each extra question costs a tiny bit more and adds almost no time.
What the code looks like
There are official Python and TypeScript SDKs. The support message above looks roughly like this in code.
Look at the final if. Jev only makes the judgment; whether to refund, and how much, is still up to your code. TypeSafe calls this the intelligent if statement: fuzzy judgments you could never write rules for can now go straight into an if.
Why it’s so fast
A regular LLM producing JSON still generates it token by token: every brace, quote and field name is computed separately, each waiting on the one before. Jev doesn’t generate text at all; it computes every question in parallel in one pass. TypeSafe says end-to-end latency is 70 to 500 milliseconds, versus 3 seconds to over 300 seconds for frontier models in the same comparison table.
The price is even wilder: $0.042 per million input tokens, and output is free. Frontier models typically charge $0.20 to $10 per million input tokens, with output several times more. At the official price, a million reviews at 500 tokens each including the questions is 500 million tokens, about $21 in input fees.
They also show a demo of Jev playing Doom in real time, making 10 decisions a second for about $7 an hour. It’s fed a text version of the game state, though, not the screen.
The real win is the confidence
Jev is trained with a method called RLCD, reinforcement learning for calibrated decisions, aimed at making its probabilities honest. When it says it’s 90% sure, over the long run it really is right about 90% of the time.
That changes how you write programs: you can set a different threshold for each action based on the cost of being wrong. Take a banking support bot: below 50% confidence, hand off to a human. If the user just wants their balance, a low bar is fine. If they want to transfer money, it needs 85% or more to proceed; otherwise, pop up a dialog for the user to confirm themselves.
You can ask a regular LLM to report its confidence too, but they’re generally overconfident: they say 95%, and they’re not actually that accurate.
What people have built with it
Within two days of launch the community had a pile of projects. The numbers below are self-reported by their authors, so treat them as demos.
Someone used it to classify 1,018 papers. Summarizing them first with DeepSeek V4 Flash cost $3.99; handing the summaries and 24 topics to Jev as single-choice questions cost just $0.08.
The Browser Use team built a browser agent. Each step turns the page into a numbered list of elements, and a single Jev request decides both what action to take and which element to use, calling a small model only when it needs to type. Booking Zurich to London on the real Google Flights took 7.1 seconds and cost $0.0039.
Someone else built Mac automation: OCR reads the screen and Jev picks the next step, at $0.0002 per step, versus $0.032 per step for Opus 5 looking at screenshots directly. The author was honest about the trade-off: an LLM can read dates off a screenshot and compare them, while with Jev you have to write that part in code yourself.
Someone used it to control a drone. Flight control and obstacle avoidance are all traditional code, vision is classic CV, and Jev makes only 2.5 judgments a second, as suggestions; safety always stays with the code. Someone had it beat the first level of StarCraft in 421 decisions, and someone else had it play Super Mario from JSON dumped from the emulator’s memory.
All these projects follow a similar idea: loops, safety and computation stay in ordinary code, and Jev handles only the small piece of judgment in the middle that code can’t express.
Its pitfalls
TypeSafe published a whole page listing where Jev falls short, which is rare to see at launch.
It reads questions very literally. Negations, scope limits and conditions you assume but didn’t write down are all taken at face value. If you catch yourself thinking “what I really mean is…”, that half-sentence is what’s missing from your question.
It can’t count, and the more items there are, the less accurate it gets. To count, ask a yes-or-no question per item and add them up in code. It also can’t do date math: which came first or how many days apart aren’t reliable. Have it extract the dates and let code compare them.
The more irrelevant input you feed it, the less accurate it gets, so filter with code first and give it only the fields the question needs. It also doesn’t guard against its input: if users can change the input, text written specifically to fool it really can sway the answer. And it doesn’t generate anything: no prose, no code, no summaries.
There’s a line in the docs I really like: don’t ask the model what code can compute exactly, and don’t hide several judgments in one question.
How to read numbers like “200× faster”
You may have seen 100×, 200× or 400× in different articles. The highest come from TypeSafe’s own evaluation: 193.6× faster and 444.6× cheaper, which the company itself says is on the high side for real-world use.
In that evaluation Jev scored 67.8% and GPT-5.6 Terra 67.9%, almost identical. Sol at 74.1% and Opus 5 at 73.1% both beat it. Claude Sonnet 5 also scored 67.8%, but at 293 times Jev’s cost per question.
But the score isn’t accuracy. There are no ground-truth answers; the reference is the average of GPT-6 Astra and Fable 5.1, so what it really measures is how closely Jev agrees with those two top models. They wrote the questions and ran the test themselves, and no third party has reproduced it yet.
The “no hallucinations” claim deserves a discount too. What it guarantees is that the answer is always one of your options and nothing is made up, but picking the wrong option still happens. And prices may not stay where they are; TypeSafe says it can’t prove they aren’t subsidized right now, only that it expects them to get cheaper.
Some people are skeptical
Engineer Sean Goedecke wrote a fairly representative analysis. He argues existing LLMs can also do very fast structured output: prefill the answer so only one token is left, constrain it to the options, and you get most of the speed advantage. He tried it with Qwen2.5-1.5B and got two to three times faster than ordinary structured output.
Someone in the community has already built an open-source version along those lines called openjev, computing everything in one pass on a 4B open model and reading the option probabilities directly. Its author says it only replicates the API, not Jev’s model or training method.
Sean also points out that Jev can’t think before answering, so it can’t use inference-time compute, and it’s probably about as smart as a non-reasoning model. So how deep its moat really is is hard to say right now, though he concedes a model trained specifically for this will most likely still beat what people hack together themselves.
When to use it
It’s a good fit for ticket classification and routing, content moderation, filtering material before handing it to an expensive model, scoring and gating LLM output, large-scale labeling you used to skip because it was too expensive, and any judgment that has to come back within a second.
It’s a poor fit for writing anything, counting or date math, decisions that need a written rationale for human review, one-off complex reasoning, and questions whose answers can’t be listed as options in advance.
The most common pattern is tiering. Jev first decides what kind of request this is and how hard it is; code handles what it can, cheap models take the ordinary ones, and only the few hard ones go to the most expensive model. LangChain has already published an integration guide, and one of its uses is having Jev check whether an agent’s tool calls are risky.
To try it you currently need to join a waitlist, or you can call it through Vercel AI Gateway. If you’ve tuned thresholds to its confidence, pin the version number: jev-latest moves with new releases, and the answers may move with it.
My take
What strikes me most about Jev is that it’s a different kind of interface. Nearly everything people have built on LLMs in recent years looks like a chat box. Now there’s a judgment function that answers in 100 milliseconds, costs almost nothing and tells you how much to trust it, and that could bring a wave of AI apps that look nothing like chatbots.
It also made me realize that a lot of work we used to hand to LLMs is really just a multiple-choice question. Of course it’s still in private beta and the key numbers are self-reported, so it’s worth waiting for a third-party run before drawing conclusions.
Do you have a feature that really only needs AI to answer a multiple-choice question?
