Decision models vs language models: what Jev is and when to use it

Some jobs need words and some need a decision. Learn what a decision model like Jev does, what it cannot do, and when Claude is the better fit.

Most of what you have practiced so far is about language: asking Claude to draft, explain, summarize, or think out loud with you. That is where Claude shines.

Some jobs are not really about language, though. They are a stream of small, repeated calls. Is this email a refund request? Does this ticket need a human? Is this lead a good fit? On September 15, 2026, a company called TypeSafe AI launched Jev, a model built only for that second kind of job.

You may never use Jev. It is still worth understanding, because it sharpens a skill you need every day with Claude: knowing what kind of tool a task actually calls for.

What a decision model returns

A language model like Claude answers in words. A decision model answers with a typed value: a yes or no, one choice from a list you provide, or a score. Every answer comes with a confidence number, and TypeSafe trains Jev so that number is calibrated. In plain terms, when it says it is very sure, it should be right about that often. That is the maker's claim, so teams still check it against their own results.

Here is the part that surprises people: Jev cannot write text. No summaries, no emails, no explanations. You ask narrow questions and it returns decisions.

Two more details matter. You can ask several questions in one call, and they all run in parallel, so an extra question barely adds any wait. And it reads up to 32K tokens of context per call, which is room for a long email thread or a detailed support ticket.

The four-part rule

Teams that use decision models well follow one pattern. Picture a queue of refund emails:

Code computes the facts. When was the order placed? How much was paid? Software looks those up. No model guesses them.

The model makes a narrow judgment. "Is this customer asking for a refund, yes or no?" One question the model is genuinely good at.

Code applies the policy. "Refund requests inside the return window are approved." A written rule, applied the same way every time.

Hard rules win. "Large refunds always go to a person" overrides everything, no matter how confident the model is.

Notice how small the model's job is. That is the point. The narrower the question, the more you can trust the answer, and the easier it is to check.

What it is not

A decision model is a decision layer. It is not a strategy, and it is not an edge. It will not tell you what your business should do, and it will not notice that you asked the wrong question. If anyone can call the same model, your advantage comes from the questions you design and the rules you wrap around them.

Most of the time, you will not need one. If a task happens a handful of times a week, or the answer needs any explanation, Claude is the simpler choice. A decision model starts to make sense when the same narrow call repeats many times, the answer is a label rather than a paragraph, and you want a confidence number you can set a threshold on.

Where Claude still fits

Even when a decision model does the sorting, Claude is often the best partner for designing the system around it. Ask Claude to help you break a messy process into facts, judgments, policy, and hard rules. Ask it to draft the narrow yes-or-no questions, and to point out where one question is really two questions in disguise. Then let each tool do the job it was built for.

Language models like Claude write, explain, and think with you. Decision models like Jev return typed answers (yes or no, a choice, a score) with calibrated confidence, and cannot write at all. Use the four-part rule: code computes the facts, the model makes a narrow judgment, code applies the policy, and hard rules win. A decision model is one layer inside a process, not a strategy. When in doubt, start with Claude.