Direct answer
You write the list of answers; it picks one
A System One model does one thing. You give it something to look at. You give it a question, plus the list of answers it is allowed to give. It picks one from your list and tells you how sure it is. It never writes a word.
So it takes the decisions your software already makes all day: the ones where the answer is one of a handful of options, and where paying a language model to spell that option out is the expensive part. Which of those decisions people actually hand to it is now a matter of public record. TypeSafe released Jev in September 2026, and within a week a community index of projects built on it passed 802 entries.
The answer
Eight System One model use cases, most-built first
The order comes from an ecosystem tracker that counts how many separate implementations exist for each one.
| Pattern | What it does | Why this shape fits |
|---|---|---|
| Supervising an agent | Judge every tool call an agent is about to make, and hold the risky ones | It runs on every single call, so it has to be cheap and fast. The answer is always hold, allow or flag |
| Context compaction | Score each tool call and result in a long conversation, drop what is no longer needed | One yes-or-no per item, hundreds of items, and nothing gets rewritten. Ask a model to summarise instead and you lose exact file paths and error strings |
| Model routing | Classify each request and send it to the cheapest model that can handle it | You know every model you might send it to, and the list is short. That is exactly a choice question. The tracker counts at least ten separate implementations |
| Real-time control | Pick the next click, key or spoken command while something is still moving | You can afford one decision every few hundred milliseconds. From a model that writes out its answer, you cannot |
| Scoring content | Grade drafts, ads or submissions against criteria you name | Scoring against levels you describe is one of the three answer types, and dozens of questions fit in a single request |
| Trading decisions | One buy, sell or hold per market tick | A fixed set of actions on a fixed clock. What matters is speed, not wording |
| A predicate inside other software | Semantic conditions in SQL, shell history, editors and log pipelines | It behaves like a function that returns a number, so it fits in places a language model does not |
| Narrow vertical extraction | Pull fixed fields out of forms, filings and papers | You already know every field you want, and listing them is how you ask |
Look at what is not in that table. Nothing in it writes text. Nothing in it picks an option that was not already on the list. Those two absences are the boundary.
Limits
What Jev is bad at
TypeSafe publishes a list of what Jev is bad at. It reads literally, so negation trips it up. It is unreliable at counting, at arithmetic, and at putting dates in order. Accuracy drops when an answer needs several hops of indirection, and when the state you send carries a lot of material the question does not need. Text inside that state can mislead it, the same way a prompt injection misleads a text model.
Three more findings come from people who tested it themselves.
- Long option lists degrade. One report puts a twelve-way choice on real bookkeeping data at 0.40 accuracy. Splitting one wide question into several narrow ones is the usual fix.
- A high confidence number is not a high accuracy rate. In one large independent evaluation, rows with confidence at or above 0.9 were right 72.2 percent of the time. Confidence tells you how tightly the model's belief sits on one answer. That is a different thing from how often it is right.
- Order and phrasing move the answer. One verifier's rulings flipped on 5.8 percent of cases when the evidence order changed.
Those are other people's numbers, measured on other people's data. They do not give you a failure rate to plan around. What they tell you is to measure on your own data before you put a threshold in front of anything that matters.
Your own work
Does your use case fit?
If you can write down every answer your code is prepared to accept, this shape fits. If you cannot, it does not, and prompt work will not change that. Listing the answers is how you talk to this model, not a restriction on it.
Then ask two more questions. Does the decision happen often enough for its cost to matter? Forty times a day does not justify adding a provider. And can your system say, in words, what is currently true? The model can only pick from what it is shown.
If all three answers are yes, one decision is still not much use on its own. Something has to hold the state, work out the options, ask, judge the answer and know when to stop. That is a System One agent.
Sourcing
What the Jev numbers actually say
Four figures get quoted constantly. We opened the original repository for each one. All four had drifted, and all four drifted the same way: toward sounding better.
| The figure as usually quoted | What the source actually says |
|---|---|
| A browser agent books a flight in 7 seconds | Nothing was booked. The task was a flight search, and the goal written into the repository tells the agent to stop once matching flights are on screen. The seven seconds is real: Browser Use reports 7.073 seconds at normal speed, counting text generation, model requests, browser work and page loading. Browser startup, the first page load and a separate check of the result sit outside that clock. The run used 17 decision-model requests, median 178 milliseconds each, plus two calls to a small text model |
| That same run cost $0.0039 | Not a number the author reports. What is published is $0.00006272, and it covers only the two text-generation calls. The repository says plainly that this is the cost of those two calls, not the cost of the task: the decision-model responses come back with token counts but no dollar figure, and browser costs are left out entirely |
| Routing with a decision model measured a 60 percent cost saving | The author says that is not what it means. Nothing was saved and nothing was spent: the repository replayed 237 past turns and re-priced them, using a routing policy it has since replaced. It states that this is not money actually saved, and not evidence for how the tool routes today. The limitations section adds that token counts were held fixed, and that switching model mid-thread throws away the prompt cache, which the replay never accounted for. Real savings could be lower |
| An agent supervisor holds the right call 88 percent of the time | That number is not in the project. Its README publishes something closer to the opposite. The supervisor stopped 3 calls in every 1,000: 48 holds across 18,075 guarded calls over 315 sessions. And of the 13 holds it went back and checked by hand, only 2 turned out to be right. The other 11 went through on a retry. The full replay is published next to those numbers |
The authors were careful. The drift happened afterwards, in other people's summaries. So before you plan around any number in this space, open the repository it came from and read what was measured.
These are their measurements, not ours. We ran none of them.
FAQ
Common questions
What can Jev do?
Jev picks an answer from a list you supply, and tells you how sure it is. It writes nothing. The three most common uses are judging an agent's tool calls before they run, trimming a long conversation down to what still matters, and routing a request to the right model. It is also used to choose the next click in a live interface, to score drafts against criteria you name, and as a semantic condition inside SQL or a shell. What it cannot do is write, explain, summarise or code.
What is Jev used for most often?
Supervising an agent's tool calls, trimming context, and routing between models. All three run on every step of a loop. All three have an answer that is one of a few fixed options. And all three were impractical before, because asking a language model the same small question hundreds of times cost too much and took too long.
Can a System One model do classification?
Classification is its most direct use. Two things differ from a trained classifier. You write the label set with each request instead of training it in, so changing the labels costs nothing. And you can ask several questions about the same state in one call. The trade is that if you already have labelled data, an ordinary baseline may still beat it on a narrow task. Measure before you assume.
Can it read images or audio?
Jev accepts text only. Projects that appear to act on screens or speech convert first, with optical character recognition or transcription, and send the resulting text as the state. That conversion step is part of your system rather than the model's, so its accuracy and its latency are yours to measure.
Is a System One model accurate enough to act on without review?
That is what the probability is for, and it is a decision you make per action rather than once. The usual pattern is a threshold that scales with what the action costs if it is wrong: low for reading something, high for anything that cannot be undone. Below the bar the step runs nothing and is recorded, which turns an uncertain moment into a handover instead of a mistake.
Put a harness behind your product
Run complete agent harnesses through one contract for tasks, sessions, streaming and artifacts, and keep the harness a request parameter rather than an architectural commitment.
Start building free