Jev: The AI Model That Doesn’t Write — It Decides

TypeSafe AI launched Jev in September 2026, a "System One" model that returns typed decisions, probabilities and confidence scores as JSON instead of generating text, targeting software decision tasks rather than open-ended writing. TypeSafe AI, founded by Diogo Almeida, who co-invented RLHF, reports roughly 70–500 ms response times and says Jev can be 20–200× faster than frontier LLMs on System-One-shaped tasks, using parallel sampling to evaluate requested decisions together; pricing is based on input tokens with output tokens free. Jev accepts state plus three question types — Noul, Choice and Score — through the typesafe_sdk Python client, returning answers such as a billing department choice with 0.91 confidence.

We have spent years teaching AI models to write . But software often needs something much simpler: “Given this information, what should I do next?” That is the problem TypeSafe AI is targeting with Jev , its first System One model. Jev is not designed to generate paragraphs. It takes a piece of state/context plus structured questions, and returns typed decisions, probabilities, and confidence information that software can use directly. Jev is an AI model from TypeSafe AI , a startup founded by Diogo Almeida, who co-invented RLHF, the training technique behind ChatGPT. It launched in September 2026. The easiest way to picture it: Think of an LLM as a writer . Think of Jev as a decision engine . LLM────────────────────────────────────Context → Generate tokens → Text → Parse / validate → Software logic Jev────────────────────────────────────Context + Questions → Structured decisions → Software logic For example, suppose a customer sends: “I was charged twice for the same transaction.” An LLM might generate: “This appears to be a duplicate transaction. You should investigate…” Jev can instead answer something like: { "department": { "choice": "billing", "confidence": 0.91 } } You hand Jev some information and a few questions. It hands back structured answers JSON that your software can use directly, with a confidence score on each. Because generating text is expensive when all you wanted was a decision. LLMs normally generate tokens one after another : Token 1 → Token 2 → Token 3 → Token 4 → ... Jev says it uses parallel sampling , allowing the requested decisions to be evaluated together rather than generating a long sequence of output tokens. TypeSafe reports roughly 70–500 ms response times and says Jev can be 20–200× faster than frontier LLMs on System-One-shaped tasks. TypeSafe also lists pricing based on input tokens, with output tokens free . So the idea is not: “Build a smarter chatbot.” It is: “Build a cheaper and faster AI component for software decisions.” Psychologist Daniel Kahneman described two modes of thinking. System 1 is fast and intuitive, like recognizing an angry face. System 2 is slow and deliberate, like solving a puzzle. LLMs are System 2 machines. Jev is built for System 1. A rough analogy: SYSTEM 1 SYSTEM 2──────────── ─────────────Fast SlowIntuitive DeliberateQuick judgment Planning / reasoning"This ticket is about billing." "How should I solve this complicated problem?" TypeSafe uses “System One” to describe models focused on fast, structured judgments , rather than open-ended generation. Importantly, this analogy is about the type of task , not a claim that Jev literally thinks like a human brain. Jev only understands three kinds of questions: Here’s what a support-ticket check looks like. The input is: “My payouts have been failing for 3 days.” STATE QUESTIONS "My payouts have + is urgent → Noul been failing + department → Choice for 3 days" + frustration → Score \ / └──────► JEV ◄──┘ │ ▼ one structured answer Here is how you ask those three questions in code: python from typesafe sdk import Choice, Noul, Score, TypeSafeClientstate = {"ticket": "My payouts have been failing for 3 days."}with TypeSafeClient as client: reads TYPESAFE API KEY response = client.system one state=state, questions={ "is urgent": Noul instructions="Does the ticket communicate time pressure?" , "department": Choice instructions="Which team should handle this ticket?", criteria={ "billing": "Payments, charges, refunds, payouts.", "technical": "Bugs, errors, integrations.", "account": "Login, profile, settings.", }, , "frustration": Score instructions="How frustrated does the customer seem?", criteria= "Calm and neutral", "Frustrated", "Very angry or using strong language", , , }, Notice that you define the options. Jev can only pick from them. Its answer comes back as: { "is urgent": { "noul": 0.95 }, "department": { "choice": "billing", "confidence": 0.80 }, "frustration": { "score": 1.04, "confidence": 0.94 }} One call answers three questions. Instead of making three separate LLM calls, you ask Jev all of them at once. TypeSafe says the questions are evaluated in parallel and independently against the same state, so adding more questions barely slows down the response. Because every answer carries a confidence score, you can write ordinary code around it. TypeSafe’s docs suggest a pattern like this: if confidence 0.9: auto act trust itelif confidence 0.5: flag for review double-checkelse: send to human don't guess Speed → 20–200x faster than frontier LLMsCost → 40–400x cheaperPrice → $0.042 per million input tokensOutput → freeLatency → 70–500 msContext → 32K tokens Jev’s answers are locked into a fixed format, so it can’t ramble, invent a fake field, or break your JSON. If your application gives it three choices: A = BillingB = TechnicalC = Account it cannot suddenly invent: D = Please contact our support team... The output shape is defined beforehand. But that does not mean Jev can never be wrong. It can still choose the wrong option , misunderstand a question, or be poorly calibrated. That’s why the confidence score matters. Jev is trained with a method called RLCD Reinforcement Learning for Calibrated Decisions , which punishes confident wrong answers more than uncertain ones. So the safer statement is: Jev removes free-form output hallucination and type errors; it does not remove incorrect judgments. Jev is meant to sit beside LLMs, not replace them: A typical setup looks like this: USER │ ↓ Your Agent │ ┌───────────┴───────────┐ ↓ ↓ JEV LLM Fast decisions Deep reasoning Routing Writing Classification Planning Scoring Explanations Guardrails Code generation │ │ └───────────┬───────────┘ ↓ Your Software For example: Jev decides which tool or model should be called. LLM decides how to solve a complex problem. Code decides what actions are actually allowed. That hybrid architecture is probably more realistic than “ Jev will replace LLMs. ” TypeSafe itself presents Jev as an automation-oriented component that can work alongside more general generative models. Nobody outside TypeSafe knows yet. The architecture isn’t public. What’s known is that it uses a new training method RLCD and a parallel sampler that answers all questions at once instead of word by word. The name comes from the Jevons paradox : when something gets much cheaper, people use far more of it. Probably not instead of LLMs. More likely, alongside them. We may be moving toward systems where different models have different jobs: AI SYSTEM │ ┌───────────┴───────────┐ ↓ ↓ System One System Two Jev LLM │ │ Decide quickly Reason deeply │ │ └───────────┬───────────┘ ↓ SOFTWARE LLMs are extremely powerful because they can generate almost anything. Jev gives up that flexibility to gain speed, structure, and decision-oriented outputs . If LLMs are the brain that thinks and writes, Jev is the reflex . It’s fast, cheap, and structured. The best AI systems will probably use both. And that may be the real idea behind System One models: Not every AI problem needs a model that writes. Sometimes software just needs a model that decides. Jev: The AI Model That Doesn’t Write — It Decides https://pub.towardsai.net/jev-the-ai-model-that-doesnt-write-it-decides-6f3d91a78c3a was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.