--- title: Jev and why not everything needs an LLM description: Jev turns questions into decisions without generating text. An idea that could change how we divide work inside agents. url: https://www.felixsanz.dev/articles/jev-and-why-not-everything-needs-an-llm language: en published: 2026-09-21 updated: 2026-09-21 tags: - ai - development alternate-es: https://www.felixsanz.dev/es/articulos/jev-y-por-que-no-todo-necesita-un-llm --- # Jev and why not everything needs an LLM ## Introduction Every time our software needs to understand something, we call an LLM. We ask it to classify an email, score an answer, choose a tool, or decide which model should handle the next request. Even when the output can only be A or B, we reach for **a machine trained to write paragraphs**. It works. I have used this approach myself in several decision systems, for example to assign a popularity score to different AI models. At Runware, I also built a router where the user specifies how much speed, quality and price matter, and a judge chooses the model that will handle the request. You provide the data, define a schema and receive a decision that the code can use. On September 15, 2026, TypeSafe introduced [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev), a model designed to do this work without generating text. It receives unstructured information and returns choices, scores and probabilities. The company claims it can do this 40 to 200 times faster than an LLM with similar capabilities, and sums it up with an even more striking line: **Jev cannot hallucinate**. The temptation is to debate whether this is a new class of model or a classifier with a particularly polished API. Both possibilities are interesting, but there is a more useful question: why are we using **a generative model for every small decision** an agent makes? In this article we will see what actually changes between Jev and an LLM with structured output, where its claims begin to crack, and why the idea matters even if we never use the product. Agents may not need a smarter model. They may simply be assigning **too much work to the same model**. ## The problem is not generating JSON A modern LLM can already return a structured response. With [Structured Outputs](https://openai.com/index/introducing-structured-outputs-in-the-api/), for example, the provider restricts the tokens available during generation so the result follows the requested JSON Schema. If a field only accepts `model-a`, `model-b` or `model-c`, the model cannot return another identifier or add an explanation outside the object. This solves an important problem. We no longer have to cross our fingers and hope every brace is in place, or extract JSON from a Markdown block. The format stops being a suggestion and **becomes a contract**. But a valid contract does not guarantee a correct decision. The model still has to interpret the context, choose a value and generate it token by token. The schema limits how it can answer. It does not improve the judgment behind that answer. > [!NOTE] > **The same contract does not mean the same model** > TypeSafe publishes an [adapter](https://github.com/typesafe-ai/system-one-adapter-python) that reproduces its models' interface with LLMs from OpenAI and Anthropic. This proves that we can imitate the API with structured output. It does not prove that Jev uses the same mechanism internally. That model router is a good example. The user assigns a weight from zero to five to speed, quality and price. The judge receives those priorities along with each model's scores. Its only useful output is **the identifier of the model that will handle the request**. The response can be perfectly structured, but we invoked a generative model to choose an identifier. **The model's ability to write stops mattering** as soon as we parse the JSON. Jev starts from the opposite idea. If the result will feed directly into software, it does not first generate a string that we later turn into a decision. Its output is already the decision. Speed1 Quality5 Price2 Which model should handle the request? LLM + JSON Schema Generates the response from left to right`{ "model": "model-b" }` Jev Evaluates the options and returns the distribution - `model-a`**12%** - `model-b`**63%** - `model-c`**25%** ## A model that decides instead of writing [TypeSafe calls System One](https://docs.typesafe.ai/concepts/system-one) a family of models designed for fast decisions. The name refers to the intuitive mode of thought described in *Thinking, Fast and Slow*. Jev is the first member of that family. A request has two parts. `state` contains the information the model needs, while `questions` describes the decisions we want to make. Jev 1.13 supports three question types: - `Choice` selects from up to 255 options and returns a probability for each one. - `Score` rates something on an ordered scale with between two and ten levels. - `Noul` responds to a statement with a probability between zero and one. The output contains no explanation or free-text field. It also cannot invent a fourth option if we only give it three. Instead of composing the response from left to right, **it evaluates every question in parallel** against the same state. We can measure this difference. In a [public API test](https://github.com/WallerChen/jev-measured), sending one, three, four or five questions produced internal times of 70, 72, 81 and 74 milliseconds. This does not prove that every workload will take exactly the same time, but it supports the claim that the questions are not answered as part of one long sequential response. It also lets us ask questions ahead of time that we may not end up needing. In the pattern TypeSafe calls [speculative fan-out](https://docs.typesafe.ai/patterns/fan-out), a support system can calculate the category, severity, frustration and likelihood of a refund request at the same time. The code then uses the relevant answers and ignores the rest. We replace several consecutive calls with **parallel questions and explicit routing in code**. The [current version](https://docs.typesafe.ai/models) accepts up to 64k tokens per request, works only with text and costs $0.042 per million input tokens. TypeSafe does not charge for output tokens because there is no text sequence to measure. English is also its primary language, and the company says that is where it performs best. ### Three operations, not arbitrary JSON Jev is more limited than an LLM with JSON Schema. It cannot produce a nested structure with names, dates, summaries and arbitrary lists. We can ask many questions in the same call, but they all reduce to **choices, scales or probabilities**. That limitation is part of the design. An LLM transforms an open-ended request into another open-ended representation. Jev is useful when **we know the answer space in advance** and the difficult part is deciding where each case belongs. This fits tasks such as classifying requests, prioritizing tickets, evaluating signals or choosing a route. It does not fit writing an email or summarizing a document. It cannot write the argument you are reading either. Jev **does not replace the LLM**. It takes away work that may never have belonged to it. ### What we still do not know TypeSafe presents Jev as a new architecture with a parallel sampler and a training method called Reinforcement Learning for Calibrated Decisions, or RLCD. So far, it has not published a paper, the parameter count, the training data or enough detail to reproduce the system. The company's documentation describes RLCD as a third way to adapt pretrained language models. [TechCrunch](https://techcrunch.com/2026/09/18/a-new-kind-of-ai-model-from-a-chatgpt-inventor-is-thrilling-developers/) describes it as a transformer-based model and notes that it may start from an open-weight LLM. TypeSafe has not confirmed what sits underneath. Therefore, we can test the API's behavior, price and speed. We can also study its results. What we still cannot verify is whether this is **a genuinely new architecture** or how much of the improvement comes from training, inference or the interface design. ## It can be wrong without hallucinating The phrase "Jev cannot hallucinate" makes a great headline because it contains a technical truth and invites an easy misreading. If we ask an LLM whether an email is legitimate and require strict JSON, it can return **a valid structure with the wrong answer**. It could also invent an explanation or a fact if we give it text fields. Jev removes this second possibility. It can only distribute probability among the answers we defined. That does not prevent the first one. If the correct answer was A and Jev chooses B, we have a classification error. We do not usually call it a hallucination because the model has not generated a new claim outside the allowed space, but the software executing the decision will not care much about the terminology. Jev removes the hallucinations that come with free-form generation, **not errors in judgment**. The contract can be flawless and the decision can still be wrong. ### Confidence is not a guarantee `Choice` and `Score` responses include the full probability distribution and a confidence value calculated from its shape. A concentrated distribution means the model sees one clear option. A flat distribution means it is uncertain between several. That confidence is not the probability that one particular answer is true. **Calibration is measured across many cases**, not one decision. If decisions assigned an 80% probability are correct roughly 8 out of 10 times, the system is well calibrated in that range. The next decision can still be one of the two failures. This is why the [confidence documentation](https://docs.typesafe.ai/confidence) recommends setting thresholds with real data from the use case. A decision below the threshold can be routed to a person or another model. The right value also depends on risk. A reversible action can tolerate more uncertainty than permanently deleting data. Confidence and risk example**The same confidence level is not enough for every action** Confidence0.72 - `A`**81%** - `B`**10%** - `C`**9%** Reversible action**Add a label** Threshold 0.55**Execute** Destructive action**Delete data** Threshold 0.9**Confirm** Jev does not present every decision with the same degree of certainty. It provides **a number that the code can use** to decide what happens next. But measuring it and setting the threshold remain our responsibility. ## The idea predates Jev Classifiers **have been making decisions without generating text for decades**. Their traditional problem was rigidity. We defined a set of labels, collected data, trained the model and repeated the process whenever the task changed. Language models began to loosen that constraint. In 2019, [zero-shot classification based on textual inference](https://arxiv.org/abs/1909.00161) already let us describe labels in natural language and use them without training a specific classifier. Later projects such as [SetFit](https://arxiv.org/abs/2209.11055) and [GLiClass](https://arxiv.org/abs/2508.07662) have continued to give classifiers more of that flexibility. The reward models used to train LLMs do something similar from another angle. They do not write the best response. They read several and **estimate which one best satisfies a set of criteria**. The [InstructGPT paper](https://arxiv.org/abs/2203.02155), for example, replaced the model's language output with a projection that produced a scalar reward. There are also models such as [Llama Guard](https://arxiv.org/abs/2312.06674), designed to classify content, and routers such as [RouteLLM](https://arxiv.org/abs/2406.18665), which learn when a request is worth sending to a more expensive model. Model-based judgment existed long before Jev. The difference is how TypeSafe packages those ideas. Jev accepts new criteria with every request, returns probability distributions and answers several questions after reading the context once. It tries to preserve **the convenience of programming with natural language** without always paying the cost of generating it. ## Replacing the LLM does not always improve the system The launch figures compare Jev with large models inside workflows prepared by the TypeSafe team. The company itself acknowledges that the reported 193.6× speedup and 444.6× cost advantage are probably near the upper end of what we will see in real tasks. Its reference is also an average across two proprietary models rather than independently annotated ground truth. The first external tests tell **a less spectacular and much more useful story**. In a [comparison of 100 synthetic reviews](https://github.com/mameli/jev-vs-luna) run three times, Jev reached 96.13% per-field accuracy and Luna reached 97.13%. Luna was 2.4× slower and each call cost an average of 4.88× more. One Jev request also returned an HTTP error after 41 seconds, enough to remind us that a fast median does not eliminate long tails or infrastructure failures. The result does not prove that either model is universally better. It only shows that, in a simple classification task, a small LLM with strict JSON can maintain **similar accuracy**. Jev's advantage was **cost and latency**, not a clear lead in intelligence. A [benchmark with 2,000 phishing emails](https://github.com/anisselbd/jev-phishing-bench) was much harsher. Asked directly whether someone should click the link, Jev achieved 62.6% accuracy and Claude Haiku 4.5 reached 81.3%. Jev was also less well calibrated. It was faster and cheaper, but **it made too many mistakes to automate that decision**. If the analysis ended there, Jev would simply be a very cheap classifier that lost to a small LLM. The experiment continued, and that is where it becomes interesting. ### The right questions matter more than the model Instead of asking for a direct verdict, the benchmark broke the email into five signals: whether the sender and link domains differed, whether the link used a URL shortener or free hosting, whether the message asked the user to sign in or open a document, whether it tried to create urgency, and whether the sender looked generic. It then combined those probabilities with logistic regression. On the held-out half of the dataset, Jev reached 95% accuracy. The same decomposition with Haiku reached 93.2%. The difference was not statistically significant and Haiku retained a higher AUROC, but it took 5 times as long and cost about 27 times more. There is one more uncomfortable surprise. **Simple rules already achieved 91.8% accuracy** using only the link and sender domains. The dataset is synthetic and much of the problem can already be captured with those rules. Some decisions do not need a model at all. The lesson is not that five questions magically turn Jev into the best model. The signals were designed after studying the dataset taxonomy, a limitation that the benchmark itself explains. The lesson is that **the architecture of the problem can matter more than the model**. Asking "is this phishing?" forces the model to solve everything at once. Asking about specific signals separates the fuzzy judgment from the final rule. The model estimates what we cannot express well. The code combines the results in a visible and testable way. 2,000 emails in series Direct verdictFive signals Replay Email*→***Model verdict***→*Decision CorrectError **Jev**0 / 2,000 Accuracy 62.6% p50 latency 239 ms Cost / 1,000 $0.0384 **Claude Haiku 4.5**0 / 2,000 Accuracy 81.3% p50 latency 687 ms Cost / 1,000 $0.4622 Haiku is more accurate, but takes almost 3 times as long and costs 12 times more. No model**Simple rules · 91.8% accuracy** Haiku is more accurate, but takes almost 3 times as long and costs 12 times more.The difference in accuracy was not significant. Haiku takes 5 times as long and costs 27 times more. ### Some of the speed comes from outside the model A [Browser Use experiment with Jev](https://github.com/browser-use/jev-ultrafast) applies the same separation to a browser agent. Jev chooses the operation and the element it should act on. A small LLM only steps in when the agent needs to write text. The code then executes the action and verifies the result separately. The repository shows a flight search completed in 7.073 seconds. Across six alternating runs, the median fell from 9.450 to 7.092 seconds and browser protocol calls dropped from 1,092 to 101. This is not a general benchmark. It covers three repetitions of one task in a single browser profile. And **the model alone does not explain the improvement**. Much of it comes from reading the DOM more efficiently and reducing calls to the browser. Giving Jev all the credit would be unfair. But that is precisely what makes it interesting. An agent's speed **does not depend only on the model**. It also depends on keeping state, execution and verification from getting in each other's way. ## An agent does not need a single brain For the last few years **we have used the LLM as a universal CPU**. It interprets the request, decides what to do, generates the arguments, calls tools and explains the result. When something fails, we add another instruction to the prompt and hope all those responsibilities still fit inside the same conversation. Jev suggests an architecture that is less convenient at first, but clearer as the system grows. TypeSafe's own [guide](https://docs.typesafe.ai/concepts/how-to-build-with-system-one) insists that System One is not an agent, does not choose its next action and should not control the flow. The idea is to integrate it into a conventional software workflow, where it handles bounded decisions while code stays in control. Divide an agent's workload Generate**Generative LLM** Produces language or content that was not defined in advance. Decide**Decision model** Chooses or scores alternatives we already know. Execute**Code** Applies exact rules and performs the operation. Supervise**Person** Steps in when uncertainty or risk becomes too high. ### Generate The LLM handles the open-ended tasks. It can research, summarize, propose a plan, transform information or write. It can also interpret an ambiguous request before a closed answer space exists. If we need to explain why an image does not work or write a query, there is something to generate. The same applies when we need to turn several sources into a report. **The flexibility of language is an advantage here**, not a residue we will discard after parsing the output. ### Decide A model such as Jev can step in once we know the alternatives. It classifies, scores, prioritizes or chooses a route. It does not have to write the decision or simulate a conversation to reach it. In the router I mentioned earlier, the user scores the importance of speed, quality and price from zero to five. The judge combines those priorities with the model scores and returns the one that will handle the request. A model such as Jev could replace only that judge. This does not guarantee that the router would improve. We would have to measure it with real traffic and results. It does preserve a clear boundary: **the code applies the rules and the model makes the decision**. ### Execute and verify Code should remain responsible for **what we can express exactly**. It calculates the total cost, checks availability, applies permissions, discards models above the maximum price and executes the call. It also verifies whether the result meets any conditions we can evaluate without another model. Jev's own documentation acknowledges that the model struggles with counting, arithmetic and date comparisons. Asking it to decide which model is the best fit can make sense. Asking it to check whether a model exceeds the maximum allowed price introduces uncertainty where none existed. ### Supervise A person steps in when confidence is low or an operation is irreversible. The same applies when a case falls into a category the system has never seen. **Not every case belongs in the automated path**. This split does not always need all four pieces. A rule may be enough. A creative request may only need the LLM. The important part is to stop assuming that every slightly ambiguous task automatically belongs to the same generative model. ## Jev matters even if it is not a revolution TypeSafe may eventually publish a genuinely different architecture. Jev may instead turn out to combine an encoder with a decision head, while much of its advantage comes from calibration training and the surrounding infrastructure. We cannot settle that with the information currently available. Other projects are already exploring a similar design in public. [Laya](https://github.com/NandhaKishorM/laya) combines ModernBERT with a decision head and offers operations compatible with `Choice`, `Score` and `Noul`. There is also a [Qwen3 0.6B model trained with RLCD](https://huggingface.co/anthonym21/qwen3-0.6b-rlcd-decision). Their results do not prove that they have reproduced Jev's quality, but they do show that **this direction can be investigated in the open**. And that category deserves attention. Generative LLMs displaced many classifiers because we could program them with a sentence and use them on tasks that did not justify collecting a dataset. Jev tries to preserve that flexibility while recovering some properties we lost along the way: bounded decisions and usable probabilities, with many questions answered in parallel. The combination can be valuable even if Jev did not invent every ingredient. We do not need to call it a "new brain for AI" either. Sometimes a good product is simply about **drawing a useful boundary** where everyone had grown used to seeing none. ## Conclusion Jev does not prove that LLMs are unnecessary. It shows that **generating, deciding and executing are different jobs**, even if we have used the same API for all three for years. I will still need a generative model when the system has to interpret or create something I cannot define in advance. To choose among known options, I may prefer a model trained to decide. And when an exact rule exists, I will still prefer to solve it with code that always returns the same result. The mistake is not in using an LLM. It is turning it into the only intelligent component in the system. If there is nothing to write, perhaps we do not need to **call a model that writes** either.