TypeSafe released Jev on September 15th, 2026 and called it a System One model. A System One model is a specialized type of AI designed to make fast, deterministic judgments and structured classifications in a single parallel pass rather than generating conversational text.
You don't chat with it. You send it some state plus a list of narrow questions, and it sends back probabilities.
What I really like about it is it's cost. It's $42 per billion input tokens, and output tokens free. In my testing I was seeing answers in 70 to 500 milliseconds.
Here is what I built with it!
What a request actually looks like
This is the interface. It has a POST, a state object, and a map of questions:
const response = await $fetch('https://openrouter.ai/api/alpha/decisions', {
method: 'POST',
headers: {
Authorization: `Bearer ${config.openRouterApiKey}`,
'Content-Type': 'application/json',
},
body: {
model: '~typesafe/jev-latest',
state: buildGateState(stack, pullRequest),
questions: {
matches_request: {
type: 'noul',
instructions: 'Does the pull request directly address the stated issue and acceptance criteria?',
},
protects_credentials: {
type: 'noul',
instructions: 'Does the changed frontend code keep credentials and secret tokens out of browser-visible runtime configuration?',
},
},
},
})
What comes back is shaped like the questions you asked:
{
"model": "~typesafe/jev-latest",
"answers": {
"matches_request": { "type": "noul", "noul": 0.59 },
"protects_credentials": { "type": "noul", "noul": 0.11 }
},
"usage": { "input_tokens": 4211, "output_tokens": 0, "cost": 0.00067 }
}
Every answer is a number between 0 and 1. If you ask six questions, you get six probabilities, and you can then decide what to do with them.
Three question types
Jev has three primitives.
A noul is a yes-or-no probability. It doesn't have any other criteria, just questions.
A choice picks one category from a set you define. Its criteria are an object, because the categories are unordered:
traffic_shape: {
type: 'choice',
instructions: 'Using only the described usage pattern, choose how this workload receives traffic over a typical month.',
criteria: {
steady_24_7: 'Traffic arrives continuously at a roughly similar rate at all hours.',
business_hours: 'Traffic happens during working hours on weekdays and falls to almost nothing outside them.',
spiky_bursty: 'Traffic is uneven and unpredictable, with quiet periods followed by much heavier bursts.',
batch_scheduled: 'Work runs on a schedule as discrete jobs rather than as a stream of user requests.',
},
}
A score is an ordered rubric, so its criteria are an array instead. The API enforces that distinction.
App one: gating a pull request
The first app loads a pull request and asks six questions about it at once. In my case I asked: Does the diff match the stated issue? Does it keep credentials out of browser-visible config? Does it implement the failure states the acceptance criteria asked for? Is the changed interactive UI keyboard operable? Is the layer safe to review on its own given its dependencies?
All six run in the same request, and it's super fast!
Then my code, not the model, turns those probabilities into a verdict:
| Probability | Result | Meaning |
|---|---|---|
| 80 to 100% | Pass | Enough support to continue through normal review |
| 55 to 79% | Review | A person should verify the uncertain evidence |
| Below 55% | Block | Do not merge this layer yet |
In my scenario I used keyboard_accessible to only count if changes_interactive_ui came back above 0.5. A backend-only PR shouldn't get dinged for missing keyboard behavior, and that conditional lives in my code where I can read it and change it.
OpenRouter versus calling TypeSafe directly
I started on OpenRouter because I was still on the TypeSafe waitlist. I noticed that OpenRouter was quite a bit slower.
- Through OpenRouter: 683 ms, cost $0.00067
- Straight to TypeSafe: 318 ms
Roughly half the time for the same work. If you're going to build on this, get on the waitlist and use their API. I got in the next day.
App two: AWS workload
For the second app you describe an AWS workload, something like "public checkout API for retail storefronts," and it gives you back a cost estimate.
Here is what it does:
| Layer | Owns | Never does |
|---|---|---|
| Jev | Semantic judgment about the prose description | See a number, emit a number, compare two numbers |
| My code | Sizing, platform limits, thresholds, ranking | Guess at intent |
| AWS Price List | Every unit rate | Nothing, it is just data |
Jev answers questions like whether the described data access needs relational queries across multiple tables, whether any single unit of work runs longer than fifteen minutes, and whether the description implies a bounded population or open-ended public demand. Then the Agent Toolkit for AWS and the AWS pricing MCP server produces the dollar figure.
Once the model has classified the output, the arithmetic is deterministic.
Schema validity
Schema validity is not correctness. Jev cannot return an answer outside the questions and criteria you defined, so you'll never parse a broken response. Although, it can return a confidently wrong probability that validates perfectly.
That's why both apps put a threshold in front of any consequence. Low confidence routes to a person or to a stronger model. If you wire probabilities straight into an irreversible action, the guaranteed output shape will not save you.
TypeSafe publishes guidance on confidence, but you need to measure it against your own labeled data and set thresholds based on what a mistake costs you.
What other people are doing with it
The community projects are where the speed becomes obvious. Someone has Jev playing Super Mario Brothers by asking "should I jump here" over and over while the game runs. Somebody else built a real time outfit picker that updates suggestions as you change the inputs.
The possibilities are endless.
Would I use it
Frontier models aren't going anywhere, and this doesn't compete with them. Nothing here writes code, explains a decision, or produces a plan.
However, I have a decent number of workflows that need a lot of small semantic decisions with deterministic code waiting on the other side. Routing, classification, gating, cheap verification before an expensive step. For those, sending narrow questions and getting probabilities back is a better fit than asking a chat model for JSON and hoping.
Try it on something you already have labels for, measure the calibration yourself, and keep anything expensive behind a threshold.
Top comments (1)
Are you using Jev?