Jev and the Rise of Decision Models: What Changes When AI Returns Probabilities Instead of Text

Many AI pipelines still use generative language models for tasks that do not require generating language. A router needs a label. A policy check needs a yes or no. A triage system needs a severity level. Yet these steps are often implemented through a text-generation interface, followed by parsing, validation, and application logic.

Jev, released on September 15, 2026 by TypeSafe AI [1], is designed for exactly these steps. Instead of producing a natural-language answer that software must interpret, it returns typed decisions with probabilities. TypeSafe brands it a "System One" model [3], a reference to Daniel Kahneman's distinction between fast, intuitive thinking and slow, deliberate thinking. The term is TypeSafe's framing, not an established scientific category.

Who Built It

TypeSafe AI was founded by Diogo Almeida, Erik Gafni, and Sasha Sheng [1]. Almeida spent approximately four years at OpenAI working on improving ChatGPT's responses before leaving in 2024 to start TypeSafe [12]. His diagnosis of the problem with today's models is blunt: "We've been optimizing for humans and we're super human at pleasing humans" [12]. The company emerged from stealth with approximately $40 million in seed funding led by DCVC [1], at a reported $200 million valuation [12].

Investor appetite moved fast. On October 9, 2026, Bloomberg reported that TypeSafe raised approximately $870 million in a round led by Andreessen Horowitz at a $7.5 billion valuation [8]. At the time of writing, the figures come from Bloomberg's reporting rather than a TypeSafe announcement [9].

What Is New in the Approach

TypeSafe describes three differences from a conventional LLM [3]. These are the company's design claims. Where independent evidence exists, it is covered later in this article.

Typed decisions instead of strings. An LLM returns a string that software must parse and validate. Jev returns values whose possible outputs are defined in advance by the caller [3]. A choice question can only return one of the options you supplied. TypeSafe goes further and states that the model "never makes type errors" [3]. That is a guarantee about the shape of the output, not about whether the decision is right.

Parallel evaluation. Where an LLM generates one token at a time, TypeSafe says Jev produces all outputs of a request in parallel [3]. Multiple questions about the same input are evaluated in isolation from each other [20], so adding questions barely changes latency.

Calibration as the training target. Jev is trained with what TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), which the company contrasts with RLHF and describes as optimizing for "epistemically honest probabilities" [3]. The goal is that higher confidence corresponds to higher accuracy [3]. This is a design objective. Whether it holds on a given workload is an empirical question, addressed in the calibration section below.

The architecture has not been published. TypeSafe's public GitHub organization contains SDKs, agent skills, an LLM adapter, and forks of projects such as vLLM and LLaDA, but no model weights or Jev repository [10].

The Three Question Types

Two details matter for anyone building on these outputs. First, a score value is not a probability. It is a position on your level scale, calculated as a probability-weighted mean of the level numbers, so a three-level scale runs from 0 to 2 [5]. Second, confidence is computed from how concentrated the probability distribution is: a single peak means high confidence, a flat spread means low confidence [5]. TypeSafe's documentation does not define it as the probability that the answer is correct.

How to Use It

A request has two parts: a state (the text or data describing the situation) and a map of questions keyed by IDs you choose. The endpoint is POST https://api.typesafe.ai/v1/systemone. In the wire format, question types are lowercase (choice, score, noul). The capitalized names are SDK classes [4]. Official SDKs exist for Python and JavaScript/TypeScript [4][10].

Jev launched in early access and opened for general availability in September 2026, with a $5 starting credit for new users [13].

The Tokenomics Problem It Solves

TypeSafe's published pricing is $0.042 per million input tokens, with output tokens listed as free [3]. The company puts frontier LLM input pricing at roughly $0.20 to $10 per million tokens, with output around five times the input rate, and notes that it cannot prove its own pricing is not subsidized [3]. Prices were checked in October 2026 and are likely to change.

Price per token is only part of the picture. The more useful comparison is what each approach returns for the same task, and what the surrounding pipeline has to do with that result.

Same Request, Two Approaches

Take a common automated step: an incoming support ticket must be assigned to a team, rated for severity, and flagged if it describes a full outage.

Customer reports production cluster unreachable since 02:00. 400 users affected. Last change was a firewall rule update yesterday.

A fair LLM baseline uses structured outputs. Modern LLM APIs can constrain the response to a JSON Schema. OpenAI states that Structured Outputs "ensures the model will always generate responses that adhere to your supplied JSON Schema," which rules out invalid enum values [19]. A well-built LLM pipeline therefore defines the allowed values in a schema:

{
  "type": "object",
  "properties": {
    "team":      { "type": "string", "enum": ["network", "compute", "billing"] },
    "severity":  { "type": "string", "enum": ["low", "medium", "high", "critical"] },
    "is_outage": { "type": "boolean" }
  },
  "required": ["team", "severity", "is_outage"],
  "additionalProperties": false
}

With Structured Outputs enabled, the API constrains successful model responses to the supplied schema, including the allowed enum values, for example {"team": "network", "severity": "critical", "is_outage": true}. Applications must still handle refusals, incomplete responses, and API errors [19]. What a successful response does not contain is any measure of how sure the model is. "critical" chosen with near certainty and "critical" chosen as a coin flip between "high" and "critical" look identical to the pipeline. (Without structured outputs, for example with plain prompting or JSON mode, LLMs can also return prose around the JSON or labels outside the allowed set, which is a common failure in older pipelines.)

The same step with Jev follows the request format in TypeSafe's quickstart [4]:

{
  "model": "jev-latest",
  "state": "Customer reports production cluster unreachable since 02:00. 400 users affected. Last change was a firewall rule update yesterday.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should own this ticket?",
      "criteria": {
        "network": "Connectivity, DNS, firewall",
        "compute": "Hosts, VMs, capacity",
        "billing": "Invoices, licensing"
      }
    },
    "severity": {
      "type": "score",
      "instructions": "How severe is the business impact?",
      "criteria": [
        "Low: cosmetic or single user, workaround exists",
        "Medium: degraded service for some users",
        "High: major feature down for many users",
        "Critical: production outage, no workaround"
      ]
    },
    "is_outage": {
      "type": "noul",
      "instructions": "This ticket describes a full service outage."
    }
  }
}

The response uses the field structure documented by TypeSafe [4][5]. The values below are illustrative, not an observed API response:

{
  "model": "jev-1.13.0",
  "answers": {
    "team": {
      "type": "choice", "choice": "network", "confidence": 0.82,
      "probabilities": { "network": 0.91, "compute": 0.08, "billing": 0.01 }
    },
    "severity": {
      "type": "score", "score": 2.85, "confidence": 0.71,
      "probabilities": { "0": 0.0, "1": 0.02, "2": 0.11, "3": 0.87 }
    },
    "is_outage": { "type": "noul", "noul": 0.96 }
  }
}

The severity score of 2.85 sits on the 0 to 3 scale defined by the four criteria, close to "Critical". It is the probability-weighted mean of the level numbers (0.02 x 1 + 0.11 x 2 + 0.87 x 3), not a 95% probability. The confidence values shown are placeholders: TypeSafe computes confidence from the spread of the whole distribution and does not publish how [5], so it should not be read as, or derived from, the probability of the top option.

The meaningful difference is not valid JSON. Both approaches can deliver that. It is that Jev returns a probability distribution with every decision through a dedicated interface, which a pipeline can use to decide what to automate and what to escalate.

Illustrative Inference Cost

Kiseki Labs compared list-price costs for classifying one million items of approximately 1,100 tokens each (roughly an 800-word article), with a one-word answer [11]:

This is an illustrative inference-cost estimate, not a comparison of complete systems at equal performance. It uses the source's token assumption and list prices at the time of testing, and the source notes that real LLM bills tend to run higher because production prompts carry instructions and examples, and reasoning models bill for thinking tokens [11]. It does not include retries, fallback calls to a larger model, human review of low-confidence cases, or follow-up generation calls. A cheaper decision that triggers more escalations can cost more overall, so the metric that matters is cost per correct decision, measured on your own workload.

What Happens After Jev Decides

Jev does not call the next model or rewrite the user's prompt. It returns a decision to your application, and your application (or a framework middleware) makes the next call.

In LangChain's ModelRouterMiddleware, you define candidate models and a description of when each should be used. Jev chooses one based on the latest user message, the chosen model handles the run, and Jev's probabilities and confidence remain available in the agent state [6]. The example below is reproduced from LangChain's published guide, including its model identifiers:

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(model="openai:luna",
                            criteria="Direct lookups, extraction, and localized changes."),
        "powerful": ModelChoice(model="openai:sol",
                                criteria="Architecture and high-stakes decisions."),
    },
    instructions="Choose the least costly model that can complete the task.",
)

The downstream model receives the original request plus your existing system prompt. A design pattern I would recommend is to pass Jev's structured results along as fields in a fixed, code-generated template:

Team: network | Severity: Critical (level 3 on a 0 to 3 scale) | Outage probability: 0.96
Task: Draft an incident summary and the first three troubleshooting steps.
Ticket: Customer reports production cluster unreachable since 02:00...

The expensive model starts from a classified, consistent context, and the template is produced by code rather than written by hand for each case.

How It Can Reduce Errors in Automated Pipelines

The benefits are most relevant in scheduled jobs and API-driven workflows, where no human reads the output before the next step runs.

Less dependence on prompt wording. The output format lives in the question schema, not in the prompt text. In Kiseki Labs' test on 540 news articles, Jev reached 90.9% agreement with the reference using only a bare one-line question, against 92.6% with a full policy [11]. That suggests lower sensitivity to how carefully instructions are written, on that dataset.

Uncertainty as a routing signal. In the same test, answers with confidence of 0.9 or higher covered 68.5% of the 540 articles, and those answers agreed with the reference labels 99.7% of the time [11]. The reference labels came from Claude Opus 5 rather than human annotators, so this measures agreement with a frontier model, on one dataset. The pattern, not the exact number, is what transfers: high-confidence answers can be automated, and the rest can be routed to review.

Thresholds set by error cost. For noul answers, TypeSafe's documentation recommends choosing the threshold by the cost of being wrong: raise it when a false yes is expensive (for example, issuing a refund), lower it when a missed yes is expensive (for example, a safety issue), and send the middle band to a person [5].

Guardrails before actions. LangChain's AutoModeMiddleware uses Jev to check tool calls, such as shell commands, and can block a risky call before the tool runs [6]. Vercel replaced an OpenAI model with Jev for a command-safety classifier and reported results 5 to 18 times faster with greater accuracy [2].

Jev does not fix a poorly defined task. If options overlap or criteria are vague, the decision will reflect that.

A Note on Calibration

Calibration is an empirical property of a model on a given distribution of inputs, not a guarantee for every decision. Independent evidence so far supports Jev's calibration claims in some areas and qualifies them in others.

Deußer, Sparrenberg, and Sifa evaluated jev-1.13.0 zero-shot on 37 datasets using 346,009 requests [17]. Jev beat a Qwen baseline on 27 of 37 datasets and a Gemma baseline on all 37. Choice probabilities were well calibrated and supported selective prediction. Binary probabilities ranked cases well but sat poorly relative to a fixed 0.5 threshold: tuning the threshold on training data raised micro-F1 on one legal-clause dataset from 0.50 to 0.75. All models, including Jev, degraded on low-resource languages, fine-grained or noisy labels, and rubric-based quality judgments [17].

The practical rule: validate confidence thresholds per task on representative, labeled data from your own workload, and monitor calibration as inputs change.

Where It Fits in an AI Architecture

Jev does not replace LLMs. It targets the structured decision points that LLMs are often overqualified for, such as decision rules, routing, scoring, and guardrails [3][6]. An analysis of 2,170 public GitHub projects in the first week after launch found that 81% used choice, 72.2% used noul, and 45.4% used score [7].

What It Takes to Self-Host Jev-Class Models

This is the question enterprise teams ask first, especially in regulated or air-gapped environments.

Jev itself is not currently available for self-hosting. TypeSafe offers Jev through a hosted API and has not publicly released its model weights, parameter count, or hardware requirements, or announced an on-premises deployment option [10][20]. Any figure describing Jev's own hardware footprint is speculation.

What has changed is the evidence that open models can do this job.

Open Models Can Already Make Jev-Style Decisions

A preprint published on October 12, 2026 by Jonathan Geuter, Andrew Cheng, and David Alvarez-Melis, "Releasing the Inner Jev," tested whether existing open language models can produce Jev-style decisions [18]. The method is simple: present the options as lettered choices, run one forward pass, and read the probabilities of the answer letters directly from the model's output logits, with temperature scaling for calibration. No text is generated.

Key results reported by the authors [18]:

• Zero-shot: Gemma 4 31B scored 79.6 Capability on the authors' OpenDecisions validation set, against 80.1 for Jev. Qwen3.6-27B scored 79.0.
• After a short fine-tune: LoRA adapters plus a decision head, trained for 400 steps, raised Gemma 4 31B to 84.4 on OpenDecisions. On the official JevBench leaderboard (v1.7, 1,500 items), the trained model scored 81.5 against 77.1 for Jev.
• Training run: about 78 minutes on four H200 GPUs, roughly five GPU-hours, for the 31B model. This covers the training run only, not the cost of development, evaluation, deployment, maintenance, or serving the model over time.
• Held-out public datasets: averaged over seven public decision datasets, the trained 31B model scored 89.0 accuracy against 88.0 for Jev.
• Where Jev still leads: on six knowledge-heavy multiple-choice benchmarks, Jev scored 92.9 macro accuracy against 88.8 for the trained 31B model.

The authors released the trained models as the Jeff-1.0 family, along with serving code and the OpenDecisions dataset [18].

These results need context. The paper is a preprint. OpenDecisions was built by the same authors, is 78% English, and many items were generated by language models. One of the teacher models is related to a model used in evaluation labeling, which the authors flag as a possible bias. Their implementation supports at most 16 options, against 255 for Jev [5][18]. The finding is that open models can match or exceed Jev on these benchmarks, not that they are equivalent in production latency, operations, or reliability.

What JevBench Measures, and What It Does Not

The name can mislead, so it is worth being precise. JevBench is not a test of general intelligence, and Jev is not "more than a model" because a benchmark carries its name. JevBench is an independent community benchmark, maintained by Benchmark Heaven and not affiliated with TypeSafe [15], that measures one narrow category: typed decisions. It scores models on decision accuracy corrected for chance, calibration of the reported probabilities, latency, and cost per 1,000 decisions [15].

It is named after Jev because Jev defined the category, and Jev serves as the hosted reference point [14]. General-purpose chat models such as GPT, Claude, or Gemini are not ranked on it, and it says nothing about writing, coding, or reasoning ability.

It is also a moving target. Jev scored 74.4 under JevBench v1.3 and 63.3 under v1.4, a drop caused by a new scoring formula and a sealed test set rather than any change to the model [16]. The maintainers advise against comparing scores across method versions [15]. Leaderboard figures in this article were checked in mid-October 2026 and will change as the benchmark evolves.

Comparison on One Consistent Evaluation

The table uses a single evaluation, OpenDecisions from the "Releasing the Inner Jev" preprint, where all systems were scored on the same questions [18]. Memory figures are my own weight-only estimates (parameters multiplied by bytes per parameter), not measured values.

Weight size is the minimum to load a model, not what it needs in production. Actual GPU memory also depends on the inference runtime, context length, batch size, and concurrency, and quantization can affect accuracy and calibration. A decision workload has one advantage here: it needs a single forward pass and no long generated output, so memory for generation is small compared with a chat workload of the same model size. Sizing for production should be done by load-testing the chosen model at the expected request rate and measuring p50 and p95 latency.

For infrastructure teams, the benchmark results suggest that roughly 30B-class open models can deliver decision quality in Jev's range on these benchmarks, inside your own environment. Whether a given model fits on a single data-center GPU or a smaller quantized deployment is a sizing question that only load tests on real traffic can answer. The benchmark results do not establish it. The trade-off moves from "hosted Jev or nothing" to a classic build-versus-buy decision: hosted simplicity and low per-call price against data residency, control, and GPU capacity you operate yourself.

The Jevons Paradox Bet

The name is a deliberate nod to the Jevons Paradox [1]. William Stanley Jevons observed in 1865 that more efficient coal use increased total coal consumption rather than reducing it. TypeSafe is betting on the same dynamic: if machine decisions become dramatically cheaper, AI spending will not shrink. Many decision points that are too expensive to automate today will become viable.

What I Would Evaluate

For teams running AI in production and watching token bills grow, I would approach Jev-style decision models in four steps:

1. Inventory decision calls. Identify every LLM call in your pipelines that returns a label, a yes/no, or a score. These are the candidates.
2. Build a labeled test set. Use real inputs with ground-truth labels, not labels from another model, and include the hard and ambiguous cases.
3. Shadow test and measure the right metrics. Run the decision model alongside the current one and compare accuracy, calibration and coverage at each confidence threshold, p50 and p95 latency under load, stability across input changes, and total cost per correct decision including fallback and review.
4. Decide on data residency up front. If data cannot leave your environment, hosted Jev is not an option today. Evaluate an open-weight model with a letter-readout or fine-tuned decision head on your own GPU capacity, and measure the gap against the cost and compliance benefit.

The point is not to choose a model by price per token. It is to choose the decision layer that lets an automated process run reliably at the right cost, and to call the expensive model only when it is needed.

Related Reading

• Why the Same Text Costs More on GPT Than on Gemini: How AI Tokenizers Actually Work
• VMware AI Factory: GPU Pooling, AI Tokenomics, and What VCF Customers Should Do Now
• The Agentic Shift: How AI Agents Are Changing IT Operations and Management

References

[1] TypeSafe AI Emerges From Stealth With $40M in Funding With New Model for Composable AI↗ - TypeSafe AI press release via Business Wire, September 15, 2026

[2] A new kind of AI model from a ChatGPT inventor is thrilling developers↗ - TechCrunch

[3] Introducing System One Models and Jev↗ - TypeSafe AI blog

[4] Quick start↗ - TypeSafe documentation

[5] Primitives: choice, score, noul↗ - TypeSafe documentation

[6] What Is Jev? A Guide to TypeSafe AI's System One Model↗ - LangChain

[7] Jev in the Wild: A Data-Driven Analysis of the Jev Model's Functionality, Applications and Ecosystem↗ - arXiv preprint

[8] Andreessen Horowitz Backs Jev Maker at $7.5 Billion Value↗ - Bloomberg, October 9, 2026

[9] Bloomberg reports TypeSafe raised $870M at a $7.5B valuation↗ - RuntimeWire

[10] typesafe-ai↗ - TypeSafe AI GitHub organization

[11] LLM Classification Cost vs Accuracy: TypeSafe's Jev Tested↗ - Kiseki Labs

[12] This $200 Million Startup Wants To Fix AI's Overconfidence Problem↗ - Forbes

[13] TypeSafe Opens Jev for General Availability↗ - Techstrong.ai

[14] JevBench: AI decision model benchmark and leaderboard↗ - Benchmark Heaven

[15] Decision model benchmark methodology↗ - Benchmark Heaven

[16] How do you benchmark a System One model? What JevBench scores, and what calibration says it cannot↗ - Stackness

[17] Evaluating and Benchmarking the System One Model Jev↗ - Deußer, Sparrenberg, Sifa, arXiv preprint, September 2026

[18] Releasing the Inner Jev: A Simple Recipe for Open Decision Models↗ - Geuter, Cheng, Alvarez-Melis, arXiv preprint, October 12, 2026

[19] Structured Outputs↗ - OpenAI API documentation

[20] TypeSafe AI Releases Jev: A System One Model That Returns Typed, Calibrated Decisions Instead of Text↗ - MarkTechPost

Disclosure: The author is an employee of Broadcom. This article represents the author's technical analysis and does not represent Broadcom's official position.