An AI that refuses to chat: What the heck is Jev
Written in September 2026, five days after Jev was released. This stuff changes quickly, and the pricing, latency, and test data in this article may be out of date. I tried my best to check official documents and primary sources, but I still recommend that you open the original text and take another look.
In the past two years, we have become accustomed to AI talking a lot. You ask it if today is Monday, it will first tell you about the origin of the week system, then remind you to pay attention to the balance between work and rest, and finally ask you if there is anything else it can help.
Then Jev showed up. You ask it a question, and it only replies to you with an option and a probability, not a single word more. Very much like that colleague in the company who never speaks in the group but never makes mistakes in the work he is handed.

Source: TypeSafe AI official demo, via TechCrunch 2026-09-18 Report reprinted. The 74.9× / 171.0× in the screenshot are the results of that demonstration, not an average value that can be extrapolated casually.
1. What is Jev?
Jev is the first public model released by TypeSafe AI on September 15, 2026. The official category name given to it is System One Model: Borrowing the term "System One" from Kahneman's "Thinking, Fast and Slow", it is the kind of intuitive thinking that makes quick judgments without thinking. In contrast, there are large models such as ChatGPT and Claude that write word by word and think slowly. The name of the model comes from economist William Stanley Jevons - the official meaning is: once intelligence becomes cheap, usage will increase, not shrink.
founder Diogo Almeida is a former OpenAI researcher. TechCrunch reported that he participated in ChatGPT and the set of command-following training later known as RLHF; his own release was more narrow: he helped in OpenAI to help language models learn to listen to commands and speak to people. The company’s other two co-founders are Erik Gafni and Sasha Sheng. Multiple media reported that TypeSafe completed a $40 million seed round led by DCVC during the same period; I did not see the financing details in the official release, so I only regarded it as a media report and not as a number stamped by the company.
in human terms is:
Jev is a universal classifier. The technical point is that there is no need to train for every task like traditional classifiers.
In the past, if you wanted a machine to automatically classify customer service work orders, you had to find someone to label thousands of pieces of data and then train a special model. One day the boss said that he wanted to add a "complaint" category. Well, re-label and re-train. Jev deleted this step: the classification criteria are directly written in text when calling, and changing the criteria is just a matter of changing a few lines.
Also make it clear: Jev is closed source. There is no open weight, it cannot be deployed locally, and it can only use the managed API. The official release stated that their evaluation was run from a laptop on the West Coast of the United States, "this is where our service is currently based" - which can be understood to mean that the server is now on the West Coast of the United States. There is a queue for the official API; there is currently no need to wait for the Vercel AI Gateway.

Schematic diagram. The left side is the path of the traditional classifier, and the right side is the calling method of Jev.
2. What can Jev do?
The official documents only give it three kinds of questions, that is, three "primitive languages":
- Choice / multiple-choice question: Choose one of the several options you gave, such as "Which department should this work order be given to?" Maximum of 255 options.
- Score/Scoring Questions: Score in an ordered scale you define, such as "How urgent is this problem?"
- Noul/True or False: Give the probability of "yes". The official name is Noul; it is often written as Boolean in Vercel's AI SDK and changelog. It's the same kind of problem.
Each answer comes with a probability, and multiple-choice and scored questions will also give a confidence. This is its most interesting part, which will be discussed in detail later.
sounds very simple, but this kind of judgment is actually everywhere in the software. Typical usages include the following:
- Work order and message diversion: Determine which team should be handed over and how urgent it is.
- Agent's decision node: Which tool should be called next, should continue, retry, ask the user or stop.
- Safety Checks and Guardrails: Determine whether the operation is dangerous before the AI executes the command, or check whether the output of another model is out of bounds. Vercel engineers used it to replace the security review of commands running on Luna in fx default mode.
- Model Routing: Determine whether a request is a simple question or a difficult question. If it is a simple question, it will be handed over to a cheap model, and if it is difficult, it will be handed over to an expensive model. LangChain has made a ready-made experimental middleware
ModelRouterMiddleware, and there is alsoAutoModeMiddlewarethat uses Jev to block high-risk tool calls. The scenarios that
is suitable for have a common feature: Answers can be listed in advance, and the number of judgments is high. It doesn’t matter what model you use to judge something dozens of times a day; it’s only when you judge it hundreds of thousands of times a day, or once every time a user clicks, that the value of Jev comes out.
On the other hand, if you need it to write things, do calculations, or explain why you make such judgments, don't look for it. It really doesn't. The official himself said: It gave up string generation.

Schematic diagram. Jev is only responsible for judgment; who to distribute it to and whether to manually review it is still determined by your code.
3. How is it better than Luna?
The pricing and positioning of Jev are based on cheap and fast small models such as GPT-5.6 Luna and Claude Haiku. So here's the comparison with Luna. The numbers are divided into three levels: the official ones, those of Vercel engineers, and those independently tested by the community. Don't mess around with reading.
1. Fast
This is the most real advantage. Someone in the
community did an independent test: In a split test of 30 work orders, Jev had a median delay of 575 ms and Luna 1472 ms, which is about 2.6 times faster; in another review classification test, the median delay was 0.647 s versus 1.556 s, which is about 2.4 times faster. The official numbers are even more exaggerated: 70–500 ms end-to-end, 3–329 seconds for large models, and say 40 to 200 times faster on System One tasks. The phrase “193.6x Faster” on the official website comes from their own workflow evals, and the official admits that this is “on the higher side of real-world earnings.” Vercel changed the command security review in fx from Luna to Jev. Engineers publicly stated that it was 5 to 18 times faster (p95 reached 18 times); Vercel's official changelog did not write this set of numbers, but only reported TypeSafe's own 193.6 times.
1 second and 0.3 seconds, there is no difference for batch processing. But if the judgment occurs after each click of the user, or before each step of the AI Agent, this delay will stack up layer by layer, and finally become a lag that the user can feel.
2. Cheap The official pricing of
is very clear: Input is $0.042 per million tokens (that is, $42 per billion tokens), Output is free, because it has nothing to output at all. Officials also confessed: they could not prove that the price was not subsidized. The “444.6x Cheaper” on the
official website is compared with expensive large models and according to their own workflow. Compared with Luna, the two community independent tests are about 4 to 5 times cheaper: $0.022 vs. $0.088 per 1,000 in the ticket test; the known single cost in the review test is about $0.000032 vs. $0.000154.
To be honest, Luna is already cheap enough, so the price difference is insignificant to most people. It only makes sense if the quantity is large enough.
3. The probability can be trusted
This is what makes Jev truly unique. You ask Luna to give a confidence level, and it says 0.9. This number is more like what it "says" and doesn't quite reflect whether it is actually correct. TypeSafe specifically uses a method called RLCD (Reinforcement Learning for Calibrated Decisions) to train this thing. The goal is that when it says 90% of the time, it is really about 90% correct. If
is reliable, it can do a very practical thing: high-confidence tasks can be directly processed automatically, and low-confidence tasks can be transferred to manual processing. For the company, the savings in manual review costs are much more valuable than the savings in API fees. However, this statement currently mainly comes from the official, and there are no public papers on training details and calibration errors. It is recommended to verify it yourself with real data.
4. Wrong-formatted answers will not be output
When using Luna for classification, you may occasionally encounter that the JSON format it returns is incorrect, or it compiles an option that you have not given. Jev does not have this problem structurally, it can only choose from the options you define.
officially calls this "zero illusion". This statement needs to be discounted: the official explained that this 0% is not measured, but "schema matching is guaranteed" - it will not give non-existent options, but it is entirely possible to choose the wrong option that exists, and it is possible to choose it very confidently.
Let me be honest about the accuracy
The accuracy rate is high. Jev does not win steadily.
- Community 30 ticket test: Luna triathlon 28/30, Jev 25/30. Jev's typical mistake is to judge two fault reports with a very calm tone as "the customer is angry".
- 100 comments from the community, 3 runs each: Luna field accuracy is 97.13%, Jev is 96.13%, a difference of 1 percentage point. The author himself also wrote that this is synthetic data and cannot be used as a general ranking.
- Official workflow evals: Jev 67.8%, Luna 66.8%, Jev 1 point higher. But the standard answer for this set of evaluations is the average output of GPT-6 Astra and Claude Fable 5.1, without human annotation. There is an article on Dev.to that breaks down this method very clearly.
These test samples are not large, so no one can explain anything. My own conclusion is: The accuracy is almost the same. Jev wins because it is fast, cheap, the format will not run away, and it is willing to give you a probability that you can use to set a threshold.

based on BUNYOD0987/jev-vs-llm and mameli/jev-vs-luna Published digital repaint. The sample size is small and only indicates the direction in these two tests.
4. How to use
Access
Currently I see three paths:
- Official API:
POST https://api.typesafe.ai/v1/systemone, model ID isjev-latest. You need to queue for eligibility first. - Vercel AI Gateway: No queue is required; the model ID is
typesafe-ai/jev, and the changelog says the price is the same. AI SDK 7 uses the experimentalevaluateinterface. - OpenRouter: The model ID is
~typesafe/jev-latest; it uses the Decisions API, not ordinary chat completions. The listed price is also $0.042 per million input tokens and $0 for output.
LiteLLM also supports pass-through: replace https://api.typesafe.ai with the proxy path /typesafe.
What does the call look like?
You have to give it two things: state is the content to be judged, and questions is the question you want to ask. You can ask several at a time, and it will answer in parallel. The following is written according to the structure of the official document, and the work order content is replaced by an example that I am more familiar with:
POST https://api.typesafe.ai/v1/systemone
{
"model": "jev-latest",
"state": "Your app crashed as soon as I opened it after the update. It has been three days. I will use it to submit a report next Monday.",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should this work order be handed to?",
"criteria": {
"billing": "Payment, invoice, refund related",
"technical": "Fault, crash, malfunction",
"sales": "Price consultation, package upgrade, new account opening"
}
}
}
}
returns something like this (indicative, not the original text of a real call):
{
"answers": {
"department": {
"type": "choice",
"choice": "technical",
"probabilities": { "billing": 0.04, "technical": 0.91, "sales": 0.05 },
"confidence": 0.89
}
}
}The
true or false question in the official response is "type": "noul" plus an noul field ranging from 0 to 1; in the Vercel SDK you will see boolean and probability. What you do after you get the result is determined by your own code. For example, if the confidence level is higher than 0.9, it will be automatically assigned, and if it is lower than this number, it will be pushed to a manual look.
Key points: write prompt words well
Jev's "prompt words" are not the same as writing prompts for large models. It is not one big paragraph, but broken into three parts: what to judge, what each question asks, and the definition of each option. Whether the effect is good or not depends mainly on whether the definition of the option is clearly written. The effort that was previously spent on labeling data is now spent here.
Several key points:
1. The boundaries between options must be written down
In the 30 work order test above, Jev judged two fault reports with very calm tones as "customers are angry". It’s easy to guess why: it confuses “the problem is serious” with “the customer is angry.”
vague writing:
"criteria": {
"angry": "The customer is angry",
"calm": "The customer is not angry"
}
Clear writing:
"criteria": {
"angry": "There are obvious emotional expressions in the wording, such as accusations, rhetorical questions, exclamations, threats of negative reviews or refunds. Just look at the tone, not the seriousness of the problem itself.",
"calm": "Describe the problem in a calm tone. Even if the problem is serious (for example, the system is completely paralyzed), as long as the wording is calm, it counts as this category."
}
The second way of writing directly points out the most confusing situation. Wherever you think the judgment may be wrong, write it into the definition.
2. Ask only one thing in one question
If you want to know which department to call, how urgent it is, and whether you want a refund, split it into three questions and ask them together instead of cramming them into one question. Jev originally answers in parallel, and officials say that asking more questions will almost not slow it down.
By the way, the official review found that after breaking the big task into a bunch of small judgments, even Luna's score increased from 51.9% to 66.8%. So even if you don't use Jev in the end, this habit is worth developing.
3. List all options and leave a cover item
If there may be situations that you did not expect in reality, add "other" or "unable to judge". Otherwise, Jev can only choose one of the inappropriate options, and he may choose very confidently.
4. In the scoring questions, you should write clearly what each level means
Don't just write "1 to 5 points", but also write clearly what each level corresponds to:
"criteria": [
"Can be queued for processing: does not affect normal use",
"Processed today: Some functions are affected, but there are alternatives",
"Process immediately: core functions are unavailable, or funds and data security are involved"
]
The more specific you write, the more stable your score will be.

diagram, drawn according to the state / questions / answers structure of the TypeSafe official document, not a console screenshot. Real Playground requires login: https://console.typesafe.ai/playground
at last
Jev is not something disruptive, it won't replace big models, and it won't write a single line of code. What it does is very narrow: where the software needs to make a judgment, it quickly and cheaply gives an answer and a probability that you can probably use to set a threshold.
But the software is full of such small judgments. In the past, they either relied on a bunch of hard-coded if-else, or a large model that was slow and occasionally talked nonsense. Now there’s an additional option: a classifier that talks less, is quick, and never talks nonsense.
Will I integrate it into my project now? I will probably run a batch of data that I have marked first to see what the calibration and misjudgment look like, instead of just reading the official sentence of "zero hallucinations". It is suitable as a switch, not as a brain.
Reference sources
- TypeSafe official release: Introducing System One Models & Jev
- TypeSafe documentation: Introduction · Quick start
- TechCrunch: A new kind of AI model from a ChatGPT inventor is thrilling developers
- Vercel: TypeSafe AI's Jev now available on AI Gateway
- Community independent testing: Jev vs GPT-5.6 Luna vs Claude Sonnet 5 (work order classification) https://github.com/BUNYOD0987/jev-vs-llm
- Community independent testing: Jev vs Luna (review category) https://github.com/mameli/jev-vs-luna
- Analysis of official evaluation methods: https://dev.to/gabrielanhaia/jev-beat-gpt-luna-by-1-point-gpt-6-and-claude-wrote-the-answer-key-314k
- LiteLLM documentation: TypeSafe AI (Jev)
- OpenRouter model page: https://openrouter.ai/~typesafe/jev-latest
- LangChain integration: https://docs.langchain.com/oss/python/integrations/providers/typesafe

