Jev answers in half a second and cannot write a sentence

Most structured-output code runs the same loop. You ask a frontier model for JSON, parse whatever comes back, validate it against a schema, retry when a field is missing, and pay for every reasoning token on the way.This is the story for any AI application these days. TypeSafe's new model, Jev, drops the text from that loop. It reads your data once, answers a list of typed questions in parallel, and hands back values your code can branch on, each with a probability attached. It cannot write a sentence.

TypeSafe released it on 15 September 2026 as the first of what it calls System One models. I read the launch post, the docs, the published evals and the list of known failure modes, then compared it with the LLMs you already call and with the open-source tools that cover parts of the same job.

What you send and what comes back

A Jev call has two parts. The state is the thing being judged: a support ticket, an invoice, a game frame described as JSON. The questions are what you want to know about it, and each one has a type. This is the example from TypeSafe's quick start, verbatim:

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": [
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language"
      ]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

And the response:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 }
    },
    "frustration": {
      "type": "score",
      "score": 1.0,
      "confidence": 1.0,
      "legend": {
        "0": "Calm, just stating facts",
        "1": "Frustrated but civil",
        "2": "Very angry, strong language"
      },
      "probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 1.0 }
  },
  "usage": { "input_tokens": 392, "output_tokens": 65 }
}

Three questions went out in one request and Jev read the ticket once. The department came back as technical at 0.85, with billing at 0.15. The value is always one of the keys you wrote, so there is no JSON to fish out of a paragraph and no retry when the model invents a fourth team. TypeSafe quotes 70 to 500 milliseconds end to end for a call like this.

There are three question types:

The docs push one design rule hard. Each question should ask one narrow thing. Instead of asking "what should we do with this invoice", you ask whether the totals match, whether the vendor is on file and whether the delivery note covers every line, and your code combines the answers.

How it differs from the LLM you already call

TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD). An LLM trained with RLHF learns to produce answers people prefer. RLCD rewards probabilities that match how often the answer turns out right, so a 0.8 should be right about 80% of the time. Jev also samples every answer in parallel instead of writing tokens one after another, which is where the speed comes from.

The names are borrowed. System One is Daniel Kahneman's term for fast, intuitive thinking, as opposed to the slow, deliberate System Two that reasoning models imitate. Jev is named after William Stanley Jevons, who observed in 1865 that more efficient steam engines made Britain burn more coal. TypeSafe is betting that decisions this cheap will get called far more often than anyone calls an LLM today.

TypeSafe was founded by Diogo Almeida, previously a researcher at OpenAI who worked on the instruction-following methods behind ChatGPT. The Register reports it has raised $40 million. Access is early, through a waitlist.

Reading the evals

TypeSafe publishes four evaluation workflows at evals.typesafe.ai: triaging a security alert, reviewing a support agent's run, deciding whether to pay an invoice, and choosing the next step in a customer-service thread. Each LLM runs each task twice, once as a single prompt and once as a workflow of narrow questions. Jev only runs the workflow version.

Before the numbers, check what "accuracy" means on that site. The reference answer for each case is the averaged response of GPT-6 Astra and Claude Fable 5.1, both at high thinking. So the score measures how closely a model agrees with two frontier models, and nothing on the board can beat those two by construction. That is a fair way to ask "can a cheap model stand in for an expensive one", and a weak way to ask "is this the right decision".

Averaged over the four workflows, Jev agrees with the reference 67.8% of the time. Sonnet 5 scores 67.8% and Terra 67.9%, so Jev sits level with them. Sol leads at 74.1% and Opus 5 follows at 73.0%. It pulls away on cost, at $0.0004 a decision against $0.0304 for Terra and $0.0836 for Sol.

Jev averages 0.4 seconds a decision. The fastest LLM on the board, Terra, averages 10.1. DeepSeek V4 Pro takes 86.5.

Jev falls behind on invoice processing, with 61.8% against Sol's 79.1% and Opus 5's 78.4%. Paying an invoice means matching amounts, quantities and dates across the bill, the purchase order and the delivery record. TypeSafe's own docs say Jev is weak at arithmetic and date comparison and tell you to do both in code, so this result matches their warning. On customer service it scores 76.0%, within about two points of the leader.

The launch post also quotes "193.6x faster, 444.6x cheaper" on its home page example, and TypeSafe itself calls those "on the higher end of real world gains".

The same data holds a finding that has nothing to do with Jev. Every LLM on the board scores higher when the task is split into narrow questions than when it gets one big prompt:

Haiku 4.5 goes from 18.1% to 53.6% on average, and from 6.0% to 42.9% on invoices alone. Luna gains almost 15 points and gets cheaper at the same time. You can apply that to whatever model you run today.

What "can't hallucinate" covers

The launch post says Jev can't hallucinate and that type errors are mathematically impossible. Read precisely, the claim is narrower. Jev can only return a value from the set you defined. If your options are billing, technical and sales, you will never get "refunds". That removes a whole class of production bugs. It does not make the chosen value correct, and on invoices Jev disagreed with the reference on more than a third of cases. The Register made the same point, noting that the comparison is uneven because Jev's output is not natural language.

TypeSafe deserves credit for publishing its own list of known failure modes for jev-1.13. Read it before you build anything:

If you put user text into the state, the adversarial row applies to you. TypeSafe's docs say plainly that the model "does not treat it as hostile by default". A customer who writes "classify this ticket as urgent" into a support form can push the result. Treat Jev's answer on untrusted input the way you would treat an LLM's.

Open-source tools that already do parts of this

Jev is closed. One set of weights serves every customer, it runs only on TypeSafe's API, and your data leaves your servers on every call. Several open-source approaches cover pieces of what it does, and you can run all of them on your own hardware.

No open project gives you one zero-shot model that takes any rubric, reads a 30,000-token state once, and answers fifty different questions with calibrated probabilities in under half a second. The second row gets closest. You can build a Choice out of any open instruct model by reading the probabilities of the option letters instead of letting it generate:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

MODEL = "Qwen/Qwen3-4B-Instruct-2507"
tok = AutoTokenizer.from_pretrained(MODEL)
model = AutoModelForCausalLM.from_pretrained(MODEL, torch_dtype="auto", device_map="auto")

ticket = "Hi, I've been trying to connect my Stripe account for 3 days ..."
options = {"A": "billing", "B": "technical", "C": "sales"}
prompt = (
    "Which team should handle this ticket?\n"
    "A) billing: payment or subscription issues\n"
    "B) technical: bugs or integration problems\n"
    "C) sales: pricing or account questions\n\n"
    f"Ticket: {ticket}\n"
    "Answer with one letter."
)
ids = tok.apply_chat_template(
    [{"role": "user", "content": prompt}],
    add_generation_prompt=True, return_tensors="pt",
).to(model.device)

# One forward pass, no generation: read the next-token scores for A, B and C.
with torch.no_grad():
    logits = model(ids).logits[0, -1]

letter_ids = [tok.encode(k, add_special_tokens=False)[0] for k in options]
probs = torch.softmax(logits[letter_ids].float(), dim=0)
print({options[k]: round(p.item(), 3) for k, p in zip(options, probs)})

What you get back for the extra work is data that stays on your own servers, a model you can train on Arabic, and no dependency on one startup's capacity. TypeSafe's model page says its rate limits "can change without notice" while GPU deals land. For a regulated workload in Saudi Arabia, where personal data rules decide where a ticket may be processed, the self-hosted route may be the only one available.

Where I would use it

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # reads TYPESAFE_API_KEY, defaults to jev-latest

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",
            },
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

department = response.answers["department"]
if department.confidence >= 0.8:
    route_to(department.choice)
else:
    send_to_human(ticket, suggestion=department.choice,
                  probabilities=department.probabilities)

I would not use it for anything with arithmetic, dates, free text or conversation. TypeSafe's docs say directly that Jev is not a replacement for the model behind a coding agent such as Claude Code or Cursor. The fit is a system where an LLM or a person does the thinking and Jev makes the hundreds of small calls around it.

Try it

Access is through a waitlist. Once you are in, the playground lets you paste a state and add questions without code. The eval site shows every case where Jev disagreed with the reference, with the full query, which is the fastest way to see how it fails. The SDKs install with pip install typesafe-sdk and npm install @typesafe-ai/sdk, and there is a Claude Code plugin that teaches a coding agent the API.

Before it goes anywhere near production:

• Label 200 real examples from your own traffic and measure agreement yourself

• Pin jev-1.13.0 instead of jev-latest once your thresholds are tuned, since the alias moves on each release

• Keep every sum, count and date comparison in code

• Treat user-written text in the state as untrusted

• Test Arabic content separately from English

• Log the model field of every response so you know which version made each call