Jev: the AI model that decides instead of writing

Jev is an artificial intelligence model that writes nothing. You send it a context and a set of closed questions, and it returns typed answers with probabilities: an option picked from a list, a score on a scale, or the probability that a statement is true. It was launched in mid-September 2026 by TypeSafe AI, a start-up founded by former OpenAI researcher Diogo Almeida, which raised 40 million dollars at the same time.

The idea is simple and it addresses a real production problem. When an application needs an AI to make a decision, such as sorting a ticket or validating an extraction, the usual approach is to ask a conversational model to answer in JSON, then hope the JSON is valid and the answer consistent. Jev removes that step: the output is structured by construction, and it arrives in a fraction of a second at a very low cost. Here is what it is, what it changes, and three use cases where it is genuinely worth a look.

A “System One” model: deciding rather than generating

TypeSafe places Jev in a new category it calls “System One” models, a reference to the System 1 that Daniel Kahneman popularised in Thinking, Fast and Slow: fast, intuitive thinking, as opposed to slow, deliberate reasoning. Like a large language model, Jev understands natural language. But instead of producing text, it returns decisions and probabilities that code can consume directly.

The official documentation describes three primitives, which can be mixed in a single call.

• Choice selects one option from a list you define, with a probability per option and a confidence value. Example: which team should handle this ticket, billing, technical or account.
• Score places content on an ordered scale you describe, with the same probabilities and confidence. Example: how unhappy is this customer, from calm to very frustrated.
• Noul returns the probability, between 0 and 1, that a statement is true. Example: does this message contain a refund request.

Each question is evaluated in parallel and in isolation against the same context, which the vendor calls the state. Adding questions does not degrade the other answers. TypeSafe measured this on a concrete case: thirteen questions asked about the Wikipedia article on the GDPR, around 54,000 characters. Asking them in a single call rather than thirteen separate calls was 12.2 times cheaper and 10 times faster, with no change in the answers.

Why it differs from an LLM with JSON output

The difference starts with training. Conversational large language models are fine-tuned through reinforcement learning from human feedback, known as RLHF, which teaches them to produce the answers people prefer. TypeSafe points out in its technical primer that Diogo Almeida co-invented that method, before naming its limit: it rewards what pleases, which can encourage sycophancy and confidently worded hallucinations.

Jev is trained differently, with an approach the vendor calls RLCD, reinforcement learning for calibrated decisions. The goal is no longer to please but to be calibrated: across a large number of predictions, the answers the model assigns an 80% probability should be right about 80% of the time. That property is what makes uncertainty usable by a program. A low probability becomes a signal to hand the case to a person or to a more expensive model.

That promise still needs to be read correctly. Calibration is a statistical property, measured across groups of predictions: it does not guarantee that any individual answer is right. Typed output guarantees the format, not the truth. And when the vendor describes a hallucination-free model, The Register rightly notes that the comparison with a model generating free text is partly misleading, since Jev can by construction only answer within the space you gave it.

What Jev costs, and how fast it answers

The figures published on the models page are striking. The current version, jev-1.13, is billed at 0.042 dollars per million input tokens, and output tokens are free. The documentation says most queries complete in about 100 milliseconds, which makes it usable in a real-time interface. Accepted context is 64,000 tokens per request, of which 32,000 for the state plus the longest question.

To picture the order of magnitude, take a simple calculation. A company sorting 100,000 requests a month, at around 1,000 tokens per request counting the message, the useful context and the questions, consumes 100 million tokens. At the listed price, that is 4.20 dollars a month. At that level, inference cost stops being a decision criterion, which changes how you design an architecture. We broke down a full AI budget, where the model often weighs little, in our article on what an AI project costs.

Two precautions before getting carried away. First, the vendor warns that its rate limits are adjusting dynamically to demand, which is normal for a product launched a week ago but should be factored into any capacity planning. Second, English is the main training language: other languages are supported, but not as well. For use on non-English content, test on your own data before any production rollout.

Use case 1: sorting and routing incoming requests

This is the most immediate case. A customer service desk, a sales inbox or a contact form receives messages of very different kinds. Some can be settled with a simple database lookup, others need a language model loaded with business context, and others a person. Sending every message through a large model just to find out what it is about is expensive and takes several seconds.

With Jev, a single call asks several questions at once: what is the intent among a closed list, what is the complexity level on a scale, is this a complaint, does the customer mention cancelling. Code then applies explicit rules. An invoice request goes to an automatic answer with no generative model involved. A technical question goes to a specialised assistant. A complex complaint, or any case where confidence is low, goes to a person.

The benefit is not only economic. The routing policy lives in code, readable, testable and changeable without rewriting a prompt. If management decides to prioritise customers at risk of churning, you change a threshold, not a natural-language instruction whose side effects nobody can measure. That is exactly the boundary we described between AI agents and automation: code stays in control, the AI supplies the one-off judgment.

Use case 2: putting guardrails around an AI assistant

Every conversational assistant in production raises the same question: how do you stop a user from hijacking it, and how do you check it is not saying anything at all. Writing the rules into the system prompt puts them exactly where a bypass attempt tries to get through. Placing a second large model in front of the first doubles latency and cost on every exchange, and that second model can be manipulated too.

The guardrails guide published by TypeSafe proposes another architecture. Every incoming message and every outgoing reply goes through a Jev call that asks a battery of Noul questions, one per identified risk: an attempt to bypass instructions, a request for personal data, an out-of-scope topic, unlawful content. A Score question also rates the severity of potential harm. Code then decides, based on thresholds you set, whether to let it through, send it for review, block it or route it to support.

The benefit comes down to three points: rules written somewhere you control rather than buried in the weights of a third-party model, a check that adds around a hundred milliseconds rather than several seconds, and a structured record of every decision, useful for understanding an incident. Common mistakes in this area are covered in our article on AI agent security. One important caveat: the documentation acknowledges that the current version can be swayed by content designed to manipulate it. A Jev guardrail reduces the risk, it does not replace testing your edge cases.

Use case 3: ranking documents better in a RAG system

A RAG system, which has a model answer from your internal documents, relies on an often neglected step: finding the right passages. Fast search, by keyword or by vector, returns a list of plausible candidates, but cannot tell which one actually answers the question. If the right passage lands in fifteenth place, the generative model will never see it and will answer beside the point.

Re-ranking means scoring each candidate on that shortlist against the question, then putting the best one first. TypeSafe published a test on a dataset of court opinions: 3,565 passages, 40 queries, a 30-candidate shortlist per query produced by keyword search. With Jev re-ranking, the correct passage comes first in 18% of cases against 5% without, and appears in the top ten in 62% of cases against 38%. The test set is small and highly specialised, but the gap is clear, and the cost of the step stays marginal.

The same principle can filter passages before they are sent to the generative model. Less irrelevant context means a more accurate answer, and a lighter bill on the most expensive model in the chain.

What Jev cannot do

TypeSafe publishes an honest list of its own known limitations for version 1.13, last reviewed on 17 September 2026. It deserves a read before any project, because it draws the usage boundary precisely.

Jev does not calculate: arithmetic, counting and date comparisons must stay in code. It reads instructions literally, which means writing exactly the condition you want rather than relying on interpretation. It loses accuracy when buried under a large context unrelated to the question, so filter before sending. It handles double negatives and multi-step reasoning poorly. And it does not generate text: to write a reply, a summary or code, a language model remains the right tool.

That list is not a communication failure, it is a user manual. Jev is a fast decision component to place at the right point in an architecture, not a universal replacement for existing models. We reached the same conclusion about OpenRouter: the right question is never which model is best, but which model for which step.

How to integrate it without getting it wrong

The method the vendor recommends, and which we share, is to start from the application’s expected behaviour and work back to the decisions it needs. Everything that is a known rule, a calculation or an exact lookup stays in code. Only decisions that require language understanding go to the model, as narrow, well-defined questions.

Three habits make the difference. Split a complex decision into several simple questions, then combine them with a formula you control, rather than asking for an overall score. Use confidence as a second signal to decide when to act automatically and when to escalate. And pin the model version in your code once your thresholds are tuned, since the jev-latest alias will point tomorrow to a new version whose answers may differ.

On data, TypeSafe states that it does not train Jev on its customers’ requests and responses, and offers a zero data retention option for enterprise accounts. For personal or sensitive data, where processing happens and any transfers outside the European Union still need to be assessed, as with any AI provider.

What we take away from it

Jev stands for an idea more than a product: not every AI task needs a model that writes. A large share of real-world automation consists of sorting, scoring, checking and routing, and for those decisions a fast, cheap and calibrated model is better suited than a conversational assistant asked to produce JSON.

The product is a week old, its rate limits are still moving and its performance outside English remains to be measured. But for routing requests, guarding assistants and re-ranking documents, it opens up architectures that were until now too slow or too expensive to be reasonable.

We integrate this kind of component into our projects building AI assistants connected to your data, always starting with a test on your own cases. If you have a flow of requests to sort or an assistant to secure, let’s talk.