Jev by TypeSafe: 7 AI Use Cases for a Decision Model
What Jev is, how it differs from an LLM, and where I would use it
This week the whole internet was talking about Jev, the new model from TypeSafe. I took a look, and my first reaction was that this is not another chatbot.
What is Jev?
Jev is a decision model. TypeSafe calls it a System One model, after Kahneman’s fast, intuitive thinking. You send it some state (a string, a JSON object, a conversation) and a list of typed questions. It answers all of them in one parallel pass and returns typed values with calibrated probabilities. No text generation, nothing to parse.
There are three question types:
- Choice picks one option from a set.
- Score places something on a scale.
- Noul returns the probability of a yes or no.
It’s in early access, text-only for now.
Jev vs a classic LLM
| Classic LLM | Jev | |
|---|---|---|
| Output | Generated text you parse and validate | Typed values, defined in advance |
| Sampling | One token at a time | All answers in one parallel pass |
| Latency | 3 to 329 s | 70 to 500 ms |
| Input price | $0.20 to $10 / MTok | $0.042 / MTok, output free |
| Confidence | Prompted, often overconfident | Calibrated probability on every answer |
These numbers come from TypeSafe’s own benchmarks. I haven’t reproduced them, so treat them as a claim to test. Also, calibration holds across many predictions and does not guarantee that a single answer is right.
Why I think it matters
Look at what most AI systems do all day. Yes, they write and summarize. But a wide range of the tasks inside them are classification: route this, flag that, pick one option out of five. And we send all of them to a big generative model, because that was the tool we had.
That works, but it’s slow and expensive for a job that only needs a label and a confidence score. So I went through the projects I’ve worked on and looked for places where Jev would fit. Here are seven.
1. Support ticket routing
Which team owns it, how urgent it is, how angry the customer is. One call answers all three, and the output is plain data your code can branch on: if urgency is above 90% and the customer is on an enterprise plan, send it to the priority queue. The model does the fuzzy reading and your code keeps control of the action. That split is the idea behind every use case below.
2. Agent tool selection
An agent with SQL, search, CRM, email and Python has to pick one at every step. When I look at the traces of agents I’ve built, most steps are just this choice, not deep reasoning. A Choice over your tools, plus a Noul for “should I stop?”, is a good fit. Routing happens far more often than real thinking, so this is where a fast decision layer saves the most.
3. Fraud and account-risk signals
Six failed logins, a new device, a country change, a password reset an hour ago. Rules cover the obvious cases and the gray zone is where it gets painful. Ask for account_compromised and manual_review_required as Noul questions, and feed them into your risk engine next to your existing rules. For anything high-impact, I wouldn’t let the model be the only judge.
4. Guardrails
Put a classifier in front of the LLM to catch prompt injection, sensitive data or spam. Put another one after it to check the format and policy compliance, and regenerate if needed. A cheap model guarding an expensive one makes a lot of sense.
5. AI-derived columns
Every company sits on millions of tickets, CRM notes, reviews and call transcripts that nobody can query. Run the same questions over all of them and you get real columns: topic, urgency, churn risk. After that it’s just SQL. I think this is the most underrated use case, because the cost per call is so low.
6. RAG reranking
Vector search gives you 20 candidates and you want the best 5 in the prompt. Scoring each document against the query is a “how relevant is this?” question, and you can ask about freshness or authority in the same pass. Less noise in the context, and no big LLM call to answer a yes-or-no question.
7. Event-driven automation
IF payment fails 3 times THEN start recovery is easy to write. “Escalate if this looks unusually serious and is about a payment problem” is not. Jev is a probabilistic layer between raw events and deterministic code.
What I take from this
I don’t think Jev replaces LLMs. It’s the wrong tool for chat, code or anything that needs a written explanation. I think it changes how we split the work.
The generative model writes and reasons. Jev tells you which known situation you’re in. Your code decides what happens next.
“Explain why this payment failed” is a job for an LLM. “Does this payment failure need escalation?” is a job for a decision model.
Most of the value here will not show up in a chat window. It will sit quietly inside applications, making millions of small decisions. I’m curious to see how many teams realize that most of their LLM calls were classification all along.