10 ways to use Jev, after testing it on 3 of my own tasks

Chinese narration · 720p · captions track (zh) · MP4

Article: 10 ways to use Jev, and the 3 things I tested

I've recently been trying out a somewhat unusual model called Jev. It was released by a company called TypeSafe in September 2026. Jev doesn't write essays, and it doesn't chat with you. It only answers questions that come with options, and it gives you a probability for each option.

I care about it because my own workflow is full of questions like that. I use a kanban board in Obsidian to manage the tasks I hand off to AI. For every card I have to decide a few things: which tier of LLM gets it, how much reasoning to turn on, and which project it belongs to. Each of these is a single judgment call. None of them needs a paragraph of text. So I wanted to know whether I could hand these calls to Jev, and where in the system it would fit.

This article starts by explaining what Jev is, then covers three things I tested myself. After that come the 10 use cases I've put together, and how the work splits between Jev and LLMs. Finally, I cover where it falls short, which matters just as much as everything before it.

1. What Jev is

TypeSafe officially calls Jev a System One Model. The name comes from the book Thinking, Fast and Slow, which splits human thinking into two systems: System 1 is fast intuition, and System 2 is slow reasoning. Jev is going after the first one.

Its input has two parts. The first is a piece of state, which can be a passage of text, a card, or a post. The second is a set of typed questions. There are only three kinds:

• Multiple choice: pick one of several options, such as which project this card belongs to.
• Score: give a score, such as how expensive this SQL query is.
• Yes/no: answer yes or no, such as whether this statement can go straight to production.

The output isn't text. It's a probability for each option, or a score for score questions. An ordinary large language model (LLM) generates its output one word at a time. Jev does a single forward pass, meaning it runs the input through the model once from start to finish, and that's the result. Because it doesn't generate text, it can't output anything outside the options. If you write code, that means the return type is fixed, and you can branch on it directly.

TypeSafe also says its probabilities are calibrated. Calibrated means the confidence it states should match how often it's actually right. Think of a weather forecast: on the days it says there's a 70% chance of rain, it should actually rain on about 70% of them. That's TypeSafe's training goal. I haven't verified it, so for now I'm just noting it.

The speed and pricing are also official figures. The official figure is 70 to 500 milliseconds per judgment. Billing is per token, the unit a model uses to count text, roughly a word or a piece of a word. Input costs $0.042 per million tokens, and output is free, because there's no text-generation step. Their example: scoring 50 million product reviews costs about $20.

I also measured latency myself through the API, and my numbers include the network round trip. My median latency was 524 ms for the SQL experiment and 545 ms for the task-routing experiment. That's a bit slower than the top of the official range, but still only a little over half a second.

TypeSafe itself calls it "smart if-statements," for classification, routing, scoring, extraction, and branching. I'd rather put it another way:

Jev is a learnable if/else.

It fits anywhere you take in some context, make a judgment, and then decide what to do next, as long as you don't need long generated text. For example, if Jev says the probability that "this order looks unusual" is above 0.93, send it for manual review. The 0.93 is a threshold, a cutoff you set in advance, and the number itself is only illustrative. In code it looks roughly like this:

if jev(order, "Does this order look unusual?") > 0.93:
    send_to_manual_review()

To the caller, it's no different from an ordinary function. You pass in some context and a question, you get back a number, and the code handles the rest. The only requirement is that the answer you want can be expressed as options or a score, not a paragraph.

2. Three things I tested first

However good the official numbers look, you still have to try them in your own setting. From September 21 to 23, 2026, I plugged Jev into three things I actually deal with: task routing, kanban classification, and SQL review. What they have in common is that none of them needs any writing, just a judgment. The code and raw results for task routing and SQL review are public at github.com/DDnim/jev-vs-laya. The kanban classification used my own private cards, so it isn't public.

The first was task routing. I wrote 20 synthetic task cards in a mix of Chinese, Japanese, and English, modeled on my personal board. For each card I labeled two answers in advance. One was which tier of LLM it should go to, out of four tiers from cheapest to strongest: flash, sonnet, opus, fable. The other was how much reasoning to use, on four levels from 0 to 3.

The state I gave Jev was just the card text. I described what each of the four model tiers is good for in the question's description. That way, Jev had to do the same thinking I do every day when I assign cards by hand.

For the model tier, it got 17 of 20 right. For the reasoning level, it got 19 of 20, and if being off by one level counts, all 20. The 3 cards where it picked the wrong tier were each off by only one tier, and all of them were borderline cases. One research card I'd labeled sonnet, it sent to opus. A multi-file feature with a finished spec, which I'd labeled opus, it sent to sonnet.

What does that tell us? Deciding "how strong a brain does this need?" is a textbook small judgment in itself. An agent is a program that has an LLM work through a task step by step, and it has to make decisions like this at every step. I'll come back to this in the use cases.

The second was project classification on my real board. My board has 151 real cards, and 93 of them have a project label, which gave me a ready-made answer key. There were 7 options in total: 6 projects plus "Other." The state I gave Jev was each card's title and body.

It classified 81 of the 93 correctly, for 87% accuracy. That number on its own isn't especially high. The more interesting part is its confidence. When I looked only at cards where its confidence was above 0.7, there were 81, and 77 of them were right: 95% accuracy.

It knows which ones it isn't sure about.

So the probability isn't just decoration. Use the high-confidence answers directly, send the low-confidence ones to a human, and the workflow naturally splits into two paths. A person only has to look at the small set of cards that's left.

The third was SQL review, the set I designed most carefully. I prepared 14 PostgreSQL statements, each with a note on what it was supposed to do. Each one also came with the same schema: 5 tables, with the row counts and indexes for each.

Of the 14, 6 were correct and the other 8 each hid a bug. One double-counted amounts after a JOIN. One compared with = NULL, so it never matches anything. One DELETE had a misplaced OR that would wipe out every order older than two years. One UPDATE had no WHERE and would change all 80 million rows. And one should have used NOT EXISTS but was written as a cross join.

The remaining three are also traps people fall into in real work. One ran CREATE INDEX on an 80-million-row table without CONCURRENTLY, which locks the table. One used BETWEEN, which counted an extra day. And one had a leftover OR 1=1 injection.

I asked Jev four questions about each statement. First, can it go straight to production, meaning it's read-only and safe to run without human sign-off? That's a yes/no question. Second, is the logic correct? Also yes/no. Third, how expensive is it? That's a score from 0 to 2. Fourth, what category does it fall into? That's multiple choice, with the options report, destructive operation, and schema change.

On the production question, its probabilities were clearly separated. The DELETE, UPDATE, and schema-change statements got only 0.01 to 0.03. Ordinary queries got 0.73 to 0.90, and the one with the injection got 0.10.

On the logic question, the only one it missed was the BETWEEN statement. It thought that one was correct, with a 0.83 probability. An extra day at a date boundary is a well-hidden bug to begin with, but it really did miss it.

These results sharpened my understanding of "type safety." Type safety only guarantees that it won't output anything outside the options. It doesn't guarantee the judgment is always right. Getting only 9 right on the cost question also shows it isn't equally accurate on every question. So before you rely on it, measure it on your own questions.

Besides these three experiments, I also built a small tool, which doesn't count as a formal experiment. It's a Chrome extension, open source at github.com/DDnim/jev-tweet-radar. While I scroll X, it asks Jev about each post exactly once. That single request returns several probabilities at the same time: whether the post is worth engaging with, whether it'll take off, whether it's spam, and so on.

In my own use, one judgment is about 300 input tokens, which works out to roughly one hundred-thousandth of a dollar, and output is free. At that price, asking about every single post is a no-brainer. One caveat: Jev doesn't give reasons, and the text of each post is sent to TypeSafe's API.

3. 10 use cases

Here are the 10 use cases I've put together, in four groups: backend and data, agents, filtering and judging, and real-time decisions. Of these, #1 is the one I think may have the biggest business value, and #2 is the easiest to underrate.

Use case 1 is fuzzy rules in backend software, which I think may have the biggest business value. Traditionally, rules are hard-coded, like triggering a review when an amount goes over 10,000. But plenty of judgments can't be written as a line of code. Is this customer angry? Is this a refund request? How serious is this bug? The same goes for whether an email is a sales lead, or whether a complaint needs escalating right away.

With Jev, each judgment becomes one API call that returns a probability, and the code branches on a threshold. Say you set the threshold at 0.93: anything over that line goes to manual review. These judgments used to depend on someone looking at them, or they just didn't get made. Now they can go into backend workflows like any other rule.

Use case 2 is large-scale offline data processing, which I think is the easiest to underrate. Say you have a billion reviews, logs, or support transcripts, and you only want to know a few things: is it relevant, what's the topic, what's the sentiment, is there purchase intent, is there any risk. Until now, either the rules didn't cover everything, or calling an LLM was slow and expensive.

You can think of this as MapReduce at the semantic level. MapReduce is a batch-processing approach: run the same operation in parallel over a huge amount of data, then aggregate the results. Here the "operation" becomes a semantic judgment. The official figure of about $20 to score 50 million reviews is exactly this kind of job. My kanban classification belongs here too, just at a much smaller scale.

Use case 3 is the agent's cerebellum. Today's agents call an LLM at every step to decide what to do next. But most of those decisions don't need deep thinking: whether to call a tool, which one, whether to retry. Whether the task is done, whether to ask the user, whether to hand off to a human: these are the same kind of small judgment. Jev can make them in a few hundred milliseconds, which leaves the LLM free to think about the hard problems. The task-routing experiment earlier tested exactly this kind of judgment.

Use case 4 is computer use, where an AI operates a computer by looking at the screen. The screen state comes in, and Jev decides whether the next step is to click, scroll, type, wait, go back, ask the user, or finish. The LLM makes the plan, and Jev handles the local judgments across hundreds of small actions. That way you don't have to reason from scratch on every mouse click. In TypeSafe's official demo, Jev plays the shooter Doom in real time, making about 10 decisions per second.

Use case 5 is filtering for RAG and memory. RAG means retrieving material first and then having the LLM answer based on it. A lot of the retrieved chunks are noise. Jev can score each chunk: is it relevant to the question, does it contain evidence for an answer, does it conflict with other material? It can also judge whether a chunk hides a prompt injection, meaning instructions buried in the material that try to hijack the model.

Memory works the same way. Is this piece of information worth keeping long-term? Does this question need a memory lookup? Should an old memory be retired? None of these require answering a question, just a score.

Use case 6 is judging LLM output. Did it answer the question? Did it go off topic? Does it cite evidence? Is the format right? Does it contradict itself? You can also ask, in the same go, whether it's worth regenerating and which of two versions is better. Jev returns multiple probabilities in one request, so you don't need an LLM to write a long critique. The SQL review earlier is this kind of thing: four questions about a single statement at once.

The last four use cases have one thing in common: the judgment has to be fast and cheap, and it happens very often.

Use case 7 is risk control. Fraud, account anomalies, spam, bots, payment risk: all of these just need a yes or no. You can use Jev as a cheap first-layer filter. Requests it's highly confident are normal go straight through, high-risk ones go to rules or a stronger model, and uncertain ones go to a human. That cuts down a lot of what people need to review, and it's the same idea as "use the high-confidence answers directly" from the kanban experiment.

Use case 8 is recommendation and search. Jev doesn't replace vector retrieval or ranking models. It slots in at the final step to make semantic judgments, such as reranking a few dozen candidates, or working out which kind of content the user wants to see right now.

Use case 9 is real-time voice conversation. The system has to judge whether the user has finished speaking, whether a silence is a pause or the end, whether to cut in, and whether a sound is just background noise. These calls have to happen within 100 to 300 milliseconds, and a full LLM is too slow. That's my understanding of what the scenario requires. I haven't tested how Jev performs here.

Use case 10 is game NPCs, the characters in a game controlled by the program. An NPC has to choose whether to attack, defend, retreat, call for help, or take cover, based on the enemy's state, the terrain, and what the player is doing. The LLM handles story and dialogue, and Jev handles the high-frequency behavior choices.

4. How the work splits between Jev and LLMs

This section is my opinion, not test results. My core idea fits in one sentence:

The LLM does the thinking. Jev watches the LLM and keeps it in check.

The LLM answers "how should this be done?" Jev keeps answering a different set of questions: should we do it now, how far along are we, did it work, what's next, do we still need the LLM? Once you separate these two kinds of questions, a lot of system design falls into place.

The first loop is: the LLM generates, then Jev judges. Jev judges whether the output is good enough, whether it answered the question, and whether to redo it. It can also judge whether there are obvious hallucinations, meaning content the model made up. If it needs redoing, Jev also decides whether the same model retries or a stronger model takes over. After the fix, it judges again. Judging is very cheap, so you can do it over and over inside the loop.

The second loop is: the LLM makes the plan, and Jev manages the execution. Say Codex, the coding agent, lays out five steps: find the files, change the code, run the tests, fix bugs, commit. None of these steps needs a fresh call to a strong model. Jev judges which step we're on, whether it succeeded, and whether a given error is worth retrying. It also decides whether to continue, roll back, try a different approach, or bring the LLM back in. The agent goes from thinking deeply at every step to thinking deeply now and then and making lots of fast decisions.

You can hand it compute allocation too. Every request goes to Jev first: easy ones to a small model, ordinary ones to a mid-sized model, and hard ones to the strongest model. That's exactly what the task routing in section 2 tested. Even inside a single answer, Jev could judge whether it's worth thinking for another 5 seconds.

Tool calling is another example. The LLM says "I need to look something up," and Jev gives each tool a probability. For example, web search 0.93, file system 0.04, code execution 0.02; these numbers are illustrative. Once the tool returns, Jev judges whether the material is enough, whether to try different search terms, and when to hand things back to the LLM.

Real-time review is a good fit too. After the LLM writes some code, Jev can judge all at once whether it meets the requirements, whether it misses edge cases, and whether it touched files it shouldn't have. Whether there are dangerous operations, whether to run tests, and whether to ask a human to confirm can all go in the same request. These judgments happen in parallel, so there's no need for the LLM to write a 500-word review.

Putting all of this together, here's how I'd describe the division of labor among the three:

• The LLM is the brain: planning, generation, and complex reasoning.
• Jev is the cerebellum: judging, routing, filtering, scoring, stopping, and verifying, in a few hundred milliseconds.
• Code is the spinal cord: permissions, databases, and the actual execution.

Taking this one step further, what follows is my estimate, not a test result. In the future, completing a task might take 1 top-tier LLM inference plus 100 Jev judgments. What that replaces is 30 top-tier LLM agent calls. I have no data behind this ratio. It's just a direction I've extrapolated from the division of labor above.

So I think Jev's biggest value isn't faster classification. It's freeing the expensive LLM from every single decision point.

5. Where it falls short

After all these use cases, I should lay out its weaknesses too. So far I see four.

First, it gives probabilities, not reasons. That's not enough when you need an audit trail or have to explain why something was rejected. Take loan approvals: someone who gets rejected needs to know why, and a probability can't explain that.

Second, it can still pick the wrong option. The BETWEEN statement in the SQL test is an example: it got it wrong with 0.83 confidence. So set a threshold and send low-confidence cases to a human or to an LLM. A fixed return type doesn't mean the result is reliable.

Third, be clear about where the numbers come from. Most of the speed and pricing figures are published by TypeSafe itself and haven't been independently verified by a third party. My own test samples are small too: 20 task cards, 14 SQL statements, and 93 labeled kanban cards. These results point in a direction, but they can't tell you how it will do on your data.

Fourth, it can't build on its own previous answer. If a later question depends on the answer to an earlier one, you have to send another request. One request can ask many parallel questions, but not a chain of questions where each depends on the one before.

6. Closing thoughts

Back to the question I started with: can the judgments on my board be handed to Jev? Based on my three tests, mostly yes. Picking a model tier, sorting cards into projects, reviewing SQL: none of these needs an LLM to write a paragraph. Jev gives a result you can branch on directly in just over half a second. And when it's unsure, its confidence drops, which gives you a basis for the "hand it to a human" step.

Where it fits is as a cerebellum sitting next to the LLM. The LLM thinks about the hard problems, Jev handles the flood of small judgments, and code does the actual execution.

If you want to try it, my advice is to start with one narrow judgment you're currently handing to an LLM. Prepare a labeled sample first, measure accuracy, misses, and cost, and then decide whether to switch. Don't swap out the whole pipeline on day one.

The X extension mentioned above is Jev Tweet Radar. The Japanese video on the /ja/ page is an earlier version (eight scenarios).