Jev AI: Small Decisions, Bigger Possibilities

A lot of useful software comes down to small judgments. Which team should handle this message? Is this paragraph relevant? Which action should happen next? What caught my attention about Jev was the possibility of making those judgments quickly and cheaply enough to use throughout an application.

Here’s how Jev works, where its speed and pricing become useful, and what developers are building with it. Sources and project details are current as of September 21, 2026.

Jev is TypeSafe AI’s first public System One model. You give it context, called state, and questions with defined answer types. It returns structured judgments that your code can use directly. It doesn’t write a response explaining its answer.

There are three primitives. Choice selects from options you supply. Score evaluates the input against a rubric. Noul estimates the probability that a statement is true, from zero to one. Choice and Score also return a probability distribution and a confidence value.

For an illustrative support workflow, Choice could select billing, technical support, or sales. Score could assess urgency. Noul could judge whether the customer is asking to cancel. Your code would combine those results into an action.

TypeSafe recommends asking narrow questions and combining the answers in code. Multiple independent questions can run in parallel against the same state. That makes the interface useful for adding judgment to an existing workflow without asking a model to invent the whole process.

A general-purpose LLM can write an email, explain a result, generate code, or work through a multi-step problem. Jev focuses on bounded judgments that an application can consume immediately. In a support system, Jev could select a queue and assess urgency while an LLM drafts the reply.

LLMs can also classify inputs and produce schema-constrained output. OpenAI’s Structured Outputs, for example, supports JSON Schema adherence. Jev’s distinction is its specialized decision interface, parallel evaluation, and returned probabilities—not exclusive ownership of structured answers. Neither a valid schema nor a confident prediction guarantees that the underlying judgment is correct.

TypeSafe introduced Jev on September 15, 2026. Its launch announcement reports response times of 70–500 milliseconds and pricing of $0.042 per million input tokens, with free outputs.

At that input rate, 1,000 calls using 1,000 billed input tokens each would cost $0.042 in model input charges. That is arithmetic, not a quote for a complete application: repeated context, other models, transcription, hosting, and retries can add costs.

My interest is what happens when a judgment becomes inexpensive enough to repeat. A document list could be re-ranked as the user changes their question. A queue could be classified as items arrive. Whether those ideas work well still depends on accuracy and the full application’s response time.

TypeSafe’s Doom demo connects Jev to structured game state, rather than images. Wikiracing asks it to select links toward a destination Wikipedia page. Both make the same idea visible: choose an action from a bounded set, execute it, then evaluate the updated state.

The company notes that a conventional Doom bot could play better. I read these as demonstrations of an interface for repeated decisions, not proof that Jev is a superior game-playing system.

Hassan (@nutlope) shared a pipeline that first summarized papers with DeepSeek V4 Flash, then asked Jev to choose among 24 topics using each paper’s title and summary. He reported $0.08 for the classification stage and 256 milliseconds median end-to-end latency per paper.

The summaries cost another $3.99. That distinction matters: the eight-cent figure was one stage of the workflow, not the entire project. His post also said the Jev classifications were still being evaluated before replacing the existing ones on 1kpapers.

This is the example I find easiest to translate into everyday software: use a generative model where you need new text, and a decision model where you need a label.

Tony Dinh’s open-source Sponsor Skip project uses Jev to identify sponsor reads. The application owns the timestamps; Jev selects transcript lines or makes judgments about transcribed speech. The extension then handles the skip.

Its README separates transcript-only, Smart, and Listen modes. The audio modes use Deepgram for speech-to-text, so their costs differ from transcript-only classification. This is a useful reminder that a demo described as listening to video can contain several distinct systems.

The repository documents limitations, including unreliable transcript availability and possible overshooting in Listen mode. It is an inspectable prototype, not evidence that every sponsor segment will be detected correctly.

RomanSlack’s jev-drone project puts Jev inside a MuJoCo simulation. Computer vision converts camera information into a symbolic scene. Jev proposes tactical choices such as changing direction or climbing, while ordinary code handles flight control and can override those suggestions.

The repository describes an approximately 2.5 Hz judgment loop and explicitly says Jev is not the vision or flight-control layer. It also reports substantial run-to-run variation and limits what its successful obstacle-course run demonstrates.

What makes this example useful to me is the division of responsibility. The model contributes a small judgment inside a much larger engineered system. It is a simulation, not a demonstrated deployment on a physical drone.

Greg Isenberg’s “Jev is HERE. How to use it” features Ryan Vogel and an email-sorting demonstration. The episode description reports sorting 1,700 emails for 18 cents and discusses lead scoring, support routing, video clipping, and browser control. Treat those figures as the presenters’ report, not a general price or accuracy guarantee.

For another perspective, Sam Witteveen’s “Jev - The Ultimate Classification Model?” is linked below. Start with the email example if you want an intuitive picture of the sort of task Jev is designed to handle.

TypeSafe’s documentation explains that confidence for Choice and Score is calculated from the returned probability distribution. It is a convenient summary of how concentrated that distribution is. Noul does not have a separate confidence field.

That gives an application a way to handle uncertainty: accept some judgments, collect more information for others, and send difficult cases to a human or another system. The documentation recommends choosing thresholds for the domain and validating them on your own data.

I would not read a confidence value of 0.95 as a promise of 95% accuracy on my application. The useful question is whether the signal separates reliable answers from unreliable ones on the task I actually need to automate.

TypeSafe’s schema guarantee concerns the shape of the output. A valid choice can still be the wrong choice. Its launch post also acknowledges that its headline speed and cost multipliers are toward the high end of expected real-world gains.

A useful evaluation starts with a narrow classification task and examples with known answers. Compare Jev with simple rules and an existing model, then measure incorrect decisions, uncertain cases, total cost, and latency from the location where the application runs.

Speed and price are what drew me in. The more interesting possibility is being able to add a useful judgment wherever an application needs one, while keeping the surrounding logic understandable. The showcases point toward applications that combine fast judgments, generative models, and ordinary code, each doing the part it handles best.