A different kind of intelligence
Building an AI agent often feels like trying to run a marathon one expensive sprint at a time. The agent loop—where a model observes, thinks, and acts—is powerful, but every "thought" is a full call to a large language model (LLM). This makes the process slow and costly, an accumulating tax on every decision the agent makes. A complex task requiring dozens of steps can see costs spiral and users stare at a loading spinner. On September 15, 2026, a startup named TypeSafe AI emerged from stealth to propose a different approach with its first model, Jev.
Jev is not another LLM competing to write better poetry. It doesn't write anything at all. Instead, it's the first of what TypeSafe calls "System One models," built for a single purpose: making fast, structured decisions. You provide the model with a block of information, called a "state," and a list of predefined questions about it. Jev evaluates all these questions in parallel and returns clean, typed answers—like a multiple-choice selection, a score, or a simple yes/no—along with a confidence probability for each. This design makes it fundamentally different from a text-generating LLM, enabling a new architecture for automation: use expensive LLMs for creative reasoning and cheap System One models for the thousands of small decisions that connect it all together.

What is a System One Model?
"System One model" is a category name coined by TypeSafe AI, borrowed from psychologist Daniel Kahneman's work on human cognition. In his book Thinking, Fast and Slow, Kahneman describes two modes of thought: System 1 is fast, intuitive, and automatic; System 2 is slow, deliberate, and analytical.
Existing LLMs, with their step-by-step reasoning and sequential text generation, operate like System 2. They can analyze complex problems, write detailed plans, and generate novel content, but it takes time and significant computational energy.
TypeSafe positions Jev as the counterpart: a model built for System 1 tasks. It's designed to classify, route, score, and make binary choices instantly and efficiently. According to TypeSafe founder Diogo Almeida, this new class of model is defined by a new architecture, a parallel sampler, and a new training method.
LLM vs. Jev: The Core Differences
To understand where Jev fits, it's useful to contrast its core design with that of a traditional LLM.
Existing LLMs (System 2) | System One + Jev (System 1) | |
|---|---|---|
Primary Task | Open-ended generation and reasoning | Fast, constrained decision-making |
Output Type | Unstructured text (strings) generated token-by-token | Structured, typed answers (JSON objects) with probabilities |
Sampling | Sequential: predicts the next token based on previous ones | Parallel: evaluates all questions at once in a single pass |
Training Method | RLHF (Human Feedback) or RLVR (Verifiable Rewards) | RLCD (Calibrated Decisions) |
Hallucination Risk | Inherent; can generate factually incorrect or nonsensical text | Impossible by design; outputs are constrained to a predefined schema |
Let's break down the three most important distinctions: output type, sampling method, and training objective.
Output: Strings vs. Structured Decisions
An LLM's fundamental output is a string of text, generated one token (a word or part of a word) at a time. This is incredibly flexible—the model can write code, a chat response, a JSON object, or a refusal. But this flexibility comes with a cost. To use an LLM's output in software, you must first parse and validate it. A model asked for JSON might return a malformed string, a comment explaining why it can't provide the JSON, or a completely different answer.
Jev, by contrast, never generates free-form text. Its output is always a structured object that conforms to the schema of the questions you asked. The possible answers are defined in advance. This means there is no parsing step and, according to TypeSafe, no possibility of a type error or a traditional hallucination. The model can be wrong about its answer, but it cannot produce an answer that is structurally invalid.
Sampling: Sequential vs. Parallel
The token-by-token generation process of an LLM is inherently sequential. To produce an answer, the model must perform a forward pass for every single token, making it latency-bound.
Jev uses what TypeSafe calls a parallel sampler. When you send it a state and a list of questions, it evaluates all of them at once. This architectural choice is a primary driver of its reported speed. Instead of a series of computations to build a response, it performs one larger computation to resolve all decisions simultaneously.
Training: RLHF vs. RLCD
Most modern LLMs are fine-tuned using methods like Reinforcement Learning with Human Feedback (RLHF) or Reinforcement Learning with Verifiable Rewards (RLVR). These methods train the model to produce outputs that human raters prefer or that can be programmatically verified as correct. The goal is to create helpful and harmless conversational assistants.
Jev is trained using a different method TypeSafe developed called Reinforcement Learning for Calibrated Decisions (RLCD). According to the company, RLCD optimizes the model to produce "epistemically honest probabilities." This means the confidence score attached to a decision should accurately reflect the model's true uncertainty. A well-calibrated model that reports 80% confidence in an answer should, over many predictions, be correct about 80% of the time. For developers, this is critical. Reliable confidence scores allow you to build robust business logic, setting different thresholds for when to act automatically, when to ask for clarification, and when to escalate to a human.
Jev by the Numbers: Performance, Price, and Caveats
TypeSafe AI launched with a set of extraordinary claims about Jev's efficiency. These numbers are the cornerstone of its value proposition for agent builders.
Speed: Jev is reportedly 40-200x faster than comparable LLMs on classification tasks. This speed comes from its parallel architecture and focus on decisions over generation.
Cost: The company claims Jev is over 400x cheaper. Pricing was announced at $0.042 per million input tokens, with output tokens being completely free. This pricing model is significant. With LLMs, output tokens are often more expensive than input tokens, penalizing verbose models. Jev's free output encourages asking many questions at once.
Accuracy: On TypeSafe's internal 4-workflow benchmark, Jev is said to achieve around 68% accuracy. The company states this is close to the performance of mid-tier LLMs like GPT-5.6 Terra on the same tasks.
It is crucial to put these numbers in context. As of its launch in September 2026, all published benchmarks and performance figures for Jev come directly from TypeSafe AI. The sources for this article do not contain any independent, third-party evaluations of its speed, cost, or accuracy. While the claims are compelling, they represent the vendor's best-case scenario and await confirmation from the wider community.
The Jev Harness: A Worked Example with LangChain
The true test of a new model is how it fits into a real-world stack. Jev is not designed to replace LLMs, but to complement them. The LangChain team published a guide showing how to build a "harness" that uses both model types for what they do best.
The core idea is to create a multi-layered system: Jev handles the high-volume, low-latency decisions, while a powerful LLM is reserved for complex reasoning and generation.
The Architecture: LLM for Reasoning, Jev for Decisions
Imagine you are building an advanced customer support automation system. You have access to a frontier model like OpenAI's GPT-6 Astra for complex problem-solving, but calling it for every incoming message would be prohibitively expensive.
Here, Jev acts as an intelligent, high-speed switchboard.
The LLM (System 2) is the expert on call. It's used for tasks like understanding a long, nuanced customer history, drafting a personalized, empathetic reply, or creating a multi-step plan to resolve a unique issue.
Jev (System 1) is the front desk and the safety supervisor. It handles the constant flow of small decisions: Is this message urgent? What category does this ticket belong to? Should this automated action be allowed?
Let's walk through two practical use cases from the LangChain guide.
Use Case 1: Routing by Complexity
A user sends a message to your support bot: "My bill is wrong." This could be a simple request for a link to the billing page or the start of a complex fraud investigation. Using the expensive LLM for the simple case is wasteful.
With a Jev harness, the workflow looks like this:
State and Questions: The user's message becomes the
state. You send this state to Jev with aChoicequestion.{ "model": "jev-latest", "state": { "user_message": "My bill is wrong, I think I was overcharged last month for my subscription." }, "questions": { "intent": { "type": "choice", "question": "What is the user's likely intent?", "choices": ["simple_faq", "complex_billing_inquiry", "account_cancellation"] } } }Jev's Decision: Jev processes this in milliseconds and returns a probabilistic answer.
{ "results": { "intent": { "type": "choice", "answer": "complex_billing_inquiry", "confidence": 0.85, "probabilities": { "simple_faq": 0.10, "complex_billing_inquiry": 0.85, "account_cancellation": 0.05 } } } }Intelligent Routing: Your application code reads this result. Because
complex_billing_inquiryhas high confidence, the system routes the query, along with the user's history, to the powerful LLM for detailed analysis. Ifsimple_faqhad been the top choice, it could have replied instantly with a link to a help document.
Use Case 2: Auto-Blocking Risky Tool Calls
A powerful feature of modern agents is "tool calling," where the LLM can use external functions like send_email or update_database. This is also where agents can do the most damage.
The LangChain guide describes using Jev as a safety guardrail. The TypeSafeClassifier module can intercept a tool call before it executes.
LLM Proposes Action: In a long reasoning process, your agent's LLM decides it needs to reset a user's password and prepares the tool call:
reset_user_password(email="customer@example.com").Jev Intercepts: Before this function is executed, the harness passes the proposed call to Jev. The state is the tool call itself, and the question is a simple
yes_no.{ "model": "jev-latest", "state": { "tool_call": "api.reset_user_password(email='customer@example.com')" }, "questions": { "is_destructive": { "type": "yes_no", "question": "Is this a high-risk or irreversible action that should require confirmation?" } } }Block or Proceed: Jev returns
{ "answer": "yes", "confidence": 0.98 }. Based on this high-confidence result, the harness blocks the execution and flags the action for human review, preventing a potentially catastrophic mistake. This check takes a few milliseconds and costs a fraction of a cent, making it feasible to inspect every single tool call.
When to Use Jev (and When to Stick with an LLM)
Jev and LLMs are not competitors; they are complementary tools designed for different jobs. Understanding the trade-offs is key to building effective and efficient AI systems.
Jev is the right tool when:
Your task is a decision. You need to classify, score, route, or validate something.
The possible outcomes are known. The set of choices is finite and can be defined in a schema.
Speed and cost are paramount. You need to handle a high volume of requests with minimal latency and budget.
Output reliability is non-negotiable. You need well-calibrated confidence scores and cannot tolerate structural errors or hallucinations.
An LLM is the right tool when:
Your task is generation. You need to write an email, summarize a document, generate code, or have a conversation.
The problem requires complex, multi-step reasoning. The model needs to "think" through a problem that doesn't have a clear, predefined structure.
The output space is infinite. You can't predict all possible valid answers ahead of time.
A human-like, conversational tone is required.
The emergence of System One models like Jev suggests a future for AI architecture that is more specialized and efficient. Instead of relying on one monolithic model to do everything, developers can assemble a "virtual workforce" of specialized models—fast-twitch decision-makers working alongside deep, creative thinkers—to build faster, cheaper, and safer automated systems.

