Jev is a new, ultra-fast, ultra-cheap “System one“ model from Diogo Almeida and his team at TypeSafe. Response times range from 70-500 milliseconds. One million input tokens cost $0.042 and output tokens are free. Almeida was previously at OpenAI, where he was a co-author on the InstructGPT paper.
Jev is a new way to apply AI and a new primitive to build with.
It’s totally different from working with LLMs or chat-based models, in that you don’t chat with it. You give it a decision to make, and it produces a probability over a set of options, predicting which option has the highest probability of being correct.
I spoke to an AI engineer friend. He clearly saw the potential of Jev, but he told me that he’s having a hard time wrapping his head around what it actually is, how it works, and what you can do with this new primitive.
Jev shines inside a program where it can make bounded judgments. You supply the context and possible outcomes, while code and LLMs handle the surrounding work. Your challenge as an engineer is deciding which judgments Jev should make.
What Jev is
Working with Jev starts with two things: the information it needs to evaluate, and the questions you want answered. TypeSafe calls that information the “state.” It might be a customer’s email, a document, or a description of what’s happening inside an application.
Your inputs are: the state, and a question about that state.
You define each question using one of three types. Choice selects from a list of options you provide. Score rates something against a rubric. Noul returns a probability that a statement is true, or TypeSafe’s version of a boolean.
For example, you could give Jev a support ticket and ask which team should handle it, how urgent it is, and whether the customer is requesting a refund. You ask three separate questions about the same state, and Jev attempts to answer them for you.
Your outputs are: structured values and probabilities your software can use. Jev doesn’t generate a written explanation. You decide what happens with the structured output: route the ticket, flag it for review, or pass it to an LLM that writes a response.
According to TypeSafe, Jev evaluates the questions independently and in parallel, rather than generating its answers token by token. If one decision depends on another, the surrounding code needs to handle that dependency.
TypeSafe calls their approach to training Jev Reinforcement Learning for Calibrated Decisions, or RLCD. The goal is for the probabilities to reflect how often an outcome actually occurs: across many predictions assigned an 80% probability, roughly 80% should turn out to be true. That describes calibration across predictions, not a guarantee that any individual answer is correct.
TypeSafe bets that “AI automation will be closer to 99% machine-to-machine interaction and 1% human interaction.” What that means to me is that Jev is an AI model built first to be used by computers, within programs, and us humans only need to get involved with the last mile. We are the beneficiaries of the output of Jev.
Isn’t Jev just a classifier?
One reaction to Jev’s launch was: haven’t we had classifiers for years? We have. Choosing a category or assigning a score is by no-means a new task in machine learning. Calling Jev a new primitive doesn’t, by itself, explain why this new model resonates.
The reason it resonates is the work it bakes into training for you. One commentator on X, Matija Sosic, made the point that Jev accepts unstructured text and doesn’t require users to train a classifier for each use case. He said it’s combining the best of both worlds from classifiers and LLMs. Ian Butler made a related point: he wanted something he could drop into an application, without first having to train it himself.
Yes, Jev is a classifier, but it’s not “just” a classifier. With Jev, you describe the judgment you need and define the possible outcomes. There is still work involved: choosing the right context or “state”, writing clear criteria, testing the predictions, and deciding what your software should do with them. But that starting point is further down the road than starting by building a task-specific classifier.
As a builder, all I want to know is: does Jev make it easier to build useful products faster, at a lower cost? Even if it’s not a completely new paradigm, losing myself in a philosophical debate is beside the point.
You could call the internal combustion engine “just another engine.” We already had steam engines. That’s true at the level of categories, but it misses the more interesting question: what does the new engine make possible? That’s the question I want to ask about Jev.
Jev and LLMs: both/and
It’s human nature to jump to a binary conclusion: Jev or an LLM? It’s wise to resist that temptation. As AI engineers, the question is how we compose the primitives we have access to into something that solves a problem that is valuable to yourself and others.
Thinking in terms of either/or can narrow our choices before we’ve even understood our goal and vision for building. We have a growing set of tools at our disposal, and choosing one doesn’t mean we have to give up the others.
That’s how I think about Jev: as another primitive to work with. The wiser question is where it fits in the system we’re building, and how it can work alongside existing models and tools to make the whole system better.
Gregor Zunic’s browser-agent demo is one great example. In his description, the agent gives Jev the browser’s DOM state and a new set of possible actions at each step, with a small LLM fallback for typing. The models have different jobs within the same workflow. Jev handles the constrained choices, while the LLM supplies text when needed.
Simplified workflow based on Gregor’s linked implementation.
Gregor reports that his flight-finding demo took seven seconds and cost $0.0039. What I love about this example is that it shows how you can use Jev classifiers in partnership with LLMs.
I ran a small experiment of my own along these lines: Jev playing Pac-Man, steered by Astra. Astra, the larger reasoning model, writes a strategy for Pac-Man to follow. Jev reads the game state directly from the browser and chooses each move in milliseconds, based on that strategy. As the game plays out, Astra takes feedback from the game and updates the strategy in real time, and Jev keeps executing the latest version.
One reply described it as Astra being the brain and Jev being the body, and that’s pretty much exactly it. Where Gregor’s agent calls on an LLM for the text Jev can’t produce, here the LLM sits above Jev doing the slow thinking while Jev does the fast acting. The whole thing took about 20 minutes to build in Codex.
Where Jev fits in your workflow
Jev fits when you have a bounded set of potential decisions, like the four directions Pac-Man can move in my experiment above. You can enumerate the allowable actions or judgments, provide the relevant context, and make a decision without long chains of thought. The bounded set defines the interface to the problem; it does not mean that the right choice is guaranteed. It’s still a probabilistic model with a pre-determined set of outputs.
An apt analogy is choosing a move from a playbook rather than inventing a play in the middle of the game. The possible moves are already available. Jev’s job is to identify which one fits the situation, quickly and cheaply, so the surrounding system can act on it.
You are trading possibilities and open-endedness for fast, efficient execution. Constraining the answer space gives you speed, repeatability, and testability where an open-ended LLM does not. That is why Jev works inside a designed workflow rather than as an open-ended thinker. Jev is a focused cognitive executor. It attempts to select the likely correct decision based on the state surrounding it, which your program can then execute.
Some of the most impressive Jev demonstrations I’ve seen are browser-use demos: the model operates a web app at high speed. You would not necessarily use Jev to create a new web app. But once the app exists and you know what you are trying to accomplish within it, Jev can help operate it by choosing among the actions that are available. That makes browsers use a compelling illustration of where Jev fits.
Tradeoffs and limits
A constrained set of answers doesn’t make every decision a good fit for Jev. TypeSafe is explicit about this in its documentation of Jev 1.13’s limitations. The model can take instructions literally and miss the intended meaning. It struggles with counting, arithmetic, date comparisons, and questions that require several steps of reasoning.
The context you supply matters, too. Irrelevant detail can reduce accuracy, and adversarial instructions embedded in that context can influence its answers. Defining the possible outputs doesn’t guarantee that Jev will make the correct choice.
These limitations point to the importance of the surrounding workflow for Jev. Keep exact calculations in code, supply the information the decision needs, and decompose complicated judgments into smaller questions. Where the task calls for generating text, bring in an LLM. Composing these tools well means understanding where each one falls short and where each is strong.
A test for when to use Jev
The practical test is simple. Jev is worth considering when you can define a bounded set of decisions, supply the relevant context, and do not need the model to reason through a long chain of steps or produce open-ended text. In those cases, it can be a fast, cost-effective component of a larger system.
That does not make Jev an alternative to LLMs in every setting, nor should it be. It expands the set of primitives available to an AI engineer. The question isn’t whether to choose Jev or an LLM in the abstract, but how to combine each tool with code and workflow design to solve the problems you encounter in your actual work.
To me, the deciding factor that will make Jev either a niche product or ubiquitous is this: how easily can builders grasp how, when and where to use it? LLMs have the advantage of riding on the coattails of natural language, which humans have evolved to use as an interface. Jev and general purpose classifiers don’t necessarily provide that affordance, so the challenge will be uncovering the high value use cases and products that Jev enables in a digestible way.
Really clear both/and piece. The Pac-Man demo (Astra writes the strategy, Jev picks each move from the live state) and Gregor's browser agent make the primitive concrete in a way the launch posts often do not.
One small push on calibration: saying that 80% predictions should land about 80% of the time is true across a population, but production still needs thresholds tuned on held-out tickets from your own traffic. Did you keep a refusal or needs_review band in the Pac-Man / browser loops, or always take the top choice?
I've been collecting Jev guides and experiments at JevMade if that helps.