In late September a model called Jev suddenly seemed to be everywhere among developers. Projects with a jev prefix kept landing on GitHub Trending, tech outlets covered it one after another, some called it "a classifier with brains," and others said it would put half of all LLM calls out of work. The biggest difference from a typical large language model is simple: it doesn't write; it only answers multiple-choice questions.
This article answers four questions: what Jev actually is, which decisions in your system it suits, what it clearly does badly, and, if you want to try it, how to split the work with the LLMs you already use.
Figure 1: What Jev does is closer to sorting than writing. You set up the slots in advance; it drops each card into the most likely slot and says how sure it is. The cards it isn't sure about go to a slower model or a person.
Bottom line: Jev suits decisions where the options are known in advance, the volume is high, and latency and cost matter: classification, routing, first-pass moderation and scoring. It writes no text and is weak at arithmetic and multi-step reasoning, and the hundredfold speed and cost gains in its marketing did not show up in independent tests. The safer way to use it is as the first gate, letting confidence decide which answers go straight through and which get escalated to an LLM or a person.
The discussion below draws on TypeSafe’s jev-1.13.0 documentation, Vercel’s adoption data and third-party tests to examine where Jev fits. It remains in early access; check current official information for prices, rate limits and versions.
What Jev is: the facts first
- Who makes it: TypeSafe AI, a San Francisco company founded in 2024. Founder and CEO Diogo Almeida previously spent about four years at OpenAI working on instruction-following research; the other co-founders are Erik Gafni and Sasha Sheng.
- When: On September 15, 2026, TypeSafe announced on its blog that it was leaving two years of stealth, released Jev and opened early access (there is a waitlist, which the company says it is working through as fast as it can). The same day it announced a $40 million seed round led by DCVC.
- What it is: The company calls it the first "System One model," a name borrowed from the fast, intuitive "System 1" in Daniel Kahneman's Thinking, Fast and Slow. Jev is named after the economist William Stanley Jevons, of the Jevons paradox: the more efficient something becomes, the more of it gets used.
- Current version: The docs list
jev-1.13.0as the current model, and both thejev-latestandjev-previewaliases point to it.
Two numbers get quoted a lot when people talk about its popularity, and it matters who said each one:
- Vercel says nearly 13% of paid teams on its AI Gateway used Jev within 24 hours of launch, making it the fastest-adopted model in the gateway's history. Vercel also added that the next test is whether that early adoption lasts.
- The Information reported that investors are discussing an investment in TypeSafe at a valuation above $10 billion. That is a report of funding talks, unconfirmed by TypeSafe, not a completed round.
How it works: state plus questions in, probabilities out
When you use an LLM to make a decision, the usual routine is to write a prompt, ask for JSON, then parse and validate it, and now and then handle an off-topic answer or a broken format. Jev replaces all that with a different interface. You give it two things: a state and questions.
- The state is the material to judge: a customer message, a transaction record, a policy document. It can be a string, a JSON object or an array of text.
- The questions are a set of named questions, each of one of three types, with the shape of the answer fixed in advance.
| Type | What it asks | What it returns | Example |
|---|---|---|---|
| Choice | Pick one option from a set | The chosen option, a probability for each option, confidence | Should this ticket go to billing, technical or sales? |
| Score | Rate on a few ordered levels | A score, a probability for each level, confidence | Is the customer calm, frustrated or very angry? |
| Noul | Is a statement true? | A probability between 0 and 1 | Is this message asking for a refund? |
You can mix all three types in a single request. According to the official docs, every question is evaluated against the same state in parallel and in isolation, so adding questions barely changes the response time and the questions don't interfere with each other. In the official quick-start example, a ticket complaining that a Stripe integration has failed for three days is routed to the technical team (probability 0.85), rated "frustrated but civil," and gets 1.0 on the urgency Noul.
Figure 2: A single Jev call. The model only judges what category something belongs to, how strong something is, or whether something is true. Branching, thresholds and arithmetic stay in your own code.
This design has three direct consequences:
- No format errors. Answers can only be one of the options you defined, so there is no text to parse and no value outside the options. That is what the "0% hallucination" claim in the official blog means, and the blog notes that the number "is not empirical" but guaranteed by the structure. Keep in mind that this only says it won't answer outside the options; it doesn't mean it picks correctly. The accuracy numbers from independent tests come further down.
- Every answer comes with probabilities. Your code can sort by probability, set thresholds or take a different path when the model is unsure, instead of getting a single yes-or-no verdict.
- A different pricing structure. The official price is $0.042 per million input tokens, and output is free. As a rough example at that price, a thousand tickets averaging 400 tokens come to about 400,000 input tokens, or about $0.017 (our own calculation from the list price; the real figure depends on the number of questions and the length of the state).
The docs also set a few hard limits. A single request has a 64k-token context, and the state plus the longest single question can't exceed 32k. A Choice supports up to 255 options. Only text is accepted, so images, audio and video have to be turned into text first. Rate limits are listed as 100,000 tokens and 40 requests per second, but the docs note that demand is very high and the limits may change without notice.
How to split the work with LLMs
Treating Jev as "a cheaper LLM" leads to using it in the wrong places. It and LLMs are good at two different kinds of work, and the examples in the official docs pair them rather than swapping one for the other.
| Large language model | Jev | |
|---|---|---|
| Output | Any text: answers, code, summaries, explanations | Predefined options and probabilities, no text |
| Good at | Open-ended questions, generating content, multi-step reasoning, decisions that need explaining | Fast decisions over known options: classify, detect, score, rank, route |
| Integration | Parse text or JSON, handle format errors and off-topic answers | Get typed values your code can branch on directly |
| Latency and cost | Seconds; output tokens usually cost more than input | The vendor says 70 to 500 ms; output is free |
| Uncertainty | You have to ask the model for a confidence, which tends to be optimistic | Every answer carries probabilities you can threshold directly |
Our take: anywhere you already use an LLM to answer multiple-choice questions is worth evaluating with Jev. Anything that needs it to write something, explain why, or reason step by step should stay with an LLM.
A typical hybrid setup is a refund ticket. Jev first answers three questions in one request: is a refund being requested, does the evidence point to a duplicate charge, and does the policy support a refund. Code then combines those with deterministic checks, such as the order amount, to decide the next step. An LLM is called only when a reply to the customer has to be written.
Decisions that suit Jev
Going by the official use cases and early community projects, these fit its shape best:
- Model routing: Judge a request's intent, difficulty or risk and decide whether it goes to a cheap model, a strong model or a person, which is what model routing means. The vendor lists this as one of its main use cases.
- Guardrails and safety checks: Add a semantic check (a guardrail) before and after an LLM's inputs, outputs and tool calls, such as a suspected jailbreak, leaked sensitive data or a faulty tool call. It is cheap enough to check at every step.
- First-pass content moderation: Use a Noul to decide whether something needs review, then a Choice to sort it into policy categories such as harassment or spam, and let the probabilities decide whether to allow, warn, send to review or block.
- Relevance scoring and reranking of retrieval results: In a RAG pipeline, judge whether candidate passages are relevant to the question, supplementing or partly replacing coarse filtering with embeddings.
- Bulk labeling: Tag large volumes of logs, comments or tickets with intent, sentiment or topic, as input to later statistics or features for classical machine learning models.
- Evaluation and review: Check whether a citation supports a claim or whether an answer follows a given rule. This is the same kind of task as "model as judge" in LLM evals, but it only suits rubric items with a fixed answer shape.
What these have in common: the options can be listed in advance, a knowledgeable person could make each call in a few seconds, and it has to be done many times.
What it's bad at: the weaknesses the vendor lists itself
TypeSafe's docs include a dedicated page on the "jaggedness" of jev-1.13 (last reviewed on 2026-09-17), and it is worth reading before any of the marketing. The main points:
- It reads literally. It answers the question you wrote, not the one you meant. Negations, scoping words and implied conditions are taken at face value, so boundary cases belong in the option descriptions.
- It is weak at math and counting. Counting how many times a word appears in a passage or comparing two numbers is unreliable. The vendor's advice: anything code can calculate, calculate in code.
- It is weak at comparing dates. Don't ask it which date is earlier or whether a date falls inside a window. Let it pull the year, month and day out of the text, and leave the comparison to code.
- Indirection costs accuracy. Double negatives and "a property of a property" questions that need several hops should be split into direct questions.
- Irrelevant content makes it less accurate. A state stuffed with material unrelated to the question distracts it. Filter in code first and send only the fields you need.
- Adversarial content can steer it. The vendor says plainly that Jev doesn't treat the state as hostile by default, so injected instructions or deliberately misleading wording can change its answer. If you use it for prompt injection detection, test it against adversarial samples too.
- It gets confused when the instructions and option descriptions contradict each other. For example, mapping "yes" to "no."
- Probabilities from different phrasings of a question don't convert into each other. The vendor's example: "Is the customer asking for a refund?" and "Is the customer asking for something other than a refund?" as two Nouls add up to 1.19, not 1. A threshold tuned on a Noul can't simply be reused on a Choice.
- It doesn't generate text. When you need to extract a value, the vendor suggests listing the candidates with a regex or a generative model first, then letting Jev pick among them.
Two more points matter for non-English workloads and for data governance:
- Non-English text is not its strength. The docs say English is the primary training language and where accuracy is currently best. Other languages, including Chinese, Japanese and Korean, are handled but not as well, and the vendor advises testing on your own data before relying on it and watching confidence closely.
- It is a closed, hosted service for now. Jev is proprietary and its weights aren't published. The official docs only offer a hosted API, with no self-hosting option; enterprise customers can apply for zero data retention (ZDR). If your data would cross borders, run it through your own compliance process first.
How far the marketing numbers are from independent tests
The most eye-catching claim on TypeSafe's homepage is "up to 193.6x faster and 444.6x cheaper." Both numbers come from the company's own "workflow evals," and the official blog attaches several caveats worth repeating as written:
- The reference answers are the average of two LLMs, GPT-6 Astra and Fable 5.1, so "accurate" here means "agrees with those two LLMs," not "agrees with human labels."
- The workflows were written by members of TypeSafe's model capabilities team, and the company admits "some bias could exist."
- The company itself says these multiples are likely "on the higher end of real world gains."
Third-party tests started appearing less than a week after launch. Their tasks and settings differ, so only results that can be traced to the original write-up are listed here:
- AY Automate (September 19) compared Jev with GPT-5.4 nano, Gemini 3.5 Flash-Lite, Claude Haiku 4.5 and GPT-5.6 Terra on 791 labeled decisions across three tasks covering intent routing and prompt injection detection. Jev's accuracy matched the small models. On 77-way intent routing it trailed GPT-5.6 Terra by about 5 percentage points, a gap that was statistically significant. Its median latency was 0.33 seconds, about 3.6 times faster than GPT-5.6 Terra, and 8-way routing cost about $0.015 per thousand decisions, roughly 4.7 times cheaper than even the cheapest small model. The testers note that they ran it once, used the lowest reasoning setting for the LLMs, and did not test a real client workload.
- A roundup of eight days of community tests (September 24, DEV Community) concluded that Jev returned a valid option on every call, with accuracy level with mid-priced LLMs and 6.5 to 11.5 points behind the frontier models. Its probabilities were off out of the box, but fitting one temperature parameter on 50 to a few hundred of your own labels fixed most of the calibration error.
- Phishing detection is the example that best shows how much the usage matters. Asked directly as one question, "Is this a phishing email?", Jev was only 62.6% accurate. Split into five specific questions, with combination weights fitted on half the labeled data, it reached 95.0% on the other half.
Our reading: "fast and cheap" is real, but nowhere near the advertised hundredfold, and "accurate" depends on the task and leans heavily on how you split the questions and whether you have your own labeled data for calibration. Treating it as a high-speed component that needs tuning is closer to the truth than treating it as "a smarter classifier."
If you want to try it: start with one decision point
If your system already has a step where an LLM answers multiple-choice questions, evaluate in this order instead of replacing everything at once.
- Pick one decision point. Choose a step with fixed options, high volume and a low cost per mistake, such as ticket routing or labeling comments. Avoid irreversible actions like refunds or account bans.
- Prepare 200 to 1,000 historical examples with human answers. This is the baseline for every later judgment and the basis for setting thresholds. Without it you can't know how accurate it is on your own work.
- Break questions into atomic ones. Each question asks one thing, and each option spells out its boundaries, for example "technical team: error messages, failed integrations, broken features." Conditions code can check (amounts, dates, word counts) should be calculated in code first.
- Run it in shadow mode. Keep your current setup in production while sending the same inputs to Jev, logging but not acting on its answers. Compare accuracy, latency and cost.
- Tier by confidence. Use the labeled data to find a confidence threshold. Take Jev's answer directly above it and escalate to your existing LLM or a person below it. In AY Automate's test, routing at 0.80 confidence gave combined accuracy equal to GPT-5.6 Terra alone at only 26% to 28% of its cost.
- Pin the version. Write
jev-1.13.0in production, notjev-latest. The alias moves with new releases, and the thresholds you tuned may stop working.
Figure 3: A tiered setup with Jev first, an LLM second and people last. Set the threshold from your own labeled data rather than copying someone else's number.
For integration, the vendor offers an HTTP endpoint (POST /v1/systemone), Python and JavaScript SDKs, and a skill package for coding agents. Some third-party tests called it through OpenRouter, and it is also available on Vercel AI Gateway. If your system already calls models through a framework like LangChain or a unified API gateway, integration will be cheaper.
Common pitfalls
- Cramming a complex judgment into one question. "Is this candidate a good fit?" combines several judgments, and asking it directly gives poor accuracy. Split it into whether the experience matches, whether the skills are covered, whether there is a hard mismatch, and so on, then combine them in code.
- Treating confidence as accuracy. The official docs are clear that calibration is measured across a batch of predictions and does not guarantee any single answer is right, and independent tests found the out-of-the-box probabilities were off. Always set thresholds from your own data.
- Forgetting a "none of these" option. A Choice can only pick from the given options, so if the real answer isn't among them it will still pick one. Add "none of the above" or "not enough information" to separate those cases.
- Feeding it long non-English text as is. Language and length are two weaknesses that stack, and accuracy drops noticeably. Trim to the necessary fields first and evaluate non-English samples separately.
- Budgeting from the homepage multiples. Real-world speedups and savings should come from your own shadow-mode data.
Who should use it, and who can wait
Good fit:
- Teams already using LLMs for classification, routing or first-pass moderation at high volume, where cost or latency has become the bottleneck;
- Developers building agents or doing harness engineering who want a cheap check or routing step at every stage;
- Engineering teams with labeled data who are willing to spend time splitting questions and tuning thresholds.
Can wait:
- Users who mainly need to generate content, write code or summarize; Jev doesn't help there;
- Teams working mostly in Chinese or other non-English languages without the means to run their own evaluation; it makes sense to wait for more test results in those languages;
- Cases that need self-hosting or can't let data leave the country; the vendor currently has no offering for that;
- Low-traffic apps with a few dozen decisions a day, where a small model is simpler and the savings aren't worth maintaining another component.
Alternatives
- Structured output from LLMs: Mainstream LLMs can output against a JSON Schema, and with retries and validation you get a similar "pick only from the options" effect. It is slower and more expensive, and doesn't give probabilities directly.
- Cheap small models: Small models such as Claude Haiku and GPT nano were roughly as accurate as Jev in AY Automate's test. Their advantages are familiar integration and the ability to generate text as well.
- Classical classifiers: If the categories are stable and labeled data is plentiful, fine-tuning a small text classification model, or using embeddings with logistic regression, can be cheaper and faster still, and fully self-hosted.
- Rules and keywords: For decisions with clear boundaries (does the text contain a phone number, is the order number format valid), regexes and rules are still the most reliable first gate.
To compare these options systematically, see our guide How to evaluate a large language model and test them side by side on the same labeled data.
Summary
Jev is worth watching not just because it is fast and cheap, but because it turns "have AI make a decision" into a typed function call with probabilities that you can write straight into code. For systems that need large numbers of automated decisions, that is a cleaner interface.
But it isn't a smarter LLM, and it isn't a universal classifier. It is good only at fast decisions over known options; arithmetic, dates and multi-step reasoning belong to code or an LLM, and its performance in languages other than English needs your own verification. The safest approach is to start with one low-risk decision point in shadow mode, set thresholds from your own labeled data, and then decide whether to widen its use.