# Jev vs Kev: The Two Decision Models Changing How AI Agents Make Choices > Source: > Published: 2026-11-06 17:01:03+00:00 **The Problem Nobody Talks About** Picture this. You are building an AI-powered support system. A customer sends in a ticket that says: “I was charged twice. Please fix this ASAP.” Your code needs to answer three simple questions: So you send the ticket to a large language model. And it comes back with something like this: *“Based on the customer’s message, this appears to be a billing-related issue. The use of the phrase ‘ASAP’ suggests a heightened level of urgency, and the tone indicates the customer is frustrated. I would recommend routing this to the billing team for prompt resolution…”* Your code reads that. Extracts the three answers buried inside it. Discards everything else. Moves on. Now imagine that happens a thousand times a day. You are paying to generate words your code reads for half a second and throws away. The paragraph was never the point. Three answers were the point. And somewhere between the model and your if-statement, you burned money and time producing sentences nobody needed. This is the exact gap that a brand new category of AI model is trying to fill. It is called a **decision model**, and in 2026, two of them showed up within weeks of each other: **Jev** by TypeSafe AI, and **Kev** by Jared Palmer. This blog explains both of them, from the ground up. No hype, no skipped details, just what they are, how they work, and when you should actually reach for one. To understand Jev and Kev, you first need to understand why they were built at all. A large language model generates text one token at a time. Given a prompt, it predicts the next most likely word, then the next, then the next, in a sequential chain. This is called autoregressive generation, and it is what makes models like ChatGPT, Claude, and Gemini so powerful for open-ended tasks: writing, coding, summarizing, reasoning through complex problems. But that sequential process has a cost. Every token generated is compute spent. And when all you need is a yes or a no, or a pick from three options, you are running a massive engine to answer a question that fundamentally does not require it. A decision model takes a completely different approach. Instead of generating text, it reads your context, reads your questions, and returns typed answers with confidence scores, all in a single pass. No token-by-token generation. No parsing a paragraph to extract a decision. Just structured answers your code can use directly. Think of a decision model like a very well-designed exam form. When you take a multiple-choice exam, the teacher does not ask you to write an essay about each answer. They give you a question, a set of options, and you circle one. The answer is already bounded. The format is already defined. Everything you return is directly usable. A decision model works the same way. You hand it some context, you define your questions with their possible answers upfront, and it fills in the form. No prose, no paragraphs, no parsing. Just structured answers your code can branch on immediately. Both Jev and Kev support exactly three types of questions. Here is what each one actually means. You give the model a set of possible answers. It picks exactly one and tells you how confident it is. Think of it as a dropdown menu in your application. You define the options. The model selects one. **Example:** “Which team should own this ticket?” with options Billing, Technical, Sales, and General Enquiry. The model returns choice: "Billing" with a confidence score of 0.94. Your code routes the ticket. No sentence to read, no parsing to write. You define a scale with named levels. The model places the input somewhere along it and returns a numeric position. Unlike Choice, the levels have a natural order and the model understands that order. **Example:** “How urgent is this ticket?” with levels ranging from “can wait” to “right now.” The model returns a number like 2.7, not just a bucket label. Your code decides whether 2.7 crosses your threshold for immediate action. Use Score when the distance between levels matters. Use Choice when the options are genuinely distinct categories with no ranking. You write a statement that can be true or false. The model returns a number between 0 and 1: how confident it is that the statement is true. Near 1 is a strong yes. Near 0 is a strong no. Near 0.5 means genuinely uncertain. The word “Noul” is TypeSafe’s own invention. It is simply their label for this output type. **Example:** “The customer is requesting a refund.” The model returns noul: 0.91. Your code checks: if above 0.8, flag for the refund team. If below 0.4, skip it. If it lands in the middle, send to human review. The threshold is your business decision, not the model’s. This is more useful than a binary yes or no because it lets you build confidence-gated logic. When you send a request with three questions, all three are evaluated at the same time. The model reads your context once, scores all three questions against that same read independently and simultaneously, and returns all three answers in a single response. According to TypeSafe, adding questions barely changes the response time, and each extra question only adds its own cheap token cost. Their own 13-question example came out 12 times cheaper and 10 times faster than asking those questions one at a time. One context in. Many independent judgments out. One round trip. Most AI models you have used are autoregressive. They work like a typewriter: predict one token, feed it back in, predict the next, repeat. The longer the answer, the longer you wait. The output length directly controls the cost. Jev is non-autoregressive. It ingests one state, evaluates every question against it in parallel, and returns all answers in a single pass in 70ms to 500ms. There is no decode loop. There is no writing happening at any stage. Based on what TypeSafe has disclosed publicly and what researchers have reconstructed, the architecture works in three steps: **State encoding:** Your context is read by a transformer encoder once, producing a single dense numerical representation of what it means. **Parallel question branching:** Each question gets its own branch from that single representation. Every branch sees the same encoded state but evaluates independently. This is why adding more questions costs very little extra time: the state is encoded only once regardless of how many questions follow. **Decision head output:** Instead of a language modelling head that predicts the next word, Jev has a decision head that scores your provided options directly and returns probability distributions over them. TypeSafe has not published the full architecture, parameter count, or training data. The above is reconstructed from public disclosures. Treat it as the best available picture, not confirmed internal detail. This is where Jev makes its most interesting departure from conventional AI. Most people building with AI know two training approaches. **RLHF (Reinforcement Learning from Human Feedback)**, which made ChatGPT useful, optimizes for human preference. **RLVR (Reinforcement Learning from Verifiable Rewards)**, used in reasoning models, optimizes for correctness on problems with a checkable right answer. TypeSafe trained Jev using a third approach they call **RLCD: Reinforcement Learning for Calibrated Decisions.** **Calibration** is the key concept here. A calibrated model is one where the confidence score it reports actually matches its real-world accuracy. If Jev says 90% confident, it should be correct approximately 90% of the time. Most generative models are not calibrated this way. They produce verbal expressions like “I think” or “I’m fairly sure” that map to no measurable probability. In **RLCD**, the model is penalized not just for wrong answers but for overconfident wrong answers and underconfident right answers. The training pressure is specifically on making the confidence number honest, not just making the answer correct. Technically, RLCD replaces the binary reward signals with Proper Scoring Rules like the Brier Score, plus a batch calibration penalty. Why this matters practically: when Jev returns a confidence score of 0.94, you can actually use that number to build escalation logic in your code. Route automatically above 0.85, send to human review below it. That threshold means something, unlike a verbal “I’m fairly confident” from an LLM. Every request to Jev has exactly two parts: **State:** The context Jev reads. This can be a plain text string, a JSON object with named fields, or a full conversation transcript. Think of this as the document the model will evaluate. It accepts up to 64,000 tokens per request, with a 32,000 token limit on the state itself. **Questions:** A dictionary of typed questions, each with a unique ID your code uses to read the answer back. You can mix Choice, Score, and Noul questions in the same request. Here is a complete working example: ``` python from typesafe_sdk import TypeSafeClient, Choice, Noul, Score# Reads TYPESAFE_API_KEY from environmentclient = TypeSafeClient()result = client.system_one.create( model="jev-latest", state="I was charged twice. Please fix this ASAP.", questions={ "is_billing": Noul( instructions="Is this ticket about a billing or payment issue?" ), "customer_tone": Choice( instructions="What is the customer's emotional tone?", criteria={"calm": None, "frustrated": None, "angry": None} ), "urgency": Score( instructions="How urgent is this ticket?", criteria=["can wait", "this week", "today"] ) })# Each answer is directly usable by your codeprint(result.answers.is_billing.noul) # e.g. 0.97print(result.answers.customer_tone.choice) # e.g. "frustrated"print(result.answers.urgency.score) # e.g. "today" ``` Three questions sent. Three answers back. No paragraph to parse. No second API call to clarify. Your code reads the answers like reading fields from a dictionary. **Setup:** pip install typesafe-sdk (Python 3.10+). Set TYPESAFE_API_KEY in your environment. The endpoint is POST Two things worth flagging. The speed and cost multiples compare against the most expensive frontier models, so your actual savings depend on what you are replacing. The workflow benchmark uses the average output of two other frontier models as ground truth, which means it measures model agreement rather than verified real-world accuracy. TypeSafe is unusually transparent about Jev’s limits. These are not edge cases. They are hard architectural boundaries. **It cannot generate text.** No prose, no code, no explanations, no summaries. If your workflow needs a written reply after the decision is made, you still call an LLM for that step. Jev decides what to do. The LLM writes what to say. **It does not do arithmetic.** While Jev reaches 99% accuracy when the correct answer is among the options presented, it correctly rejects arithmetic problems where no valid answer is given only 7% of the time. The fix is straightforward: do your arithmetic in code, then pass Jev the computed result to evaluate. **It can be swayed by injected text.** If the state you send contains language that argues for a particular classification (“this is definitely not urgent”), Jev may drift toward that answer. TypeSafe flags this directly in their documentation. Do not treat the state as a trusted input. **It is closed source.** You cannot download the weights, inspect the architecture, or run it offline. Your entire dependency is on TypeSafe’s API being available. This is the sharpest contrast with Kev, which we cover next. Kev is Jared Palmer’s open-source answer to Jev. Same concept, same API contract, open weights, Apache-2.0 license, and fully runnable on your own hardware. It is not a single model. It is a family, currently in four sizes: The first three models can run on a single consumer GPU or even an Apple Silicon Mac. The 0.8B model fits in 1.5 GB of GPU memory, which means it can run on almost anything. This is where Kev earns its transparency advantage over Jev. Because the weights and training code are public, the architecture is fully inspectable. Every Kev model is built from two components on top of a frozen base model: **1. A LoRA adapter** LoRA (Low-Rank Adaptation) is a technique that lets you fine-tune a large pretrained model by adding a small number of trainable parameters on top of it without changing the original model weights. Instead of retraining all billions of parameters, you add lightweight rank-16 adapter matrices to the attention and MLP projections of the model. For Kev-4B, this means roughly 33.8 million trainable parameters on top of a 4 billion parameter frozen backbone, just 0.84% of the total. In plain terms: Kev borrows the language understanding of a powerful pretrained Qwen model, then teaches it to make decisions through a small, focused layer of additional training. The base model is never modified. **2. A pointer head (replacing the language model head)** This is the key architectural change that makes Kev a decision model and not a text generator. A standard language model has an LM head: a large output layer that maps the model’s internal representations to probabilities over its entire vocabulary (tens of thousands of tokens). This is how it generates the next word. Kev removes that head entirely and replaces it with a pointer head: two small projection layers that score each option’s closing token against the question’s final token, then apply a softmax over your options to produce probabilities. In simple terms: instead of asking “what word comes next out of 50,000 possibilities,” the pointer head asks “which of the three options you gave me best matches this context.” The entire output space is whatever you defined in your question, nothing more. The technical spec for Kev-4B’s pointer head is: two linear projections from 3,072 dimensions down to 256, scoring each option’s end token against the question’s end token, with a calibration temperature of T=2.41 applied at load time. Kev was trained on a dataset called decision-v7: 12,576 examples drawn from ten public datasets plus generated policy and rule examples. No outputs from Jev were used for training. The training recipe is fully public in the repository. The training procedure for Kev-4B: two epochs on decision-v7 from the base model, LoRA rank 16, alpha 32, learning rate 5e-5 with a one-cycle schedule, effective batch size 8, bf16 precision. After training, a single calibration temperature (T=2.41) is fitted on a held-out development set and stored in the pointer head file, applied at every inference call. The first prototype, Kev-0.5B, was trained on an Apple M5 laptop in under two hours. The full 4B model was trained on a single consumer GPU, an RTX 4080 with 16 GB of memory, in about 8.5 hours. This is a meaningful signal: the entire approach is reproducible by an individual developer without a cluster. ``` # Clone and installgit clone https://github.com/jaredpalmer/kev.gitcd kevuv sync --extra serve# Serve Kev-4B on port 8008uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8008 ``` Once running, you use the exact same TypeSafe SDK you would use for Jev. The only change is api_key and base_url: ``` python from typesafe_sdk import TypeSafeClient, Choice, Noul, Scoreclient = TypeSafeClient( api_key="local", # no real key needed for local base_url="http://127.0.0.1:8008", # points to your local server model="kev-latest")result = client.system_one.create( state="I was charged twice. Please fix this ASAP.", questions={ "is_billing": Noul( instructions="Is this ticket about a billing or payment issue?" ), "customer_tone": Choice( instructions="What is the customer's emotional tone?", criteria={"calm": None, "frustrated": None, "angry": None} ), "urgency": Score( instructions="How urgent is this ticket?", criteria=["can wait", "this week", "today"] ) }) ``` That is the entire migration from Jev to Kev. Two lines change. Everything else is identical. Kev’s evaluation is split into two categories that are worth understanding before reading the numbers: “trained sources” (held-out examples from the same datasets Kev was trained on) and “new sources” (completely unseen datasets and policy types). The second number is the honest one for real-world use. For context: on the same new-sources development split, Jev scored 0.857 and Kev-27B scored 0.851. That is a gap of 0.6 percentage points. Palmer himself notes this is not a controlled comparison because Jev’s training data is unknown. One honest caveat from the Kev repository: the 0.8B model is described as a narrow-task model that needs fine-tuning for production use. If you are running locally on limited hardware, budget for some additional fine-tuning on your own data before deploying it. **Latency:** The SGLang documentation cites 205ms for a vanilla decision on a high-end GPU (H200). On commodity hardware, expect 1 to 2 seconds. That is competitive with Jev’s 70 to 500ms range for most use cases. Most of Kev’s limits mirror Jev’s, because the architecture is the same. No text generation, no arithmetic, and susceptibility to injected text in the state. Two limits specific to Kev are worth noting: **The 0.8B model needs fine-tuning for production.** On new sources it reaches only 65 to 68% accuracy out of the box. It is the right starting point if you want to train on your own data, not a drop-in replacement for production routing without any additional work. **Performance on truly out-of-domain tasks degrades.** The gap between trained-source and new-source accuracy is real across all model sizes. If your use case is significantly different from the decision-v7 training distribution, plan to evaluate carefully on your own data before shipping. Here is a clean comparison of the two models across the dimensions that actually matter for a production decision: All figures sourced from vendor documentation, model cards, and independent academic evaluations available as of October 2026. Verify current pricing and API details before building in production. **Choose Jev when:** You need the highest available accuracy on a hosted decision model and you are comfortable with a closed vendor. You want zero infrastructure to manage. You are building a product where latency matters and you cannot guarantee GPU availability for a self-hosted model. Your data going to a third-party API is acceptable under your privacy requirements. **Choose Kev when:** Your data cannot leave your infrastructure. You want to inspect, audit, or fine-tune the model. You want to avoid per-call vendor fees at scale. You are experimenting and want to run tests without an API account or waitlist. You want to start with a small model (0.8B runs on 1.5GB of GPU memory) and scale up as needed. **Choose neither and stick with an LLM when:** The output needs to be prose, a summary, or an explanation. The answer space is not bounded and you cannot define the options upfront. The task requires multi-step reasoning where each step informs the next. You need the model to handle arithmetic as part of its decision. Both Jev and Kev represent something more significant than just two new models. They represent a bet that the way AI has been deployed in production is architecturally wrong for a large class of tasks. Most developers, when they need a classification or a routing decision, reach for the same tool they use to write emails and summarize documents. That is a bit like using a passenger jet to deliver a letter across the city. The design philosophy behind decision models is to disaggregate the AI stack: let a generative model write when writing is needed, and let a fast, cheap, structured model decide when deciding is needed. TypeSafe explicitly frames this as the model becoming a “smart if-statement” inside software, rather than a service that humans converse with. TypeSafe AI turns model calls into software control flow, not chat output. The core idea is to break one messy task into many small calls where software can act when confidence is high and escalate when it is not. The confidence score that both models return with every answer is not just a nice-to-have. It is the mechanism that lets you build escalation logic: if Jev is 95% confident, act automatically; if it is 60% confident, route to a human. That is a pattern that is genuinely hard to implement cleanly with a generative model that produces prose and attaches a verbal “I think” to its answer. Whether this category of model sticks is still an open question. Both products launched in September 2026 and production deployments at scale are still early. The independent evaluation on LegalBench showed Jev underperforming specialized LLMs on domain-specific reasoning, which is a real caution for anyone planning to use it outside of routing and classification tasks. But the idea is sound, the pricing math is compelling, and the open-weight availability of Kev means you can test the concept without any commitment. That is a low-risk experiment worth running for most teams building AI-heavy products. Decision models like Jev and Kev are a new category of AI model built for one purpose: returning typed answers with confidence scores instead of generating text. They are faster, cheaper, and structurally simpler for classification, routing, scoring, and filtering tasks. Jev is the closed, hosted version from TypeSafe AI. Kev is the open-weight version from Jared Palmer, API-compatible with Jev and runnable on your own hardware. Neither replaces a generative LLM. They sit alongside one, handling the judgment so the LLM only has to handle the writing. **Want to go hands-on?** Jev: pip install typesafe-sdk and visit typesafe.ai for an API key. Kev: git clone https://github.com/jaredpalmer/kev and run it locally in under five minutes. **Can I use Jev and Kev together in the same project?** Yes, and it is actually a sensible pattern. Because Kev implements the same API contract as Jev, you can use Kev locally during development and testing, then switch to Jev in production by changing the base_url and api_key. Some teams use Kev for low-stakes routing decisions that run at high volume and Jev for higher-stakes decisions where calibration accuracy matters more. **Does Jev or Kev replace my LLM?** No, and neither model claims to. They handle the judgment layer: routing, classification, scoring, and filtering. Your LLM still handles anything that needs written output, open-ended reasoning, or multi-step thinking. The intended architecture is both running together, not one replacing the other. **What happens when Jev or Kev is not confident enough to decide?** This is one of the most useful properties of both models. Every answer comes with a probability score. You set a threshold in your code. If the score falls below it, you route to a human reviewer, escalate to an LLM for a second opinion, or ask for clarification. The model does not pretend to know when it does not. Your code decides what “not confident enough” means for your use case. **Can Kev be fine-tuned on my own data?** Yes. The full training recipe is public in the Kev repository. You can fine-tune on your own labeled examples using the same decision-v7 pipeline. This is particularly recommended for the 0.8B model, which reaches only 65 to 68% accuracy on new sources out of the box but improves significantly with domain-specific training. **Is Jev’s “zero hallucination” claim accurate?** Partially. The claim is about output format, not correctness. Jev is guaranteed to return one of the options you defined, so it cannot produce a structurally invalid answer. It can still pick the wrong option. If the correct answer is not among the options you provide, it will still pick one of the ones you gave it. Zero hallucination means zero out-of-schema output, not zero errors. **What is the context limit for each model?** Jev accepts up to 64,000 tokens per request, with 32,000 tokens as the limit for the state itself. For Kev, the 4B and larger models support an 8,192 token context window. The 0.8B model was trained on states of up to 384 tokens, so it is better suited for short inputs. **Is my data safe if I use Jev?** TypeSafe has stated publicly that it does not train its models on customer API requests. However, Jev is a closed hosted service, so your state and questions do leave your infrastructure. If your data is sensitive or subject to compliance requirements, Kev running locally is the appropriate choice since nothing leaves your servers. **Which model should a beginner start with?** Start with Kev-4B locally. It requires no API key, no waitlist, costs nothing to experiment with, and the accuracy on new sources is close to what Jev delivers. Once you have a use case that works with Kev-4B, you can evaluate whether Jev’s hosted performance justifies switching. **TypeSafe AI and Jev** Deußer et al., “Evaluating and Benchmarking the System One Model Jev,” arXiv preprint, September 2026. [https://arxiv.org/pdf/2609.37647](https://arxiv.org/pdf/2609.37647) “Jev in the Wild: A Data-Driven Analysis of the Jev Model’s Functionality, Applications and Ecosystem,” arXiv preprint, September 2026. [https://arxiv.org/pdf/2609.30216](https://arxiv.org/pdf/2609.30216) “When the Right Answer Is Missing: An Arithmetic-Dependent Rejection Bottleneck in Jev,” arXiv preprint, September 2026. [https://arxiv.org/pdf/2609.39496](https://arxiv.org/pdf/2609.39496) Connor Frank, “An Independent Evaluation of TypeSafe’s Jev,” vals.ai, October 2026. [https://vals.ai/blogs/independent-evaluation-of-jev](https://vals.ai/blogs/independent-evaluation-of-jev) TypeSafe AI launch announcement, vktr.com, September 16, 2026. [https://www.vktr.com/ai-platforms/chatgpt-cocreator-launches-typesafe-ai-with-jev](https://www.vktr.com/ai-platforms/chatgpt-cocreator-launches-typesafe-ai-with-jev) TypeSafe AI raises $870M, newsbytesapp.com, October 10, 2026. [https://www.newsbytesapp.com/news/business/creator-of-non-text-jev-ai-model-raises-870m/story](https://www.newsbytesapp.com/news/business/creator-of-non-text-jev-ai-model-raises-870m/story) **Kev** Jared Palmer, Kev repository and model cards, GitHub, September 2026. [https://github.com/jaredpalmer/kev](https://github.com/jaredpalmer/kev) Kev-4B model card, Hugging Face. [https://huggingface.co/jaredpalmer/kev-4b](https://huggingface.co/jaredpalmer/kev-4b) “Your AI agent is burning tokens on choices that don’t need words,” The New Stack, September 2026. [https://thenewstack.io/kev-skips-text-generation](https://thenewstack.io/kev-skips-text-generation) **Architecture and training** “RLCD: Reinforcement Learning for Calibrated Decisions,” Towards AI, September 2026. [https://pub.towardsai.net/rlcd-reinforcement-learning-for-calibrated-decisions-e528daf3591d](https://pub.towardsai.net/rlcd-reinforcement-learning-for-calibrated-decisions-e528daf3591d) “How Does Jev Work? A Technical Reconstruction from 5 Public Clues,” Towards AI, September 2026. [https://pub.towardsai.net/how-does-jev-work-a-technical-reconstruction-from-5-public-clues-c32b29dcb3d5](https://pub.towardsai.net/how-does-jev-work-a-technical-reconstruction-from-5-public-clues-c32b29dcb3d5) [Jev vs Kev: The Two Decision Models Changing How AI Agents Make Choices](https://pub.towardsai.net/jev-vs-kev-the-two-decision-models-changing-how-ai-agents-make-choices-bff61bea6224) 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.