Jev and System One models

Most of the language model calls inside an automated system are not asking for prose. They are asking for a decision: send this ticket to billing or to engineering, allow this tool call or refuse it, mark this comment as spam or leave it. The usual way to get one from a large language model is to ask it to write the answer out as JSON, parse the text, validate it against a schema and retry when it comes back malformed. Jev, released by TypeSafe AI in September 2026, removes the writing step. It reads the input, reads a set of named questions, and returns each answer as a typed value with a probability attached. It never produces a sentence.

A decision, not a sentence

TypeSafe calls Jev a System One model. The phrase borrows from Daniel Kahneman’s description of two modes of thought: System 1 is fast, automatic judgement, the kind a person makes before they could explain it; System 2 is slow, deliberate reasoning. A chat model with a reasoning budget is built to imitate System 2. Jev is built for the other kind, the snap call that is either right or wrong and needs no essay attached.

The name is a statement of intent too. It honours William Stanley Jevons, the economist who observed that making coal use more efficient increased total coal consumption rather than reducing it. The bet is the same shape: if a judgement becomes cheap and quick enough, people will put one in places where nobody would currently place a model call, such as every row of a table, every event on a stream, or every step of an agent.

The difference in mechanism is what the whole design follows from. A generative model produces its answer one token at a time, and a structured answer is only structured if every one of those tokens comes out right. Jev evaluates all of the questions in a request together and fills in a schema that the API guarantees, so there is nothing to parse and no type error to handle.

How it is trained, according to TypeSafe

The vendor describes a training method it calls RLCD, reinforcement learning for calibrated decisions, and sets it against the two methods behind most current models. Treat this as the vendor’s own account; the training details are not independently documented.

Calibrated has a specific meaning here. If you collect every answer the model gave with a probability of 0.8, about eight in ten of them should be correct. It is a property of many predictions taken together. It says nothing certain about any single answer, and a 0.95 can still be wrong on the case in front of you.

Anatomy of one request

A request has two parts you write and one part you get back.

State is the material the decision is about. It can be a plain string, a JSON object or an array of text, and the documentation recommends an object, because question instructions can then refer to a field with a backtick path such as ticket.messages[0].text. That keeps a question pointed at the part of the input it concerns instead of the whole thing. State is text only: images, audio and video are not accepted. English is the primary language, and the documentation states that accuracy is currently lower in other languages, including Chinese, Japanese and Korean scripts.

Questions are a map from an id you choose to a question definition. Two details catch people out. First, the id is for your code, not for the model, so a question called is_refund with the instruction “Check this” asks the model nothing useful; the full question belongs in instructions. Second, questions in the same request cannot see each other’s answers. If one decision depends on another, that is two requests.

The three question types

TypeSafe calls these the primitives. Every question is exactly one of them, and the type decides the shape of the answer.

A Noul is the one people misuse. Because the probability is the answer, there is no separate confidence value, and reading 0.5 as “somewhat” treats a coin toss as a measurement. If the thing you want is genuinely a matter of degree, it is a Score with levels you define.

Writing questions that work

The documentation and the LangChain post agree on a few habits, and they follow from how the model works rather than being matters of style:

• Ask for a snap judgement. “Does this message ask for a refund?” is a System One question. “Analyse the message, weigh the customer history and decide” asks for reasoning the model does not do.
• One decision per question. If a question contains “and”, it is usually two Nouls.
• Point at the field. Refer to the part of the state that matters with a backtick path.
• Split a hard judgement into parts. Instead of one Score for “how good is this supplier”, ask several narrower Scores and combine them with weights in your own code. TypeSafe calls this composite scoring. It also makes the final number explainable, since each part is visible.

A worked example: routing an on-call alert

The example below is ours, not the vendor’s. An alert fires, and the question is who gets paged. The state carries the alert, recent deploys and the paging policy as a JSON object, so each question can point at the field it needs.

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @alert-request.json

{
  "model": "jev-1.13.0",
  "state": {
    "alert": {
      "service": "checkout-api",
      "summary": "p99 latency above 4 seconds for 12 minutes",
      "region": "eu-west-1"
    },
    "recent_deploys": [
      { "service": "payments-gateway", "minutes_ago": 9 }
    ],
    "policy": "Latency alerts that begin within 30 minutes of a deploy are paged to the team that deployed."
  },
  "questions": {
    "owner": {
      "type": "choice",
      "instructions": "Following `policy` and `recent_deploys`, which team should be paged for `alert`?",
      "criteria": {
        "payments": "Owns payments-gateway and anything it deployed",
        "checkout": "Owns checkout-api when no recent deploy explains the alert",
        "platform": "Owns shared infrastructure such as load balancers and DNS"
      }
    },
    "impact": {
      "type": "score",
      "instructions": "How much customer impact does `alert.summary` describe?",
      "criteria": [
        "No visible customer impact",
        "Slower for some customers",
        "Customers cannot complete purchases"
      ]
    },
    "deploy_related": {
      "type": "noul",
      "instructions": "Is the alert plausibly caused by one of the `recent_deploys`?"
    }
  }
}

The response has one entry per question id, each in the shape of its type. The values here are illustrative, chosen to show the shape; they are not a recorded response.

{
  "model": "jev-1.13.0",
  "answers": {
    "owner": {
      "type": "choice",
      "choice": "payments",
      "confidence": 0.81,
      "probabilities": { "payments": 0.88, "checkout": 0.1, "platform": 0.02 }
    },
    "impact": {
      "type": "score",
      "score": 1.2,
      "confidence": 0.7,
      "legend": {
        "0": "No visible customer impact",
        "1": "Slower for some customers",
        "2": "Customers cannot complete purchases"
      },
      "probabilities": { "0": 0.05, "1": 0.7, "2": 0.25 }
    },
    "deploy_related": { "type": "noul", "noul": 0.93 }
  },
  "usage": { "input_tokens": 410, "output_tokens": 70 }
}

The model field reports which release answered. Log it: when an alias such as jev-latest moves to a new release, this field is how you notice.

Confidence, and what to do with it

A probability is only useful if something in your code reacts to it. TypeSafe’s confidence guidance describes three bands, and the useful part is that the boundaries are not fixed: they scale with what happens if the answer is wrong.

The documentation’s example puts the human hand-off below a confidence of 0.5, lets low-stakes actions proceed, and asks for more than 0.9 plus a confirmation before a high-stakes one. In code, for the alert above, that looks like this:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # reads TYPESAFE_API_KEY from the environment


def page_team(team: str, alert: dict, note: str = "") -> str:
    return f"paged {team}: {alert['service']} {note}".strip()


def page_incident_commander(alert: dict, reason: str) -> str:
    return f"paged incident commander: {alert['service']} ({reason})"


def open_ticket(team: str, alert: dict) -> str:
    return f"ticket for {team}: {alert['service']}"


def route_alert(state: dict) -> str:
    response = client.system_one(
        state=state,
        questions={
            "owner": Choice(
                instructions="Following `policy` and `recent_deploys`, which team should be paged for `alert`?",
                criteria={
                    "payments": "Owns payments-gateway and anything it deployed",
                    "checkout": "Owns checkout-api when no recent deploy explains the alert",
                    "platform": "Owns shared infrastructure such as load balancers and DNS",
                },
            ),
            "impact": Score(
                instructions="How much customer impact does `alert.summary` describe?",
                criteria=[
                    "No visible customer impact",
                    "Slower for some customers",
                    "Customers cannot complete purchases",
                ],
            ),
            "deploy_related": Noul(
                instructions="Is the alert plausibly caused by one of the `recent_deploys`?",
            ),
        },
    )
    owner = response.answers["owner"]
    impact = response.answers["impact"]
    deploy_related = response.answers["deploy_related"].noul
    alert = state["alert"]

    if owner.confidence < 0.5:
        return page_incident_commander(alert, reason="owner unclear")
    if impact.score >= 1.5:
        # Paging the wrong team during an outage costs minutes, so the bar is higher.
        if owner.confidence > 0.9:
            note = "check the recent deploy first" if deploy_related > 0.8 else ""
            return page_team(owner.choice, alert, note)
        return page_incident_commander(alert, reason=f"suggested owner {owner.choice}")
    return open_ticket(owner.choice, alert)

The SDK calls jev-latest unless told otherwise; the SDK reference covers selecting a versioned model, which you should do before relying on thresholds like these.

The trade-off in every threshold is between two costs you can count. Raise it and more decisions land on a person, which is slower and uses someone’s attention. Lower it and more wrong actions happen automatically. Neither number is knowable in advance. The way to set them is to log each probability next to the eventual outcome, group the logged answers by probability, and check whether each group was right about as often as it claimed. That comparison is a calibration check on your data, and it is the only evidence that the vendor’s calibration carries over to your inputs. The evaluation page covers building the labelled set it needs.

Asking everything at once

Because questions in one request are independent and evaluated in parallel, an extra question adds tokens but very little waiting. TypeSafe turns this into a pattern it calls speculative fan-out: ask every question you might need in a single call, then let ordinary code decide which answers to use. In its own cookbook, sending thirteen questions in one request instead of thirteen separate requests came out 11.5x cheaper and 9.6x faster (vendor-reported).

The cost of the pattern is that you pay for questions whose answers you throw away, and that it only works when the questions really are independent. When the second question only makes sense after the first has been answered, for example “which product” followed by a question whose options depend on that product, the honest design is two requests.

Where it sits in an agent

An agent loop has a handful of decision points that are not really reasoning: which model should handle this request, and is the next tool call safe to run. LangChain’s langchain-typesafe package puts Jev at exactly those points, as middleware for agents built with create_agent.

Install the package, with the experimental extra for the middleware:

uv add "langchain-typesafe[experimental]" langchain-openai
export TYPESAFE_API_KEY=your-key-from-the-typesafe-console

Tool-risk gating, with one destructive tool gated and one read-only tool left alone:

from langchain.agents import create_agent
from langchain.tools import tool
from langchain_typesafe.experimental.middleware import AutoModeMiddleware


@tool
def rotate_database_password(environment: str) -> str:
    """Rotate the application database password in the named environment. Connected clients are disconnected."""
    return f"Password rotated in {environment}."


@tool
def read_service_status(service: str) -> str:
    """Return the current health status of a service."""
    return f"{service}: healthy"


agent = create_agent(
    "openai:gpt-6-astra",
    tools=[rotate_database_password, read_service_status],
    middleware=[AutoModeMiddleware(tools=[rotate_database_password])],
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "Rotate the production database password now."}]}
)
print(result["messages"][-1].content)

Only the tools passed to AutoModeMiddleware are classified, so read_service_status runs without a check. You can replace the default risk question with your own instructions, or describe what counts as risky with NoulCriteria(true=..., false=...). Two warnings in the LangChain documentation deserve repeating. The middleware refuses; it does not pause and ask anyone, so approval needs LangChain’s human-in-the-loop middleware alongside it. And the tool arguments and conversation are sent to TypeSafe to be classified, so secrets should not be in either unless sending them to a third party is acceptable.

Model routing works the same way from the other end:

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import ModelChoice, ModelRouterMiddleware

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(
            model="openai:gpt-5.6-terra",
            criteria="Lookups, extraction and small edits where the target is named explicitly.",
        ),
        "deep": ModelChoice(
            model="openai:gpt-6-astra",
            criteria="Design questions, unfamiliar failures and decisions that are costly to reverse.",
        ),
    },
    instructions="Choose the least costly model that can complete the task safely.",
)

agent = create_agent("openai:gpt-5.6-terra", middleware=[router])
result = agent.invoke(
    {"messages": [{"role": "user", "content": "Which region is the orders table replicated to?"}]}
)
print(result["model_route"].choice)

The router classifies the latest human message once and uses its pick for every model call in the run. That is cheap, and it also means a conversation that starts simple and turns hard stays on the small model until the next run. If that matters, a custom middleware can reclassify on before_model after each tool result. TypeSafeClassifier accepts LangChain message objects directly, so custom hooks (before_agent, before_model, wrap_tool_call) can pass the conversation in as state without converting it. Every classification is traced in LangSmith, alongside the rest of the run, with its token usage.

Both middleware classes are marked experimental, and their interfaces may change without notice. The agent frameworks page covers the orchestration layer they sit in.

The two-model pipeline

The pattern that recurs across the sources, and the one MindStudio concluded fits most of its tests, is not replacing a language model with Jev but putting Jev in front of one.

The economics come from the ratio. If most items need only a label, most of the cost moves to the cheap step, and the generative model runs on a fraction of the input. Where nearly every item needs a written response anyway, the triage step adds a call and saves little.

Use cases that fit, and one that did not

MindStudio also built a Bitcoin bot that chose between buy, sell and hold about once a second, and it lost money in its first hour. The tester’s own conclusion is the right one: answering quickly is not answering correctly, and a fast loop repeats a poor decision more often. Jev is a good fit where the judgement itself is easy for a competent reader and the problem is volume or latency. It does not make a hard prediction easier.

What Jev is not for

• Writing anything. No replies, summaries, explanations or code. Use a generative model, and see the two-model pipeline above for how to combine them.
• Multi-step reasoning. Jev gives snap judgements. A decision that needs a chain of inference belongs with a reasoning model, and possibly with a person.
• Long inputs. The request limit is 64k tokens, and the state plus the longest question must fit in 32k. Long documents need to be split, or handled by a model with a larger context.
• Images, audio or video. State is text only.
• Rules you can write down exactly. If the answer follows from a field value or a regular expression, code is cheaper, faster and never wrong about it.
• Approval. AutoModeMiddleware refuses risky calls; it does not ask a person. For approval flows, see human in the loop. A risk classifier is also one layer of control, not a replacement for narrow tool permissions; the excessive agency page covers the rest.

Limits, versions and data

MindStudio also reports that Jev can be reached through the Vercel AI Gateway and OpenRouter, as well as TypeSafe’s own early access.

Failure modes and how to see them

The speed and cost claims

This section is analysis. It separates what each source reports from how far that supports a decision to adopt.

What TypeSafe reports. Jev answers in 70 to 500 milliseconds end to end, against 3 to 329 seconds for frontier language models on the same work. On its own workflow evaluations it reports being 193.6x faster and 444.6x cheaper, and says real-world gains should be expected at the higher end. The same announcement lists the caveats: the reference answers in those evaluations are the average of two frontier models (GPT-6 Astra and Fable 5.1), so the comparison measures agreement with those models rather than correctness; the evaluation may carry bias; pricing may be subsidised; and the service runs from the US West Coast.

What LangChain reports. Up to 200x faster inference and 400x lower cost on classification tasks, in a post announcing its own integration.

What an independent tester measured. MindStudio ran 1,000 emails against seven rules in about 70 seconds sequentially, and about 6 seconds in parallel, for about nine cents either way. The comparison run on a GPT 5.6-class model, covering one category, took about five minutes and 62 cents. Classifying 1,000 YouTube comments took about five seconds and five cents, and the whole test series came to close to 20,000 requests for under a dollar.

What supports the claims. Three parties with different interests report a gap of the same order. The mechanism explains it without any special pleading: generating even a short JSON answer takes many sequential steps, and Jev takes none, answers questions in parallel and does not bill output. The MindStudio figures are consistent with the published price.

What argues against relying on them. None of the three measured accuracy against labelled ground truth. The vendor’s reference is agreement with two other models, the LangChain figure comes from a partner announcement, and MindStudio’s runs are informal tests by one person, which show speed and cost clearly and correctness hardly at all. The price is described by the vendor as possibly subsidised, so a cost model built on it may not survive. Latency from a single region will be worse for callers far from it. And the middleware that makes agent integration easy is experimental.

Our reading. The speed and cost advantage over a generative model call is well supported for short classification work; the size of the multiplier on any particular workload is not, and accuracy on your data is unknown until you measure it. The reasonable way to adopt Jev is on a decision where a wrong answer is cheap and recoverable, with probabilities logged against outcomes from the first day, and with thresholds set from that evidence rather than from the vendor’s examples.