ChatGPT Co-Inventor Launches a New AI Model: System One Generates No Text and Focuses on Decisions

What Are “System One Models” and Jev?

Diogo Almeida, who co-invented ChatGPT and reinforcement learning from human feedback (RLHF) at OpenAI, has introduced an entirely different model category—“System One” models—and released Jev, the first public model under this paradigm.

Mainstream large language models excel at conversation, but struggle to run automation reliably inside code. Jev's core trade-off is abandoning token-by-token free text generation to focus strictly on outputting categories, scores, probabilities, and confidence levels within predefined structures. It is not another model meant for chatting or writing articles, but a fast decision-making component designed to be embedded directly into program control flow.

"System One" originates from Daniel Kahneman's Thinking, Fast and Slow: System 1 represents fast, intuitive judgments, contrasting with System 2, which requires prolonged deliberation. TypeSafe uses this name to emphasize that it aims to solve the vast number of classification, scoring, and routing problems that demand low-latency responses. The name Jev comes from the economic concept of the "Jevons paradox": as the steam engine became more efficient, total coal consumption actually increased. The product thesis it reflects is that when the cost and latency of an intelligent decision drop by orders of magnitude, software demand for intelligent judgments will surge accordingly.

Why did this model emerge? Because the free text generation mechanism designed for human-computer dialogue is in stark misalignment with the low latency, fixed interfaces, and deterministic branching demanded by automated pipelines.

Over the past few years, LLMs have dazzled in open-ended conversations and long-form writing, but progress in deploying them within enterprise backend code requiring deterministic logic has often fallen short of expectations. Mainstream LLMs rely primarily on RLHF alignment, with the core goal of outputting natural language that matches human evaluators' preferences. To accommodate conversation, models must possess the ability to freely generate arbitrary strings. Once placed into code pipelines, however, this mechanism exposes three engineering fatal flaws:

Prohibitively high response latency: Traditional LLMs use autoregressive token-by-token sequential generation. Frontier benchmarks cited by TypeSafe show end-to-end response times typically ranging between 3 seconds and 329 seconds. While this delay may be acceptable for a human user sitting in front of a screen, inside programs requiring multi-stage cascaded calls, waits of tens of seconds quickly accumulate to the point of being unusable. TypeSafe summarizes its value proposition as "100x faster"; its stated end-to-end latency range for Jev is 70ms to 500ms, with the actual multiple depending on the comparison model and specific task.

Extremely brittle type systems: LLMs natively output strings; even when a prompt requests JSON, downstream code must still deserialize and validate it. Once extraneous prefixes, corrupted formatting, or unexpected refusals appear, a single parsing exception at the foundational layer will crash and interrupt the entire business invocation chain.

Lack of directly dependable confidence estimates: Chat models aligned through preference tuning often exhibit overconfidence and contradictory self-assessments. If a system cannot discern when a model is fully certain versus blindly guessing, downstream programs cannot safely establish automated pass-through thresholds or human-in-the-loop fallback mechanisms.

In human cognition, System 1 does not inherently imply reliability; rapid intuitions can just as easily be flawed. TypeSafe's technical claim is that once a model is stripped of free text generation to focus on type safety and probability calibration, it can at least eliminate formatting errors and parsing exceptions at the interface level. Whether the semantic judgment itself is correct remains an entirely separate layer of concern.

How Does It Differ from Existing Models?

Jev is not a fine-tuned, scaled-down version of existing large models, but an independent model stack rebuilt entirely from its decoding mechanism to its training paradigm.

Traditional LLM Architecture:
[Unstructured Input] ──> [Autoregressive Decoder (Sequential Token-by-Token Generation)] ──> [Free String (Requires External Validation; Parsing & Hallucination Risks)]

System One (Jev) Architecture:
[Unstructured State] ──> [Parallel Sampler (Single-Forward Hardware Acceleration)] ──> [Predefined Strongly-Typed Probabilities (Zero Type Errors by Construction, Calibrated Confidence)]

Jev's most critical architectural trade-off lies in completely abandoning free text generation. Traditional large models employ an autoregressive mechanism where every newly generated token must depend on the preceding token, making computation highly serialized across the time dimension. In contrast, Jev requires the calling side to predefine the output structure prior to initiating a query; during forward propagation, the model computes numerical outputs across all dimensions in a single pass via a hardware-aware Parallel Sampler. TypeSafe claims this compresses end-to-end response times to 70ms to 500ms, delivering what official statements describe as a tens- to hundreds-fold speedup compared to conventional large models.

This architectural redesign simultaneously eliminates structural type errors at the interface layer. While a traditional large model's output space spans the entire natural language vocabulary, Jev's output space is fully constrained by a predefined Schema prior to inference. The output layer maps directly to numerical probabilities over discrete categories or scales, so structural and type conformity is guaranteed by the interface itself. It should be noted, however, that this only guarantees the output format adheres to the predefined structure; it does not prove that the model's semantic judgment is necessarily correct.

In terms of training algorithms, industry currently follows two primary paths: one is RLHF, which optimizes for human reading preferences and tends to make models overconfident in their effort to please humans; the other is reinforcement learning with verifiable rewards (RLVR), which relies on objectives that can be verified at low cost by code unit tests (such as mathematical proofs or code compilation), though this often leaves models lacking generalization in real-world business scenarios without deterministic test cases.

To address this, TypeSafe proposed "Reinforcement Learning for Calibrated Decisions" (RLCD). Rather than evaluating whether written expressions are vivid, RLCD focuses its optimization objective on "calibrated decisions." Officially, its goal is to ensure that "higher confidence means higher accuracy," outputting probability distributions that exhibit epistemological honesty. However, official materials do not disclose specific training implementation details or independent calibration curves; according to its design vision, when confronted with ambiguous or borderline edge cases, the model outputs flatter, more dispersed probability distributions, enabling downstream engineering code to set thresholds for branching and fallback interception.

TypeSafe claims Jev is 100x faster, 100x cheaper than traditional large models, and offers free output tokens. According to its published early access pricing, Jev costs $0.042 per million input tokens (equivalent to $42 per billion tokens), and outputs are indeed labeled as free; however, the company explicitly acknowledges that whether this pricing is sustainable over the long term remains to be proven, and the 100x cost-reduction claim varied by task in official testing across four workflows (in comparisons with similar accuracy, Terra cost roughly 76x more).

What Is It Primarily Used For? Becoming an “Intelligent Decision Node” in Code

In practical engineering systems, relying entirely on hardcoded rules is excessively brittle, while entrusting entire workflows to monolithic LLMs easily spirals out of control. Jev's core positioning is as a "fuzzy semantic decision node" embedded within conventional code control flow: the code maintains overall control flow, while the model is solely responsible for rendering probabilistic local semantic verdicts.

Its most direct utility is replacing hard-to-exhaust rules in code with "intelligent if-else" logic: routing and classifying requests, scoring risk, satisfaction, or fit, extracting constrained fields from unstructured input, or determining whether a given step warrants human intervention. Its low latency allows it to enter real-time interactions; its low unit price makes it well-suited for batch processing massive numbers of records; and its fixed candidates and probabilistic outputs enable it to serve as pre- and post-execution safety guardrails around other large models.

In the official SDK and open-source adapter, underlying semantic decisions are abstracted into three standard type primitives:

Noul (Boolean Evaluation): Takes unstructured text and an evaluation criterion as input, outputting the probability that the proposition holds true; used for handling binary decisions.

Choice (Discrete Classification): Performs single-choice selection across a clearly defined candidate set, returning a complete probability distribution across all categories along with an aggregate confidence score. The system natively supports selection among up to 255 categories; when facing larger candidate sets, it first scores them in parallel before making a discrete decision.

Score (Ordinal Scoring): Rates inputs against a predefined continuous scale or ordinal rubric, returning the current score value, a discrete distribution across tiers, and confidence; suited for quantifying severity, emotional satisfaction, or alignment.

Taking an enterprise's routine employee expense reimbursement audit as an example clearly illustrates the contrast between the two paradigms.

In traditional LLM approaches, developers typically cram all business rules into a single long prompt: "Each expense claim must include invoice documentation; reject if unreadable; classify into meals, travel, or equipment procurement; meal expenses exceeding $75 with itemized details inconsistent with the description require manager approval; approve all others directly." This monolithic prompt requires the model to deduce the final action in a single chain-of-thought pass; entangling multi-step logic easily triggers reasoning drift.

Under the System One architecture, this workflow is decomposed into a computation graph composed jointly of deterministic code and semantic primitives:

                 [Receive Expense Claim & Receipts]
                                │
                                ▼
         [Q1: Noul] Are receipt images or text legible?
                  /                     \
       (No / Low Prob)                 (Yes / High Prob)
              /                                 \
   [Reject & Request Re-upload]            [Q2: Choice] What category of expense?
                                                │
                                    ┌───────────┼───────────┐
                                    ▼           ▼           ▼
                                 [Travel]  [Equipment]   [Meals]
                                    │           │           │
                                    │           │           ▼
                                    │           │    [Python Native Code]
                                    │           │       Amount > $75?
                                    │           │      /          \
                                    │           │    (No)        (Yes)
                                    │           │    │             │
                                    │           │    │             ▼
                                    │           │    │    [Q3: Noul] Do receipt
                                    │           │    │    items match claim?
                                    │           │    │      /            \
                                    │           │    │  (Match)      (Mismatch)
                                    │           │    │    │                │
                                    ▼           ▼    ▼    ▼                ▼
                                 [ System Automatically Approves ]   [ Trigger Manager Approval ]

This architecture returns numerical comparisons like amount > 75 directly to the Python runtime, eliminating the risk of the model misreading numbers, while receipt legibility and semantic consistency are delegated to independent Noul and Choice nodes. This pattern embodies the system's core philosophy: leave deterministic logic to code, and semantic understanding to the model.

To help developers test migration from existing LLMs, TypeSafe open-sourced the Python adapter library system-one-adapter. The official README currently provides only a concrete invocation example for Noul (the constructor signatures for Choice and Score are not yet fully published in the README):

from system_one_adapter import SystemOneAdapterClient, Noul

# Initialize client, enable structured outputs and probability normalization
client = SystemOneAdapterClient(
    structured_outputs=True,
    llm_answer_mode="probabilities",
    normalize_probabilities=True,
)

# Pass in unstructured context to process alongside the Noul boolean question
response = client.system_one(
    state="本书印刷精美且内容详实，但外包装严重破损导致封面折损。",
    questions={
        "is_positive": Noul(instructions="整体评价是否属于正面好评？"),
    },
    provider="openai",
    model="gpt-4o-mini",
)

# Response is automatically wrapped in strongly typed objects, containing latency and probability diagnostics
print(response.answers)
print(response.usage.latency)

What Results Can It Achieve? Official Evaluations and Prototype Demos

To evaluate model performance in code-integrated environments, TypeSafe eschewed traditional public academic benchmarks in favor of custom-built workflow evaluations. The team argued that public leaderboards tend to encourage test-set overfitting and fail to directly reflect how models perform when embedded as business components inside systems.

The company constructed "Workflow Evals" to test model performance within fixed code computation graphs across four typical enterprise scenarios:

Security Incidents (Alert Triage): When an endpoint or server triggers a security alert, combined with machine history profiles, adjudicating whether to close automatically, escalate to a human analyst, or enforce network isolation.

Agent Trace Observability: After a customer service agent finishes handling a user ticket, traversing its complete context and tool invocation logs to determine whether human intervention is needed and the urgency level.

Invoice Processing: Comparing invoice details, purchase orders, and warehouse receiving slips to decide whether to release payment directly, hold for verification, or reject and return the invoice.

Customer Service (Dynamic Routing): Based on multi-turn communication context and real-time account status, determining the specific next action the agent should execute.

Because real-world business semantics have no naturally singular ground-truth standard, the evaluation benchmark adopted the mean judgment of two frontier LLMs—GPT-6 Astra and Claude Fable 5.1, both running in High Thinking deep-reasoning mode—as the de facto reference consensus label. All other evaluated models were tested using their default reasoning configurations.

The evaluation yielded a clear conclusion: across the equal-weighted average of these four sample tasks, every evaluated model was more accurate, cheaper, and faster when decomposed into a structured workflow than when the same model tackled the entire process with a single monolithic prompt. This conclusion applies solely to this specific harness and sample tasks, and cannot be extrapolated directly to all business workloads.

Under identical workflow configurations, the equal-weighted four-workflow average overview published by TypeSafe is as follows. All accuracies are relative to the team's custom "consensus label" rather than an externally recognized ground truth; apart from the two reference models, evaluated models used their respective providers' default reasoning settings.

In the equal-weighted overview across the four workflows published in official evaluations: Jev achieved an overall accuracy of 67.8%, with an average latency of 0.4 seconds and a per-invocation cost of $0.0004; OpenAI Terra, with comparable accuracy, reached 67.9%, requiring 10.1 seconds and costing $0.0304. In this directly recalculable overview comparison: at similar accuracy, Terra took roughly 25x longer than Jev (10.1s vs. 0.4s) and cost roughly 76x more ($0.0304 vs. $0.0004).

In addition to the equal-weighted overview of the four workflows above, the official evaluation page sequentially lists the four individual workflows: Security Incidents, Agent Trace Observability, Invoice Processing, and Customer Service. Official data indicates that while drastically slashing latency and cost, Jev maintained decision quality on par with mainstream frontier LLMs.

Two Prototype Demos: High-Frequency Decision-Making and Constrained Candidate Selection

Leveraging its low latency and strong typing characteristics, the company showcased several prototype scenarios where traditional LLMs struggle:

Real-time Doom control: In the official demo, engineers extracted live game states from the classic game Doom into structured data and fed them into Jev, with the model outputting next actions at a frequency of 10 queries per second (10 queries/s); TypeSafe claims driving this game agent incurs an overall invocation cost of approximately $7 per hour.

Wikiracing challenge: The rules require starting from one Wikipedia article and navigating to a target article solely by clicking internal hyperlinks. Each step often presents a massive number of candidate links. While traditional generative models may hallucinate nonexistent links when freely generating text, Jev strictly bounds the candidate set through types and schemas (scoring and selecting only within a given set of legitimate candidate links), structurally eliminating the generation of illegal links. TypeSafe claims it found paths in fewer steps, but this stems from structural guarantees bounding the candidate set through types, and does not signify zero hallucination across all semantic dimensions.

What Are Its Current Limitations?

Despite impressive official benchmarks, careful evaluation of underlying technical assumptions and boundary conditions is essential before system selection and production deployment.

The engineering boundaries of three-layer "reliability": When evaluating architectures, teams must clearly distinguish between three distinct levels of "reliability" to avoid conflating a local mechanism with end-to-end correctness:

1. Schema and Type Safety: Jev's zero type errors stem from directly binding its output space to a predefined Schema, with outputs mapped straight to discrete categories or scale values. The interface structurally eliminates JSON corruption or formatting drift; this is currently the only form of structural reliability guaranteed by design.
2. Probability Calibration: RLCD sets "higher confidence means higher accuracy" as its training optimization objective, aiming to have the model output probability distributions that honestly reflect its certainty; however, this is a model training objective and vendor claim. Without publicly available training details or independent calibration curves, it cannot be equated with verified absolute fact.
3. Semantic Correctness: Regardless of how secure the type formatting is or how calibrated the confidence scores are, model inference remains fundamentally statistical and probabilistic, offering no guarantee that business logic determinations are correct. In production rollouts, users must still build business-specific evaluation benchmarks (evals), configure rigorous decision thresholds, and establish human-in-the-loop fallback mechanisms.

Benchmark and environmental considerations: The sub-second latencies published officially were tested primarily within US-West data centers and co-located development environments; for teams making cross-border or long-distance calls, physical network round-trip time (RTT) will consume a noticeable portion of overall duration. Furthermore, the company concedes that whether its ultra-low pricing strategy is sustainable long-term still awaits commercial validation; using Astra and Fable 5.1 as evaluation reference baselines also objectively favors the logical biases of specific model families.

Architectural boundaries: Because Jev abandons free-form string generation, it cannot directly handle open-ended conversation, question answering, or text creation. It is better suited as a high-throughput semantic routing gateway, real-time interaction engine, or feature extractor within deterministic systems.

For system architects, Jev's value does not lie in replacing traditional LLMs, but in fostering a tiered evolution of intelligent system architectures: blazingly fast, inexpensive System One models handle the vast majority of deterministic data routing and perimeter defenses, while expensive, deliberative long-chain-of-thought large models are reserved for the most critical, reasoning-heavy expert nodes.

Frequently Asked Questions

Is Jev merely a pruned or distilled lightweight version of an existing large model?
No. Jev is neither a lightweight small model nor a conventional autoregressive large language model. Its output space, sampler, and training algorithm have all been re-engineered from the ground up to focus on classification and probability calibration tasks, thereby breaking away from the Pareto frontier curve of traditional LLMs.

Why doesn't the company publish scores on standard public academic benchmarks (such as MMLU)?
TypeSafe believes that general public leaderboards easily encourage prompt overfitting and fail to reflect how a model actually performs when embedded as a functional component in production code. The team advocates that users construct evaluations against their own business workflows to directly verify type stability and calibration accuracy.

Where does Jev's training data come from?
TypeSafe states that the data was produced internally and notes that it does not train on customer-submitted data.