Jev vs LLM: When a Decision Model Beats a Chat Model

Here is a task I kept running into: decide which team should handle an incoming support ticket — billing, technical, or account. Not write a reply. Not summarize. Just pick one, so the ticket lands in the right queue.

The default answer today is a chat model. So you write a system prompt: “You are a router. Classify the ticket. Respond with valid JSON only.” And then it responds with a friendly “Sure! Here is the JSON:” wrapped in a markdown fence. You strip the fence. You json.loads inside a try/except. You add a repair pass that asks it to fix its own JSON. You add a fallback to a default queue. And even when it works, the confidence it prints is decorative — a number the model produced because you asked for a number.

None of that is the model’s fault. You handed a text generator a decision problem, and it did what text generators do: it generated text. The parsing, the validation, the guardrails — that is all the tax you pay for using the wrong shape of output.

The actual difference

Chat LLMs are optimized to produce text that reads well to humans. Decision models are optimized to return judgments that code can consume directly. Jev — TypeSafe AI’s “System One Model”, first released in late September 2026 — is the clearest example of the second category. The name comes from Kahneman’s Thinking, Fast and Slow: System One is the fast, intuitive judge, not the slow deliberate reasoner.

The official docs compress the whole pitch into one line: “No text generation, no parsing.” You send a state — the material to judge — plus typed questions, and you get back typed answers with probabilities. The unit of output is not a sentence. It is something you can put straight into an if statement.

Three shapes of judgment

Choice — you list the options (and can attach what each one covers), Jev returns the pick, a probability for every option, and a confidence. “Which team handles this ticket” is the canonical case: one call, one answer, plus a distribution you can log and monitor.

Score — you define a rubric, Jev grades the state against it and returns a score on your scale, a distribution over the levels, and the legend echoed back. Grading how frustrated a customer email sounds, from calm to very upset, is a typical job — the kind of thing an LLM will happily do in prose that you then have to convert back into a number yourself.

Noul — a yes/no proposition. You get a single 0–1 probability, with no separate confidence field; you threshold it in code. “Is this message urgent?”, “Is this order a failed delivery?” — questions where the honest answer is a probability, not a paragraph.

All three can ride in one request against the same state, evaluated in parallel and independently — extra questions add almost no latency.

Which one do you need?

Your feature needs…	Reach for
A classification or routing decision	Jev · Choice
A reply a human will read	LLM
A grade against your own rubric	Jev · Score
Multi-step reasoning weighing many factors	LLM — or split the judgment into atomic Jev questions and combine them in code (the approach TypeSafe itself recommends)
A yes/no probability	Jev · Noul
Code generation, math, counting	Plain code — then, if useful, Jev on the result

Cost

Jev bills $0.042 per million input tokens, output free. Mainstream chat models run roughly $0.20–$10 per million input tokens — on the same basis, about 4.8× to 238× Jev’s input price. TypeSafe’s own benchmarks claim around two orders of magnitude faster and cheaper on System One tasks (193.6× and 444.6× in their write-up); treat vendor benchmarks as vendor benchmarks, but the direction is plausible, because deciding is simply less work than composing text. A fair caveat: this compares input price per token — your total feature cost depends on how many tokens each model needs for the same job. The full math is laid out on the pricing page.

What Jev is genuinely bad at

Honesty section, because it matters: Jev’s accuracy drops on arithmetic, counting, comparing dates, indirectly-phrased questions, and states stuffed with irrelevant details that bury the signal. English is its best language; Chinese and other CJK languages are supported but not guaranteed to match English accuracy. And it will not explain itself — no reasoning traces, no rationales, just the decision.

The practical rules I would ship with: keep exact calculations in your code and only ask Jev about the result; phrase questions directly; treat a low confidence score as “escalate to a human”, never as a conclusion to act on.

Usually, you want both

The dichotomy in this article’s title is a bit false, and that is the real conclusion. In a working system the LLM is the one talking to the customer — drafting the reply, summarizing the thread — while a decision model quietly makes the calls behind it: triage, routing, prioritization, filtering, escalation thresholds. Your code is the glue between them.

Picture one support flow end to end. A ticket arrives; Jev decides the team and the urgency in one call. An LLM drafts the reply in that team’s voice. Before sending, Jev checks the draft against the customer’s frustration score — is this reply calibrated for how upset they are? Escalation is another Noul question. Every step that is a judgment goes to the decision model; only the one step that must read like a human goes to the chat model. Nothing in that pipeline parses prose to extract a decision, which is precisely the point.

So the next time you catch yourself writing “respond with valid JSON only” into a prompt for what is really a yes/no question — that is the moment to reach for a decision model. Try the flow hands-on in the playground, then skim the five-minute API guide to see how little code it takes.