# Jev Doesn’t Write, It Decides: Games Today, Company Data with Care, Computer Vision Next > Source: > Published: 2026-09-24 23:01:02+00:00 Most of what we build with LLMs is not writing. It is deciding. Which team gets this email. Is this message spam. Which move should the bot make. Is this action allowed. We use a text generator for these decisions because it is the tool we have, and then we spend time parsing its prose, fixing its JSON and wondering whether its “90% sure” means anything. In September 2026, TypeSafe released **Jev**, a model built for exactly that gap. It does not generate text at all. You give it a state and a set of typed questions, and it returns answers with probabilities, in one parallel pass, in a fraction of a second. I have spent the last weeks looking at where a model like this fits in real systems. My conclusion so far has three parts, and they are the structure of this post: The public facts, from TypeSafe’s documentation and early coverage: On TypeSafe’s own four-workflow evaluation, Jev scored about the same accuracy as GPT-5.6 Terra (67.8% vs 67.9%) at roughly 1/75 of the cost per case and about 25 times faster, while larger reasoning models scored higher. Those numbers are the vendor’s. The most useful independent look I found (an analysis on archerhume.com) supports the core claim that probabilities are read out directly, measured a calibration error of about 0.03 on 1,200 MMLU items, and also found two things worth remembering: calibration was weaker on harder, freshly generated problems, and **the same option’s probability moved between 0.84 and 0.96 depending on where it sat in the option list**. So: fast, cheap, typed and reasonably calibrated, with no explanation of why. A game is almost the ideal environment for a model like this: **An easy example.** A player with a microphone says: *“hey, you with the sword, how much for a room?”*. The speech-to-text transcript and the NPCs in range go into the state, and Jev gets one yes/no question per NPC: *is the player talking to this character?* It comes back with innkeeper 0.81, guard 0.12, bard 0.03. The guard is the one carrying a sword, but the request is for a room, and Jev weighs both. The code decides what happens next: above 0.6 the innkeeper answers, below it the NPC asks “talking to me?”. This is not hypothetical. A community benchmark (jev-benchmark, on jev-1.13.0) tested exactly this task on 79 hand-labelled utterances designed to be tricky, and reported an F1 of 0.96 with precision 1.0, against 0.82 for a fuzzy name-matching heuristic, and 0.93 when names were phonetically misspelled. The same repository used Jev as a chess engine: about 37% best-move accuracy, an estimated ~950 Elo and a median of 166 ms per move, provided the code first computes the facts about the position (Jev does not calculate ahead). Another project, WorldKit, packages the pattern as an NPC runtime: the engine enforces the rules and Jev only ever sees the actions that are currently valid. **What about game engines?** Jev is an HTTP API with official Python and JavaScript SDKs, so any engine can call it. The most complete integration I found is jev-unreal-statetree, a C++ plugin (public alpha) that adds a “Jev Decision” task to Unreal Engine 5.8’s StateTree. It sends one request when a state is entered, not every frame, and tags each request with a world “revision” number so that answers arriving after the game state has changed are simply discarded. For Unity, Godot or browser engines like Three.js the pattern is the same over HTTP. One rule applies everywhere: never ship the API key inside the game build; put a small server or gateway between the game and Jev. The samples are small, and these are community projects, not peer-reviewed results. But the pattern is right, and it is the same one I would use outside games: **the model supplies judgement, the code owns the workflow.** Now take the same model into a company. Routing customer emails, flagging complaints, checking whether a document is complete. The pattern is identical and the economics are compelling. The difference is the data. What the documentation says, and what it does not: None of this makes Jev unusable at work. It changes how you use it: If sending data out is simply not allowed, there is now an open alternative built on the same idea: **Laya**, from Convai, released under Apache 2.0. It is a small encoder (421M parameters, with a 322M multilingual variant), runs on a CPU in a few hundred milliseconds, and can be hosted inside your own network. The honest caveats come from its own model card: out of the box it is close to guessing on typed decisions, its probabilities are overconfident until you refit a temperature on your data (its reported calibration error drops from 0.47 to 0.08 after that), and accuracy collapses with more than about 20 options. In other words, Laya is a foundation to fine-tune on your labels, not a drop-in replacement. Here is the observation that made Jev click for me. **Computer vision has worked like a System One model for a decade.** An image classifier reads the input once and returns a probability over a fixed set of labels. No one asks a ResNet to write “I think it’s a cat, 90% sure”. It just gives you the softmax. What Jev does is bring that shape of answer to language: read the state, return a distribution over typed options. The history also carries a warning. Modern image classifiers were famously shown to be overconfident (Guo et al., 2017), and the fix was calibration on held-out data, not trusting the raw softmax. The same lesson applies to Jev. Today, Jev is text-only. The documentation is explicit: no images. So the practical architecture is a pipeline: a vision network turns pixels into a typed state, and Jev decides. The community is already doing this. **jev-eyes** runs OCR, keeps the spatial layout of the text on a character grid, optionally adds zero-shot labels from a SigLIP image model, and passes the result to Jev as state. Its own numbers show where the time goes: OCR takes 1.5–2.5 seconds per screenshot on a laptop, so the vision step, not Jev, is the bottleneck. **jev-multimodal** explores sharing one visual computation across several Jev questions. Where I see this going: **The part that is easy to miss: chained probabilities.** If the detector is 70% sure it saw a potion and Jev is 88% sure you should drink it, your decision is not 88% safe. The perception error flows straight into the decision. In a pipeline like this, calibrate end to end: measure how often the final action is right, and set thresholds on that, not on either model’s number alone. What I expect next is speculation, so I will label it as such. I would not be surprised to see decision heads attached directly to vision encoders, so that the image goes in and typed probabilities come out without a text step in between. Open models like Laya make it possible to try this in-house, trained on your own labels, which also solves the data question from section 3. Jev is not a smarter LLM. It is a different tool for a job we have been doing with the wrong one. For games, it already fits almost perfectly: the decisions are bounded, the rules live in code, latency matters and the data is yours. For companies, it is promising but it is a hosted, closed API, so the question is less “is it good?” and more “what am I allowed to send it?”. And for vision, it closes a loop that computer vision opened long ago: models that simply decide, with a probability attached, and leave the rest to your code. **References** *Figures by the author. The tavern and game-screen examples are illustrative; numbers from benchmarks are as reported by their authors.* [Jev Doesn’t Write, It Decides: Games Today, Company Data with Care, Computer Vision Next](https://pub.towardsai.net/jev-doesnt-write-it-decides-games-today-company-data-with-care-computer-vision-next-21178d277475) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.