How to use the Jev decision model — Part 10

The Jev decision model is a small, fast model from TypeSafe AI that answers multiple-choice, yes-or-no, and scoring questions in JSON instead of generating free-form text. According to the video review by Code to the Moon, it responds in 70 to 500 milliseconds, which makes it suitable for real-time decisions where frontier language models are too slow.

Part 10 of a series. Start with How to Use the JEV AI Decision Model for Trading, then How to Use the JEV AI Model in Production.

What is the Jev decision model?

The Jev decision model is a small inference model from TypeSafe AI that answers structured questions instead of generating free-form text. This article is based on the Code to the Moon video published in October 2026, and every product claim below comes from that review rather than from independent testing. Where a figure could not be verified against a primary source, it is attributed to the video.

Jev is often described as a System One model, a term borrowed from the dual-process psychology made popular by Daniel Kahneman's book Thinking, Fast and Slow. System One is fast, automatic, and pattern-driven; System Two is slow and deliberative. Jev occupies the System One slot: it makes quick classification decisions, while frontier language models such as those from Anthropic and OpenAI play the slower, more capable System Two role.

Structurally, the difference is simple. You send Jev a JSON object containing one or more questions, an optional instructions field with free-form text, and an optional state field with context. Jev returns JSON answers with probability and confidence values. It understands free-form input but never produces it, which is a large part of why it is fast and cheap.

How fast and cheap is Jev compared with frontier models?

According to the Code to the Moon review, Jev typically responds between 70 and 500 milliseconds, which the presenter calls orders of magnitude faster than frontier language models. Input tokens are reported at 4.2 cents per million, and output tokens are reported as free. These are vendor-reported figures relayed through the video, not measurements from this article.

For contrast, the video cites Claude 5.5 at $4 per million input tokens and $20 per million output tokens. Even if Jev's exact pricing shifts, the structural point holds: a model that returns a single structured field instead of generated text has far less output work to do, so per-decision cost stays low.

Latency, not price, is the more interesting constraint. At sub-second response times, Jev can sit inside a tight loop such as a game tick or a live routing decision. A frontier model can answer the same question correctly, but a 2026-era frontier response time of several seconds makes real-time use impractical.

What are the three question types Jev supports?

Jev supports exactly three question types, and each maps to a common decision pattern in application code. Multiple questions of any mix can be combined in a single request, and all questions in one request share the same state field.

The mechanics matter for designing requests, so here is the breakdown as demonstrated in the video:

• choice — a multiple-choice question. The possible answers are JSON field names, and the model weighs the names themselves. In the video's example, fields named for planets returned Earth at 100% probability. Field names can also be generic, with free-form criteria strings in the values, such as an elsewhere option defined as "anywhere outside the solar system".

• yn — a yes-or-no question. With a state field asserting that humanity had moved to Mars, asking whether at least one human was on Mars returned a confident yes.

• score — a rating on a linear continuum. Criteria strings sit at indexed positions on a spectrum, and the model returns a number for its position. Scoring planets for breathable atmosphere, Earth scored two out of two, Mars slightly under one, Venus near the bottom, and "Inside the Sun" a straight zero.

Two behaviors are worth noting from the demonstrations. Adding hedging language to the instructions, changing "exists" to "could exist", raised the probability of the losing options and lowered overall confidence. And the state field accepts arbitrary free-form context, so internal documents or scenario descriptions can shift the answer without retraining anything.

Which Rust SDKs exist for Jev?

Because Jev's input and output are plain JSON, community bindings appeared quickly, and the Rust ecosystem produced two unofficial SDKs highlighted in the video. The presenter describes a typesafe Rust SDK with a builder-pattern API and Jevkit, which uses procedural macros.

Both projects looked reasonable to the reviewer, who had not tried either and chose to let the ecosystem settle first. That caution is sensible advice for any framework that is days or weeks old: unofficial bindings can lag API changes, and there is no guarantee either crate tracks the current request schema.

If you are starting a Rust project against Jev today, treat the SDK choice as low-risk but reversible. The wire format is JSON, so migrating between crates, or dropping to raw HTTP, is a small cost.

Why is the Mario demo a big deal?

The best-known Jev demo is Typesafe Mario, in which the model plays the original Super Mario Bros. from the NES. Jev does not see pixels. It receives the game state from memory and returns action decisions such as left, right, or jump.

The reviewer's argument for why this matters is worth restating. Game-playing AI of the past decade was typically trained per game with reinforcement learning: an action set, a score to optimize, and millions of playthroughs adjusting network weights. The AlphaGo documentary from 2017 captured that era's approach. Jev, by contrast, has never trained on Mario. It controls the character purely from semantic knowledge of what Mario is and how platformers work, which the reviewer compares to a human sitting down at a game after having the rules explained in natural language.

The claim deserves its scope limits. The reviewer himself suspects traditional reinforcement learning would still produce a better Mario player if you can afford to train one. The novelty is generalization plus speed: frontier language models plausibly have the same semantic understanding, but they are not fast enough to make real-time decisions. Jev's narrow output format is what closes that gap. That is one demo, not proof that decision models beat game-specific training across the board.

When should you use Jev in production?

The video proposes three use cases where a fast, structured decision model is a clear fit. Each one is a classification or routing problem where the answer space is small and the context is text.

The suggested fits, in ascending order of confidence:

1. Support routing — send an inbound customer request to the correct team based on its content. The reviewer notes this is essentially the example in the Jev documentation, so the vendor designs for it.

2. Note capture — in a note-taking app, automatically place a quickly captured thought into the right spot in the user's existing organizational structure. This is a single choice question over the user's notebook tree.

3. Customer question answering — answer questions whose response is likely yes or no, and route to a frontier model when the reported confidence is low. The confidence field makes this fallback pattern trivial to implement.

The common thread: Jev works when you can phrase the decision as one of its three question types and you can afford occasional errors caught by a confidence check.

When should you not use Jev?

The reviewer is skeptical of one popular application: controlling game characters. His reasoning is that if you can train a specialized model, traditional reinforcement learning will likely produce a better player, and he invites counterarguments. The Mario demo is a generalization showcase, not evidence that decision models beat game-specific agents.

A second limit follows from the architecture. Jev cannot explain itself, draft text, or handle open-ended questions. Any workflow that needs generated prose, multi-step reasoning, or negotiation of ambiguous requirements still needs a frontier model. The realistic pattern in 2026 is a two-tier design: Jev handles the cheap, fast, structured decisions and escalates low-confidence or high-stakes cases to a larger model.

Finally, every performance and pricing number in this article traces to a single seven-minute video review plus vendor claims. Before betting a production path on Jev, run your own latency and accuracy evaluation on your actual decision workload. Readers experimenting with AI tooling right now, from the Code to the Moon audience to creators such as Dev Doido do canal do youtube, are all working from the same early, thin evidence base.

FAQ: quick answers about the Jev decision model

• What is the Jev decision model? It is a small, fast inference model from TypeSafe AI that answers structured JSON questions rather than generating text. It supports three question types: choice, yn (yes-or-no), and score, and accepts free-form context in its state field.

• How much does Jev cost? Per the Code to the Moon review published in October 2026, input tokens cost 4.2 cents per million and output tokens are free. These are vendor-reported figures and should be confirmed against current official pricing before budgeting.

• How fast does Jev respond? The video reports typical responses between 70 and 500 milliseconds. That latency range is what enables real-time uses such as controlling a game character, which slower frontier models cannot do practically.

• Can Jev replace a language model? No. Jev answers structured questions only and generates no text. The recommended pattern is using Jev for fast classification and routing, with a frontier model such as Claude or GPT handling anything that needs generated language or deep reasoning.

• Is there an official Rust SDK for Jev? The SDKs featured in the video, a typesafe builder-pattern SDK and Jevkit with procedural macros, are both unofficial community crates. The reviewer had not tested either and advised letting the young ecosystem settle.

From video explanations to written guides

The core insight of this piece is that Jev wins by narrowing its job to structured decisions, and the same discipline applies to content. A seven-minute video like this one contains a complete mental model, three question types, and a use-case framework, but most of that value stays locked inside the recording unless someone writes it out.

If you publish technical walkthroughs, interviews, or opinions on YouTube and want them readable and searchable as articles, Skala Blog turns a video URL into a transcription and then into a structured draft article you can review and edit before publishing. Paste the link, get the article, keep the substance.

Source video