What is TypeSafe Jev?

TypeSafe Jev is an AI model that answers questions for software instead of writing text for people. An application sends Jev some content and a set of questions, each with a fixed set of possible answers. Jev returns one answer per question, plus a number that shows how certain it is.

TypeSafe AI released Jev on September 15, 2026. Access opened to all developers, with no waitlist, on September 20. The company calls Jev the first System One model: a class of model built for fast decisions inside programs.

TypeSafe Jev in Plain Terms

Many apps now ask chat models such as ChatGPT or Claude to make small decisions. Is this email urgent? Which team should answer this support ticket? Does this comment break the rules? The app needs a short answer, but a chat model always answers by writing.

An analogy helps. Suppose you ask a colleague a yes-or-no question, and the colleague replies with a full paragraph. You must read the whole paragraph to find the answer. Sometimes the paragraph has no clear yes or no in it at all. Software that asks a chat model for a decision has the same problem on every request. It waits for the text, searches the text for the answer, and retries or flags the replies that do not fit.

Jev removes the writing step. You give Jev the situation, a clear question, and the answers it can choose from. Jev picks one of those answers and reports how sure it is. It cannot reply with an answer that is not on your list.

To extend the analogy, Jev is not a better chatbot. It is closer to a panel of labeled buttons that an app can press thousands of times a day. Each press returns one of the labels you wrote, plus a number that says how sure Jev is.

A support inbox shows how this works. For each new message, the app asks Jev three questions in one request. Which team owns the message? How urgent is it? Does the customer ask for a refund? Jev answers with a team name, an urgency level, and the probability of a refund request. Ordinary code then routes the message.

The second part of the idea is speed and price. TypeSafe reports answers in 70 to 500 milliseconds, compared with seconds or minutes for large chat models on similar questions. It charges only for the content Jev reads, and the answers themselves are free. At that cost, software can ask for a decision on every message, every record, or every step of a process.

The name reflects this expectation. In the 1860s, the economist William Stanley Jevons observed that more efficient steam engines increased total coal use. TypeSafe expects cheaper decisions to increase the number of decisions that software makes.

Jev also has clear limits. It does not chat, write, or explain its answers, and it reads text only. It can also pick a wrong answer from your list, sometimes with high confidence. Test it on your own examples before you trust it with a real decision.

Why Did TypeSafe Build Jev?

Developers train large language models (LLMs) to write text that people prefer. Reinforcement learning from human feedback (RLHF) rewards the replies that human raters rate highest. That objective produced capable chat assistants. TypeSafe argues that it is a poor fit for the narrow judgments that production software makes thousands of times an hour.

A ticket router needs the label billing and a number it can compare with a threshold. A moderation filter needs the probability that a comment contains personal data. A check on an agent's tool calls needs a yes or a no before the tool runs. None of them needs a paragraph.

Teams work around the mismatch today. They ask chat models for JSON, validate the output against a schema, and retry when parsing fails. Structured-output modes and LLM tool calling reduce these failures. They do not change the underlying design: the model still generates tokens one at a time, and code still interprets a string.

TypeSafe founder Diogo Almeida worked at OpenAI on the instruction-following methods that became the research behind ChatGPT. The launch post by Almeida calls Jev "a frontier-intelligence function call" that takes unstructured state in and returns typed probabilistic decisions. The System One name comes from Daniel Kahneman's book Thinking, Fast and Slow, which separates fast, intuitive judgment from slow, deliberate reasoning. Jev targets the fast kind.

How Does TypeSafe Jev Work?

An application calls Jev with one HTTP request to POST https://api.typesafe.ai/v1/systemone, authenticated with a bearer API key. The request body has three fields:

• model selects the model version. The alias jev-latest currently points to jev-1.13.0.
• state is the content to judge: a string, a JSON object, or an array of text values.
• questions is a map of named questions. Each question has a type, instructions, and criteria that describe the possible answers.

Jev evaluates every question in parallel, and each question sees the same state in isolation. The response returns one typed answer per question, under the same names. According to TypeSafe, extra questions add a small token cost and barely change response time.

The following request asks three questions about one support message:

{
  "model": "jev-latest",
  "state": {
    "message": "I was charged twice for order A-104 and my account is now overdrawn. Please fix this today."
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this message?",
      "criteria": {
        "billing": "Payments, invoices, refunds",
        "technical": "Bugs, outages, integrations",
        "account": "Login and access"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is a reply?",
      "criteria": ["Can wait", "Reply this week", "Reply today"]
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Does the customer ask for a refund?"
    }
  }
}

A response has the following shape. The values are illustrative:

{
  "model": "jev-1.13.0",
  "answers": {
    "team": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.97, "technical": 0.02, "account": 0.01 },
      "confidence": 0.95
    },
    "urgency": {
      "type": "score",
      "score": 1.9,
      "legend": { "0": "Can wait", "1": "Reply this week", "2": "Reply today" },
      "probabilities": { "0": 0.0, "1": 0.1, "2": 0.9 },
      "confidence": 0.85
    },
    "refund_requested": { "type": "noul", "noul": 0.91 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 30 }
}

The application reads answers.team.choice and answers.refund_requested.noul as ordinary values. No parsing step exists, because the request defines the answer space before the model runs. Choice and Score answers also carry a confidence value from 0 to 1. Noul answers have no separate confidence field, because the probability of yes already expresses certainty.

Choice

Choice picks one option from a closed set that you define, with up to 255 options. Use it when the answer is a category with no order, such as a team, a language, or a document type. Add an other option when the list does not cover every possible input. For large option sets, TypeSafe scores the options first and then chooses, which can add latency.

A Choice cannot return an option outside the set. It can still return the wrong option from the set.

Score

Score places the state on an ordered scale that you write, from 2 to 10 levels. Describe each level in words, such as calm, frustrated, and very angry. The score field is a probability-weighted position, so it can fall between two levels. A score of 1.4 on a three-level scale sits between level 1 and level 2.

Use a fractional score to rank items or to compare with a threshold. Do not treat it as a measured quantity, because TypeSafe notes that score levels are weak in numerical calibration.

Noul

Noul is TypeSafe's name for a yes-or-no question. Jev returns the probability of yes, as a number from 0 to 1. Optional criteria describe what a yes and a no mean. A value near 0.5 means that Jev gives yes and no similar weight. It does not describe a medium amount of anything.

Use a Noul for a clear proposition. "Does this message request a refund?" is a good example. Do not use a Noul to measure degree. For "Is the candidate strong in Python?", a middle value can mean medium experience or an unclear case. TypeSafe's documentation recommends a Score with described levels for questions like this.

How Does TypeSafe Jev Compare to an LLM?

The main difference is the output contract, not benchmark rank. The table follows TypeSafe's launch post and documentation, so its latency and price rows are vendor-reported.

Two caveats belong next to this table. First, TypeSafe markets Jev with a claim of zero hallucinations. The claim means that Jev cannot return an answer outside the declared schema. Jev can still return a wrong answer inside the schema. On Hacker News, Almeida agreed that type safety is not factual correctness.

Second, the homepage figures of 193.6x faster and 444.6x cheaper come from TypeSafe's own workflow evaluations. The launch post lists the sources of possible bias. Members of the model capabilities team at TypeSafe wrote the workflows. The reference answers are the average of GPT-6 Astra and Fable 5.1. TypeSafe expects the figures to sit at the higher end of real-world gains.

An independent test shows the same pattern for speed and cost. Mike Taylor, head of evals at Every, ran 21 questions against each of 37 documents. Jev returned all 777 judgments in under 0.7 seconds, at an estimated cost of a quarter of a cent. Accuracy is harder to verify than speed. TypeSafe does not publish results on public benchmarks, and it asks users to build evaluations for their own tasks.

Jev vs. JSON Mode and Structured Outputs

JSON mode and structured outputs constrain what a chat model writes. The model still generates tokens, and code still parses a string. Jev never generates a string. It computes a probability for every allowed answer in one pass and returns the full distribution. Code can compare that distribution with a threshold, and a parsed JSON value carries no such number.

Almeida also argues that constrained decoding lowers answer quality. In that view, a model that assigns probability to an invalid token is already confused, and masking the token hides the problem.

What Is TypeSafe Jev Used For?

TypeSafe's launch post names four target workloads: decision steps inside workflows, map-reduce over large datasets, real-time applications, and verification of LLM output. The documented examples fall into five patterns. In each one, Jev decides, code acts, and an LLM runs only when a task needs written language.

Routing and triage. One request returns a team as a Choice, a severity as a Score, and a refund request as a Noul. Code routes the ticket to deterministic logic, a specialist LLM, or a person.

Guardrails and tool-call checks. An agent asks Jev whether a planned tool call deletes data or breaks a policy before the call runs. TypeSafe's cookbooks also screen LLM prompts and outputs for jailbreak attempts and harmful requests. Ask one question per risk, so code can see which check failed.

Ranking and retrieval filtering. One Noul per query and candidate pair can re-rank a search shortlist by probability. In a retrieval-augmented generation (RAG) pipeline, Jev can score each retrieved passage before the answering model reads it. That step can drop passages that carry injected instructions.

Map-reduce over large datasets. A low cost per call makes it practical to ask the same questions about every row of a large table.

Real-time applications. Sub-second responses put decisions inside user-facing flows and control loops. One TypeSafe demo plays the game Doom from structured game state at about 10 queries per second.

What Are the Limitations of TypeSafe Jev?

TypeSafe publishes a jaggedness page for jev-1.13 that lists known failure modes and workarounds.

• Counting, arithmetic, and dates. Jev does not count reliably, and it reads dates as text rather than as ordered values. Do the math in code, then pass Jev the computed number or a named bucket.
• Literal reading. Jev answers the question as written. Double negatives, implied conditions, and multi-hop questions reduce accuracy. State the exact condition, and name the relevant field of the state.
• Irrelevant context. Accuracy falls as the state grows with detail unrelated to the decision. Filter in code first, and send only the fields that the question needs.
• Adversarial content. Jev does not treat the state as hostile by default. Injected instructions inside the state can move an answer, so test adversarial inputs before a wide rollout.
• Consistency across questions. A Noul and a yes-or-no Choice on the same statement can disagree. Ask each decision one way, and enforce arithmetic identities in code.
• No text generation. Jev does not write, summarize, or explain its reasoning. For extraction, TypeSafe recommends a Choice over candidate values instead of a request for the value itself.

Jev also accepts text only, and its accuracy is best in English.

Advanced Topics

Calibration and RLCD

TypeSafe trains Jev with Reinforcement Learning for Calibrated Decisions (RLCD). The objective rewards probabilities that match outcomes, not text that human raters prefer. For a calibrated model, about 80% of the answers scored at 0.8 are correct.

Calibration describes groups of predictions, so it guarantees nothing about a single answer. As of September 2026, TypeSafe has not published an RLCD paper or calibration curves. Measure calibration on your own labeled data before you set thresholds.

Confidence-Gated Routing

TypeSafe derives confidence from the shape of the probability distribution. A peaked distribution scores high, and a flat one scores low. The documentation suggests three bands. At high confidence, code acts automatically. At medium confidence, code asks for confirmation or more context. At low confidence, code routes the case to a person or to another system.

Set each threshold from the cost of an error, not as one global number. A read-only action can run at moderate confidence, and a refund or a destructive tool call needs a much higher threshold. For a Noul, raise the threshold when a false yes is expensive, and lower it when a missed yes is expensive. Framework integrations can define confidence differently. Pydantic AI reports a margin from the decision threshold, not a probability that the answer is correct.

Composite Scoring and Speculative Fan-Out

TypeSafe recommends atomic questions: one judgment that a knowledgeable person could make in a few seconds. Split a compound judgment, such as the quality of a startup pitch, into market size, technical feasibility, and differentiation. Combine the three scores in code with weights that you own. When priorities change, you change a coefficient instead of a prompt.

Questions in one request run in parallel, so a request can also include speculative questions. Code reads those answers only when they apply, such as a severity score that matters only for bug reports. TypeSafe calls this pattern speculative fan-out.

Version Pinning

The jev-latest and jev-preview aliases move when TypeSafe releases a new version. Thresholds tuned against one version can shift on the next one. The model field in each response reports the versioned ID that answered, so log it with every decision. Pin a versioned ID such as jev-1.13.0 in production. Re-run your evaluation set before each upgrade.

TypeSafe Jev with Spice

Jev judges only the state it receives, and its accuracy falls when that state carries unrelated detail. In production, the hard part is often building a small, relevant state from several systems within the latency budget of the decision. Spice builds that state with SQL.

Spice joins operational databases, warehouses, and data lakes in one query through SQL federation and acceleration. It connects to 40+ data sources. Spice accelerates the working set locally, so assembling a state does not wait on a round trip to each source. Hybrid SQL search returns only the relevant passages or records, which keeps the state short.

The escalation path runs in the same runtime. AI model serving connects hosted and local LLMs through one interface, and LLM inference from SQL calls a model inside a query. Code can send any case that Jev scores below its confidence threshold to that model for a written answer or a closer review.

The following example builds the state with one federated query, asks Jev two questions, and escalates low-confidence cases:

import requests
from typesafe_sdk import Choice, Noul, TypeSafeClient

# Build the state with one federated query. The tickets and customers
# datasets come from two different sources configured in Spice.
rows = requests.post(
    "http://localhost:8090/v1/sql",
    headers={"Content-Type": "text/plain"},
    data="""
        SELECT t.subject, t.body, c.plan, c.open_invoices
        FROM tickets t
        JOIN customers c ON t.customer_id = c.id
        WHERE t.id = 4821
    """,
).json()
state = rows[0]

# Ask Jev typed questions about that state.
with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions={
            "team": Choice(
                instructions="Which team should handle this ticket?",
                criteria={"billing": None, "technical": None, "account": None},
            ),
            "refund_requested": Noul(
                instructions="Does the customer ask for a refund?"
            ),
        },
    )

# Act on confident answers in code. Escalate the rest.
team = response.choices["team"]
refund = response.nouls["refund_requested"]
if team.confidence >= 0.8:
    assign_ticket(4821, team.choice, refund_review=refund.noul >= 0.9)
else:
    escalate_ticket(4821, state)  # a person or an LLM reviews the ticket