> ## Content Index > Fetch the complete content index at: https://www.tao.media/llms.txt > Use this file to discover other available public pages before exploring further. # How to Use Jev: A Beginner's Guide to TypeSafe’s Decision Model - URL: https://www.tao.media/how-to-use-jev-a-beginners-guide-to-typesafes-decision-model/ - Published: 2026-09-21T12:32:39.000Z - Updated: 2026-09-21T12:32:39.000Z - Description: How TypeSafe’s Jev uses structured probabilistic decisions to make AI workflows faster, cheaper, and easier to control alongside traditional LLMs. - Author: Bart Hillerich - Tags: TypeSafe, AI, Educational, #editors-picks TypeSafe's new Jev model is easy to misunderstand because it arrives at a moment when almost every new AI model is judged by the same questions: *Can it write better? Can it code better? Can it reason longer? Can it sound more natural?* Those questions don't apply to Jev because the model is a different AI bet. As TypeSafe's first "System One" (a term coined by TypeSafe) model, Jev is not designed to produce polished prose, write software, or carry out long chains of reasoning. It is designed to make decisions inside software, particularly the kinds of judgment calls that traditional code struggles to handle cleanly. 0:00 /0:32 1× "when a designer gets access to Jev" | [@heystefan\_](https://x.com/heystefan%5F/status/2101369117496521042?s=20&ref=tao.media) Instead of giving Jev a prompt and waiting for a written answer, developers provide it with a piece of context, or “state,” along with one or more predefined questions. Jev then returns structured probabilities that software can use immediately. The result is not a paragraph explaining why a customer sounds frustrated or why a document belongs in one category rather than another. It is a machine-readable judgment that can be plugged directly into an existing workflow. That narrower role is the key to understanding both what Jev does well and why it may be useful alongside, rather than instead of, conventional LLMs to improve workflows. [Vercel Says Jev Saw Fastest First-Day Adoption in AI Gateway HistoryVercel said TypeSafe AI’s structured decision model reached roughly 13% of paid AI Gateway teams in its first day, outpacing several major model launches on the platform.![](https://storage.ghost.io/c/78/0b/780ba906-b1a7-4bf0-873c-bdd5c32e5331/content/images/icon/Group-1321319358-476302d6-7c45-4a7d-9a83-a50972225bb9.png)IntelligenceBart Hillerich![](https://storage.ghost.io/c/78/0b/780ba906-b1a7-4bf0-873c-bdd5c32e5331/content/images/thumbnail/ChatGPT-Image-Sep-19--2026--12_29_21-AM-c59b6549-9c1a-485e-b84d-2cb246d52cc5.png)](https://www.tao.media/vercel-says-jev-saw-fastest-first-day-adoption-in-ai-gateway-history/) ## Jev Is Built for the Decisions Between Actions Most AI applications today give general-purpose models a broad mandate. A customer support agent might be expected to understand a complaint, identify the customer’s intent, check whether the problem falls within policy, decide which team should handle it, draft a reply, and perhaps take an action on the customer’s behalf. Modern LLMs can do all of those things because they are flexible by design. The same model can summarize a legal document, write Python, compose an email and explain a medical paper because its job is ultimately to generate the next useful sequence of tokens. And we, as consumers, tend to love this flexibility; become familiar with one LLM, and you're pretty much set for anything you'd want to do. But that flexibility we love actually becomes less attractive when software only needs a narrow judgment. If a company simply wants to know whether a customer is asking for a refund, which department should receive a support ticket, or whether an AI-generated answer appears to violate a policy, generating several paragraphs of text is unnecessary and wastes time (and credits). In those cases, the useful product is simply the decision itself, not the lengthy response. Jev is built around that premise, optimizing for decision making instead of response drafting. TypeSafe describes the model as taking unstructured state and returning typed probabilistic decisions. In practical terms, the application defines the possible answers in advance, Jev evaluates the available context, and the surrounding software decides what to do with the result. That makes Jev less like a chatbot and more like a semantic decision layer sitting inside an application. And that also makes Jev fast. Really fast. [Nailthy Tang](https://x.com/nailthy62?ref=tao.media), co-founder of Drape, published the below video showcasing how she's using Jev for "\~620ms per decision" actions. 0:00 /0:31 1× "it makes realtime virtual try-on hauls possible." | [@nailthy62](https://x.com/nailthy62/status/2101388186916454439?s=20&ref=tao.media) TypeSafe’s own performance figures put Jev’s end-to-end response time at roughly 70 to 500 milliseconds, depending on the complexity of the request. The company says that can make Jev around 40x to 200x faster than frontier LLMs on comparable “System One” decision tasks, where the goal is to classify, score, route, or verify rather than generate a long-form response. In TypeSafe’s broader workflow evaluations, Jev reached a maximum reported speedup of 193.6x over the LLM-based configurations it tested. That speed comes partly from how Jev produces its answers. ## How Jev Actually Answers Questions Traditional LLMs generate tokens sequentially, meaning each new piece of output depends on what came before it. Jev instead evaluates its structured outputs in parallel. TypeSafe has pushed that far enough to demonstrate Jev making roughly 10 decisions per second inside a Doom demo, showing the kind of real-time use case that becomes possible when AI inference starts operating closer to normal application latency. TypeSafe currently gives developers three basic ways to ask Jev for a judgment: Choice, Score, and Noul. Choice is used when the answer must come from a fixed set of possibilities, such as deciding whether a support ticket belongs to billing, technical support or sales. Score is designed for ordered judgments, such as estimating severity, quality, or customer frustration on a defined scale. Noul handles binary propositions and returns the probability that a statement is true. Those primitives may appear simple at first glance, but they cover a large portion of the judgment calls that occur inside real software. Imagine a B2B software company receives the following inquiry: > “We’re evaluating the platform for around 200 support agents. We need SSO and EU data residency, and procurement wants pricing before Friday.” A conventional AI workflow might send the entire message to an LLM and ask it to determine what should happen next. Jev encourages developers to break the decision into smaller parts instead. The system might ask which sales segment the prospect belongs to, how strong the buying intent appears, whether there is a meaningful deadline and whether the requirements suggest that a security review will be necessary. Jev evaluates those questions against the same state and returns probabilities for each one. The company’s application can then decide that a high-confidence enterprise classification should create a sales opportunity, while a strong security signal automatically attaches the relevant compliance materials. In that system, Jev never needs to write the sales response. Its job is to help determine what should happen before another part of the system takes over. ## The Cleanest Architecture Separates Facts From Judgment Working with Jev also means knowing what not to ask it. Suppose the same prospect entered a 14-day trial nine days ago. Software does not need an AI model to determine whether the trial has expired. The dates can be compared exactly in code. The same is true for invoice calculations, account balances, fixed eligibility requirements and other deterministic rules. Jev becomes useful when the answer depends on interpretation rather than arithmetic. *Does the prospect sound urgent? Does the message indicate serious buying intent? Is the customer threatening to cancel? Does an AI-generated answer actually address the user’s question? Does a document appear likely to require legal review?* TypeSafe itself recommends this division of labor, noting that Jev 1.13 is weaker at tasks involving exact calculations, date comparisons and some forms of multi-step indirection, while its strengths are concentrated around semantic judgment. The result is a useful design principle: if software can know something exactly, let software handle it. Use Jev for the places where meaning has to be interpreted. This approach also makes the surrounding system easier to audit. A refund workflow, for example, can use ordinary code to determine whether an order is within the return window while using Jev to determine whether the customer is actually asking for a refund. The final action can depend on both conditions without forcing the model to control the entire process. ## Why Smaller Questions Usually Produce Better Systems Jev also changes how developers should think about prompting. With a general-purpose LLM, it is common to build a large prompt containing the entire task, policy and desired output format. With Jev, the better approach is usually to decompose one broad judgment into several narrower ones. Consider the question, *“Is this lead valuable, urgent and likely to buy?”* That sounds easy to answer for a person, but it is complex for a machine, as it combines several independent ideas. A lead could be extremely valuable while showing little urgency. Another could be highly motivated but fall outside the company’s target market. A third might have strong intent but require capabilities the product cannot provide. Instead of collapsing those conditions into a single score, Jev can evaluate account fit, purchase intent, urgency, and complexity independently. The application can then combine those results according to its own business rules. The model does not become the company’s policy engine. It provides semantic signals that the company’s policy engine can use. That distinction becomes even more useful when several questions are evaluated in parallel. ## Evaluating Many Questions in Parallel TypeSafe designed Jev so multiple independent questions can be evaluated against the same state in a single request. That means a customer support system does not need to make separate sequential calls to determine intent, frustration, urgency, churn risk, and department ownership. All of those judgments can be requested together. Consider an incoming message saying that a product has repeatedly deleted a customer’s work and that the customer plans to cancel unless the issue is fixed immediately. One Jev request could evaluate whether the issue is technical, whether the message contains cancellation intent, how frustrated the customer appears, whether the situation is urgent, and whether the case should receive human review. The surrounding application might route the ticket to technical support, add a retention flag, and place it near the top of the queue. If an LLM is then used to draft the response, Jev could appear again later in the workflow to check whether that draft actually addresses the customer’s complaint or makes a promise the company does not permit. The model is therefore not limited to one point in the workflow. It can provide judgments before an action, after an action, or at several stages in between. ## Confidence Is What Makes Automation Practical Structured output alone does not solve the most difficult problem in AI automation: models can still be (and oftentimes are) wrong. Jev’s probability and confidence outputs address this. For Choice and Score questions, Jev returns probability distributions and confidence information. That gives developers a way to treat uncertainty as part of the application rather than hide it behind fluent language. A highly confident result could be allowed to continue automatically. A less certain result could be forwarded to a more capable model with additional context. A genuinely ambiguous or high-risk case could be sent to a human. The appropriate thresholds will vary substantially by use case. A content-tagging system can tolerate more uncertainty than a workflow deciding whether to issue a large refund or approve a financial transaction. TypeSafe recommends testing those boundaries on real application data rather than adopting universal confidence cutoffs. Beyond making a judgment quickly, Jev lets software decide when that judgment is not trustworthy enough to act on automatically. ## Jev Makes More Sense Beside LLMs Than Instead of Them In the clearest production architecture, Jev works around frontier models like Claude or GPT instead replacing them. Let's again look at our customer service system example here. Jev can first classify the incoming request, estimate urgency, identify the likely product area, and determine whether the case appears sufficiently clear for automation. Ordinary code can then check the customer’s account status, purchase date, and relevant company policies. If a written response is required, an LLM can generate it. Jev can then evaluate the completed response against explicit criteria before anything reaches the customer. Each component performs the job it is best suited for. Jev handles semantic judgment, the LLM handles generation, software handles deterministic rules and permissions, and humans remain responsible for cases where ambiguity or risk makes automation inappropriate. The architecture also changes how companies can allocate expensive AI inference. Instead of sending every request directly to a frontier reasoning model, a system could use Jev to determine which requests actually require one. Routine cases can remain in deterministic software, intermediate cases can go to cheaper models, complex cases can reach frontier systems, and sensitive edge cases can be routed to people. ## Where Jev Fits in Real Products Support routing is one obvious application, but the same pattern extends across many areas where software currently relies on either brittle rules or expensive LLM calls. Jev could sit around an AI agent and evaluate whether a requested tool action appears appropriate before it executes. It could inspect the agent’s final output for missing requirements or policy violations. Sales teams could use it to estimate account fit, buying intent, and urgency separately before deciding which leads deserve attention. It could also act as a router for AI infrastructure itself, deciding whether an incoming task belongs in normal application code, a lightweight model, a frontier reasoning model, or a human queue. Large-scale data processing may be another compelling use case. A company with millions of support transcripts, customer reviews, listings, or agent traces might not want a frontier model to write an analysis of every record. Jev could instead turn each record into structured semantic attributes, allowing conventional databases and analytics systems to rank, filter, and aggregate the resulting data. In each case, the underlying pattern is the same: the task primarily requires a judgment, not a piece of prose. ## Good Jev Inputs Look More Like API Design Than Prompt Engineering Developers accustomed to prompting chatbots may also need to adjust how they prepare input for Jev. Long personas, motivational instructions, and carefully worded requests for step-by-step reasoning add little value when the model is not expected to produce a narrative answer. The more important work is defining the judgment clearly. A good Jev question asks one thing and provides meaningful boundaries between the possible answers. “Choose the right department” leaves the categories relatively vague. Defining technical support as bugs, broken product behavior, outages, and integration failures while defining billing as charges, invoices, subscriptions, and refunds gives the model a much clearer decision surface. The same discipline applies to state. Providing more context is not automatically better. The useful state is the information that could reasonably change the model’s judgment: the customer message, relevant product information, important account details, and perhaps recent support history. Dumping months of unrelated logs and every internal record associated with the customer can introduce noise without improving the answer. For Jev, to prevent performance decline, the goal should be the smallest complete version of the situation rather than the largest possible context window. ## The Bigger Idea Behind Jev For the past several years, much of AI development has revolved around making increasingly capable general-purpose models. The implicit assumption has often been that a sufficiently powerful model should be able to understand a request, reason about it, decide what to do, use the necessary tools, and generate the final result. Jev points toward a more modular future. Traditional software already works this way. Databases store data, search systems retrieve it, payment infrastructure moves money, authentication systems confirm identity, and application code defines what users are allowed to do. AI systems may ultimately develop a similar division of labor. Frontier reasoning models can handle difficult problems. Generative models can create text, code and media. Deterministic software can continue handling anything that can be known exactly. Humans can remain responsible for sensitive edge cases. A model like Jev can occupy the space between them, making the constant stream of small, fuzzy judgments that determine which component should act next. In that light, Jev does not need to become the entire AI application to be useful. It only needs to make the decision layer inside that application faster, cheaper and easier to control. So far, that's exactly how it's playing out.