Understanding Jev: a System-One tool for data engineers

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

Article: What Jev is, and why it turns a judgment into a single function call

Suppose you have 50 million product reviews and need to label each one for sentiment and check it for policy violations. Running a frontier LLM over all of them could easily cost five figures in API fees, and you might wait days for the batch to finish. Every review only needs a short verdict, yet you pay for a model that writes out a full response each time.

Jev is built for exactly this kind of work. It is a model from TypeSafe AI, officially released in September 2026. The company's founder, Diogo Almeida, is a former OpenAI researcher who worked on the instruction-following research that ChatGPT was built on. TypeSafe AI calls Jev the first public "System One Model": it doesn't write prose or code, it only answers the questions you give it with probabilities. According to the company, those 50 million reviews would take about $20 and a few hours with Jev.

This article is the written version of the video. It walks through what Jev takes in and gives back, why it can be fast and cheap, what its training goal of "calibration" means, and how a data engineer might use it in a pipeline. It ends with the limits, the most important being that nearly all of the numbers so far come from the vendor.

Why structured decisions are painful with an LLM

An LLM generates text one token at a time. Even a simple yes-or-no decision means producing a complete reply token by token. The video puts typical latency at 3 to 30 seconds per call, and more when the output schema (the format you require the answer to follow) is complex. That doesn't hold up for batch jobs in the millions.

The generated text then has to be parsed as JSON and validated. Broken formatting, extra fields and hallucinated content all need extra code to catch. Cost is the other problem: both input and output are billed per token, so a job of millions of items produces an alarming bill.

The terms System One and System Two come from Daniel Kahneman's Thinking, Fast and Slow. System One is fast, intuitive judgment; System Two is slow, deliberate reasoning. In those terms, we have been using a slow System Two engine to make fast System One calls.

State in, three kinds of probabilistic answers out

Jev's input isn't a chat message but a piece of unstructured "program state", either text or structured data. Its output isn't free text. There are only three fixed primitives, and each comes with a calibrated probability.

The first is Choice, which picks one option from a list of up to 255 that you declare in advance and returns a probability for each. The second is Score, which places the input on an ordered scale, such as calm, annoyed, very angry. The third is Noul, a yes-or-no decision that returns a probability between 0 and 1.

Take a customer support message. You pass the message in as the state and ask three questions at once: which team should handle it (Choice), whether it's urgent (Noul), and how frustrated the customer is (Score). The founder describes Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out. You can also think of it as an if statement powered by AI.

One forward pass: why it's fast and can't break format

The key to Jev's speed and price is that it answers in a single forward pass, one run of the network from input to output. A conventional LLM decodes autoregressively, one token after another, so longer outputs take longer. Jev instead enumerates every candidate answer in the output space before inference, scores all of them at once in one forward pass, and returns the most probable one.

Because there's no token-by-token generation, the output can't be malformed and can't contain anything outside the schema. The vendor reports latency of 70 to 500 milliseconds, which it says is 40 to 200 times faster than frontier LLMs, but none of this has been independently verified. The underlying architecture hasn't been disclosed either, and outside guesses remain unconfirmed.

RLCD: making stated confidence match real accuracy

Speed only matters if the answers are good. Jev is trained with a method called RLCD, Reinforcement Learning for Calibrated Decisions. It differs from RLHF, which optimizes for human preferences, and from RLVR, which targets problems with a single answer that can be checked automatically.

RLCD aims for calibration: the confidence the model states should match how often it's actually right. Weather forecasts are a good analogy. If you collect all the days a forecast said "70% chance of rain", it should in fact have rained on roughly 70% of them.

If confidence is trustworthy, you can use it directly as a threshold. Handle high-confidence cases automatically, and escalate anything below a cutoff to a human or a more expensive LLM.

Where it fits in a data pipeline

The most direct use is map-style batch labeling: classifying, scoring and routing millions of reviews or support tickets. In RAG (retrieval-augmented generation, where retrieved documents are fed to an LLM), Jev can score retrieved passages for relevance and decide which ones go into the LLM's context. It can also act as a guardrail on LLM output, using Noul to check quickly whether generated content is compliant or hallucinated.

The standout pattern is threshold routing. Cases above 0.9 confidence are processed automatically, and the rest go to a person or a stronger LLM. The expensive compute is then spent only on the minority of cases that are genuinely hard.

On price, the vendor lists input at $0.042 per million tokens, about 4 cents, and output is free because there is no token generation step to bill. That is where the $20 estimate for 50 million reviews comes from. Integration is light: with the official SDK, a call takes three lines of code. Jev is currently in early access, opening up gradually from a waitlist.

Limits: a well-formed answer isn't necessarily a correct one

Type safety doesn't mean the judgment is right. Jev never produces a malformed answer, but it can pick the wrong option inside the schema. It also gives no natural-language reasons, which is a serious gap wherever explainability or regulatory audits are required.

The benchmark numbers need care too. All of them are self-reported, with no independent third-party verification, so any citation should say so. In the vendor's internal evaluation across four workflows, the reference answers weren't independent ground truth but the average of two LLMs, GPT-6 Astra and Fable 5.1. The results were:

Read plainly, the table shows Jev's advantage is speed and cost. Its accuracy matches LLMs in the same tier and trails the stronger models by several points, so it isn't remarkable on that axis. Whether the price will last is also an open question; the vendor itself admits the current very low pricing may be subsidized. Calibration also depends on the data distribution you deploy on, and when several decisions are chained in a pipeline, their errors don't cancel out on their own.

So before going to production, build a golden dataset (examples whose correct answers a person has checked) and measure accuracy, miss rate and calibration. Don't trust any model blindly.

Takeaways

Jev isn't meant to replace LLMs; the two solve problems at different layers. Generating text, writing code and complex reasoning are System Two territory and remain the LLM's job. Jev turns judgment into a cheap, fast, type-safe function call, which is the System One role.

The name comes from the economist William Stanley Jevons. The Jevons paradox says that when a resource is used more efficiently, total consumption tends to rise rather than fall. Once judgment is cheap enough, you start adding decision logic at every step of a pipeline, and that is the direction data engineering is heading.

To repeat the main caveat: the speed, price and accuracy figures here all come from the vendor's own materials and still await independent checks. The sensible first step is to try Jev on a classification task off the critical path, verify its calibration against a golden dataset, and only then decide whether to scale up. The official announcement is TypeSafe AI's launch post.

Narration is in Chinese (a clone of my own voice); a Japanese version is on the /ja/ page. Visuals are illustrative.