Jev

Jev is a “System One” model from TypeSafe AI, released in limited early access on September 15, 2026 alongside a $40 million seed round led by DCVC. It is built to answer a narrower question than a large language model: given a block of state (a ticket, a document, a conversation) and a set of typed questions, return calibrated probabilities and confidence scores, not sentences. Where a chatbot generates text a human reads, Jev generates structured numbers software can act on directly, no parsing, no regex over a model’s free-text response, no chance of the answer drifting outside a defined schema. The name is a nod to 19th-century economist William Stanley Jevons and the Jevons Paradox, the observation that making a resource cheaper tends to increase how much of it gets used; TypeSafe’s bet is that making structured decisions dramatically cheaper than an LLM call will make software ask for far more of them.

The Three Primitives: Choice, Score, Noul

Every Jev request is one call: a state (a string, JSON object, or list of text) plus a dictionary of typed questions, each one of three kinds. All questions in a request are evaluated against the same state in a single parallel pass, which is the source of both Jev’s speed and its central limitation, discussed further below.

# Scenario: a moderation queue needs a binary flag, not a paragraph,
# on whether a post violates a specific, narrow policy.
from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state=post_text,
    questions={
        "wants_refund": Noul(
            instructions="Is the customer explicitly asking for a refund?"
        ),
    },
)
if response.answers["wants_refund"].noul > 0.8:
    escalate_to_billing_team(post_text)

# Scenario: reranking 100 BM25 search candidates for relevance
# to a query, without generating a paragraph of reasoning per doc.
from typesafe_sdk import Score, TypeSafeClient

client = TypeSafeClient()
scored = []
for doc in bm25_candidates:  # e.g. 100 candidate documents
    response = client.system_one(
        state={"query": query, "document": doc.text},
        questions={
            "relevance": Score(
                instructions="How relevant is this document to the query",
                criteria=["Not relevant", "Somewhat relevant", "Highly relevant"],
            ),
        },
    )
    scored.append((doc, response.answers["relevance"].score))
scored.sort(key=lambda pair: pair[1], reverse=True)

Notably, application code owns the decision, not Jev: a Noul or Score answer is a calibrated signal, and the caller sets the threshold for what counts as “urgent enough to page someone” or “confident enough to auto-route.” Jev estimates; the surrounding system decides.

Why It’s Fast: One Pass Instead of Token-by-Token Generation

An LLM answering “is this urgent, yes or no” still generates that answer one token at a time, autoregressively, paying for a full forward pass per token even though the final answer is a single bit of information. Jev is transformer-based but non-autoregressive for this workload: it takes the state once and evaluates every question against it in one parallel pass, trained with what TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), a training objective that optimizes the returned probabilities against actual outcomes rather than against human preference ratings the way RLHF does.

flowchart TB
    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;

    subgraph LLM["Typical LLM classification call"]
      direction TB
      A1["Prompt: classify this ticket"]:::data --> A2["Generate token 1"]:::process
      A2 --> A3["Generate token 2...N"]:::process
      A3 --> A4["Parse free text back\ninto a label"]:::process
    end
    subgraph JEV["Jev: one System One call"]
      direction TB
      B1["State + N typed questions"]:::data --> B2["Single parallel pass,\nnon-autoregressive"]:::process
      B2 --> B3["Typed answers +\ncalibrated confidence"]:::output
    end

TypeSafe’s published architecture details stop there: no weights, no technical paper, and outside observers have speculated it may build on an open-weight LLM backbone repurposed for this objective, but that hasn’t been confirmed. What TypeSafe has published are reference-benchmark numbers: on its internal workflow evaluations, Jev answered in 0.114 seconds against 8.566 seconds for GPT-5.6 Terra, a ~193.6x speed difference, at a $0.000081 cost per decision against $0.013880, a ~444.6x cost difference. TypeSafe itself flags these as likely the high end of real-world results, since the workflows were built by its own model-capabilities team.

Interactive: One Parallel Call vs. N Separate LLM Calls

The practical case for Jev shows up most clearly once a product needs more than one structured decision per item, department, frustration, urgency, spam risk, priority, each of which would otherwise be its own call to an LLM. Jev evaluates all of them against the same state in the time of roughly one call; a chain of separate LLM calls pays the per-call latency and cost N times over. The widget below uses TypeSafe’s own disclosed reference numbers (0.114s / $0.000081 for Jev, 8.566s / $0.013880 per GPT-5.6 Terra call) to show what happens as the number of required decisions grows.

Performance and Pricing Claims

TypeSafe is explicit about the caveats behind these numbers: the reference workflows were built by TypeSafe’s own model-capabilities team, “the reference answer is the average of GPT-6 Astra and Fable 5.1,” and the company states its own peak figures likely sit at the high end of what real deployments will see. “Zero hallucination” in TypeSafe’s framing means the answer will always conform to the requested schema, a Choice answer will always be one of the offered options, not that the underlying judgment is always correct.

Where It Fits: Model Routing and Safety Gating

Jev’s most cited early use cases are inside agent harnesses rather than as a standalone product: cheap, fast, typed decisions are exactly what a harness needs to make routing and safety choices without invoking a full model for each one.

# Scenario: route each incoming request to a cheap or expensive
# model depending on how complex Jev judges it to be, before any
# tokens are spent on the actual task.
from langchain_typesafe.experimental.middleware import ModelRouterMiddleware, ModelChoice

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(model="openai:gpt-5.6-luna", when="simple, routine request"),
        "powerful": ModelChoice(model="openai:gpt-5.6-sol", when="complex, multi-step request"),
    },
)
agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

A second documented pattern, AutoModeMiddleware, uses Jev to score the risk of a tool call an agentic AI system is about to execute, deleting a file, sending a payment, before it runs, gating the action on a confidence threshold the application defines. Because adding more typed questions to a single Jev call barely changes its response time, a harness can ask several such safety questions per step (is this destructive, is this reversible, does this need human-in-the-loop confirmation) for close to the cost and latency of asking one.

Limitations and Open Questions

Jev’s central trade-off is opacity in exchange for speed. Simon Willison’s assessment after testing it is blunt: “put in all the text you want, the only thing you’re going to get back is a floating point number,” which means none of the reasoning behind a Choice or Score answer is inspectable, a real problem for any application, hiring screens, content moderation, credit decisions, where an explanation matters as much as the verdict, and where a hidden bias in the model is much harder to detect experimentally than it would be if the model were producing text a human could read. Beyond that, TypeSafe has disclosed no architecture details, no weights, and no independent benchmark has yet reproduced its performance claims; Jev was reportedly developed privately for roughly two years before its announcement, which limited outside scrutiny during that period. Access is currently a hosted API behind a waitlist, with no self-hosting or open-weight option, which also means every typed decision an application makes depends on TypeSafe’s uptime and pricing.

What’s New (2025-2026)

Jev itself is the news: it did not exist as a public product before September 15, 2026, when TypeSafe AI, founded in 2024 by ex-OpenAI RLHF researcher Diogo Almeida along with Erik Gafni and Sasha Sheng, released it in early access alongside a $40 million DCVC-led seed round at a $200 million valuation. A community-run leaderboard, JevBench, appeared within days to compare Jev against more than 80 alternative “System One” implementations, including open-weight replications, and a hosted competitor, meraGPT’s Decider 1, launched using the same request schema, compatible with TypeSafe’s own SDK by changing only the base URL. Whether “System One” models become a durable second category alongside conversational LLMs, or get folded back into standard model APIs as a structured-output mode, is the open question the next year of this space will answer.

# Scenario: a support inbox needs every incoming ticket routed,
# scored for frustration, and flagged as urgent or not, without
# three separate LLM calls or free-text output to parse.
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # reads TYPESAFE_API_KEY from env

ticket = ("My subscription was charged twice this month and the "
          "dashboard still shows the old plan. Please fix this today.")

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)        # "billing"
print(response.answers["department"].confidence)    # 0.91
print(response.answers["frustration"].score)         # 1.0
print(response.answers["is_urgent"].noul)            # 0.87