The AI model that doesn’t talk
About a week ago, I got a DM that basically said, “Hey, have you been following this?”
It linked to TypeSafe’s announcement of Jev, the company’s first “System One” model.
Jev takes some text or JSON and answers narrow questions about it. The answer can be yes or no, one choice from a list, or a score on a scale. It returns a probability instead of generating an explanation.
That makes it useful in a different part of the system. An LLM can write, analyze, and reason through a complicated problem. Jev can make the smaller decisions before, during, and after that work.
What people are doing with Jev
I used Claude and a few other tools to work through the early research, writeups, and open-source projects.
A community directory collected 358 source-checked projects in Jev’s first five days. People were using it to choose a browser’s next action, decide which coding-agent context to retain, select interface components, review pull requests, and gate agent tool calls.
The recurring pattern was to use Jev inside a loop. A larger model produces something. Jev decides whether it is relevant, risky, complete, or worth escalating, then code executes the next step.
Three stood out:
- In a phishing-detection study, asking one broad question produced 62.6% accuracy. Splitting the same judgment into five narrower questions and combining the answers in code raised it to 95.0%.
- A synthetic log-alerting experiment found something similar. Asking Jev to choose among page, ticket, or ignore missed all 57 database-lag incidents. Asking whether the log should page an engineer, then applying a threshold in code, caught all 57.
- Langfuse reported that Jev matched Claude Fable 5.1’s grading verdict 91.5% of the time, at an estimated $160 instead of $33,000 per million graded answers.
These are launch-week experiments, community reports, and vendor evaluations. They indicate where Jev might fit, rather than showing mature production adoption.
My first test
I already had an LLM-based tool that scores résumés against a Director or VP of Product rubric. I turned each rubric category into a Jev Score question and ran my résumé through it three times.
Jev agreed with the original tool about the weakest area and correctly ignored unfinished placeholders when instructed to do so. Its least confident response also landed on an ambiguous category, splitting its probability almost evenly between two levels.
The overall score was much higher, about 83 compared with the LLM tool’s 65. The difference came from my questions. That was probably the most useful finding. With Jev, the wording of the options is the model’s whole world.
The opportunity in payments
Of the 358 projects in the community directory, almost none involved payments. I found a few early demonstrations for fraud scoring, pre-settlement transaction review, and invoice booking, but no evidence yet of production or bank adoption.
The gap caught my attention because payments systems contain many small judgments around otherwise exact processes.
Code should continue to handle amounts, dates, accounts, balances, and money movement. The less exact work sits around those mechanics: deciding which exception needs review, whether a remittance description matches an obligation, whether an alert describes meaningful risk, or whether a repair looks safe to automate.
I designed a second experiment around eight payments-engineering standards, including timeouts, stable idempotency keys, card data in logs, swallowed errors, and floating-point money. Each standard becomes a separate question with four possible answers: violates, complies, not applicable, or cannot tell from the diff.
The test also includes a deliberately reassuring pull-request description to see whether Jev follows the claim or judges the code. I’ll share what I find later.
What interests me is the change in how the system is designed. The work moves away from asking one model for a complete answer. Instead, you define the narrow judgments, encode your policy in Jev’s questions and answer options, and let it evaluate each one quickly and cheaply.
For now, Jev looks like a way to make parts of current LLM workflows cheaper. For certain decisions, it offers a useful middle ground between calling a frontier model and writing a pile of clunky Python.