What Is Jev AI? A Beginner’s Guide to TypeSafe’s System One Model

Most AI models are built to generate something: an answer, a summary, a block of code, or a plan.

But software often needs something much smaller. Which queue should this support ticket enter? How severe is this issue? Does this transaction need review?

Jev is TypeSafe AI’s first System One model, a model designed around these kinds of bounded decisions rather than open-ended text generation. Instead of asking Jev to write a response, an application gives it some state, defines the type of decision it needs, and receives a structured answer that code can use directly. TypeSafe introduced Jev publicly on September 15, 2026.

TL;DR

• Jev AI is a decision model from TypeSafe AI. It takes supplied state and answers structured questions instead of generating open-ended text.
• Jev supports three question types: Choice for selecting between known options, Score for judging something along an ordered scale, and Noul for yes/no probabilities.
• One request can contain multiple independent questions. Jev evaluates them against the same state in parallel.
• Jev complements rather than replaces generative LLMs. Use an LLM when you need writing or open-ended reasoning; use Jev when the answer space can be defined in advance.
• Jev depends on the information you give it. If the decision requires current web information, another system must collect that state first.

What is Jev AI?

Jev AI is a model built by TypeSafe AI for making typed, probabilistic decisions inside software. TypeSafe trains Jev around what it calls calibrated decisions, where the returned probabilities are intended to communicate uncertainty.

A conventional LLM might receive a support ticket and generate:

“This looks like a billing issue and should probably be handled urgently.”

Jev works differently. The application defines the decision before making the request.

For example:

• Which team should handle this ticket?
• How frustrated is the customer?
• Is the customer asking for a refund?

Jev then returns answers in predefined forms that the surrounding application can use in its own logic.

TypeSafe calls Jev a System One model, borrowing the name from the distinction between fast and deliberate thinking. In this context, “System One” is TypeSafe’s terminology for models optimized around fast, focused judgments rather than long-form generation.

A useful mental model is:

Generative LLM: information → generated response

Jev: state + typed question → structured decision

Why build a model for decisions instead of text?

Generative models are useful because they can write, summarize, explain, and create code. But many decisions inside software do not need an open-ended response. A support workflow may only need to decide which department gets a ticket, whether it needs escalation, and how severe the issue is.

Jev defines the expected answer as part of the request. Its typed primitives let an application work with bounded choices, scores, or probabilities instead of generating prose and then extracting a result.

A bounded answer is not automatically a correct one. Jev can still make a poor judgment when the state is incomplete, the question is ambiguous, or the available options do not represent the situation.

How Jev works: state, questions, and answers

A Jev request has two important conceptual parts:

1. State: the information available for the decision.
2. Questions: the judgments Jev should make about that state.

Imagine an application processing this support request:

“I was charged twice for my annual plan. Please refund the duplicate payment.”

The state might also contain the customer’s plan, recent transactions, and refund policy. The application can then ask several focused questions about that same state:

• Which team should handle the request?
• How frustrated does the customer appear?
• Is the customer explicitly requesting a refund?

Jev provides three question types for expressing those decisions: Choice, Score, and Noul.

Choice: pick from known options

Use Choice when the answer must be one item from a predefined set. For a support ticket, the application might provide:

• billing
• technical
• account_access
• other

Jev returns the selected option along with a probability distribution across the available choices and a confidence value. The important constraint is that the application defines the available answers.

If your categories do not cover a real possibility, Jev cannot create the missing category. TypeSafe recommends including options such as other or none of_the_above when the list may not be exhaustive.

Score: place something on a scale

Use Score when the answer lies along an ordered spectrum.

Instead of asking:

“Is this customer frustrated?”

you might define levels such as:

1. Calm
2. Frustrated
3. Very angry

Jev evaluates the state against that rubric and returns a probability-weighted position across the levels. Score questions can contain between two and ten ordered levels. The application defines what the levels mean. That matters because a numerical value without a clear rubric can be difficult to interpret consistently.

Noul: estimate whether something is true

Noul is Jev’s yes/no primitive. It returns a value from 0 to 1 representing the probability that the answer is yes.

For example:

Does the customer explicitly request a refund?

A result near 1 indicates a strong yes, a result near 0 indicates a strong no, and a result around 0.5 indicates uncertainty. Unlike Choice and Score, Noul does not return a separate confidence field. Its probability is itself useful signal.

Choice vs. Score vs. Noul

A simple way to remember them is:

Choice = which one?Score = how much?Noul = yes or no?

Jev can answer several questions about the same state

One of Jev’s more important design choices is that an application does not need to send the same state again for every independent judgment.

Multiple Choice, Score, and Noul questions can be included in the same request. Each question sees the same state and is evaluated independently. TypeSafe says those questions are evaluated in parallel.

For one support request, an application could ask:

Your code can then combine those answers.

For example:

• route the ticket using Choice;
• escalate when the Score crosses a threshold;
• start a refund workflow when the Noul probability is high enough.

This is an important difference between using a decision model and asking a general-purpose model to solve the entire workflow in one prompt. TypeSafe recommends breaking broad judgments into smaller, focused decisions and combining them in code.

How to use the Jev AI API

TypeSafe exposes Jev through its System One endpoint:

POST /v1/systemone

A request includes:

• state: the information Jev should evaluate;
• model: the Jev model or alias to use;
• questions: one or more Choice, Score, or Noul questions.

An illustrative request could look like this:

{
  "state": {
    "message": "I was charged twice. Please refund the duplicate payment."
  },
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this request?",
      "criteria": {
        "billing": "Payments, charges, or refunds",
        "technical": "Technical problems",
        "other": "None of the listed categories"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Is the customer explicitly requesting a refund?"
    }
  }
}

The important separation is state, typed questions, and application logic: Jev evaluates the state against the questions, while your code decides what to do with the answers.

Jev AI vs. generative LLMs

Jev and generative LLMs solve different kinds of problems.

A generative model is the better fit when an application needs writing, synthesis, code generation, explanation, or open-ended reasoning. Jev is designed for repeated, focused judgments where the expected answer shape is known in advance.

The two can also work together. An LLM might investigate or explain a problem, while Jev handles specific decisions that feed into deterministic application logic.

Is Jev just JSON mode or structured output?

No. The distinction is about more than the response format. An LLM using JSON mode is still a generative model. It generates an answer while following a requested structure.

Jev’s task itself is defined as a typed decision. Choice, Score, and Noul constrain the possible result before inference, and the returned values are designed to be consumed directly by software. TypeSafe says answers remain within the options or levels supplied by the application.

That said, a structured answer can still represent a wrong judgment. Type safety controls the form of the output, not the truth of the decision.

What is Jev AI good for?

Jev fits tasks where the application already has the relevant state and can clearly describe the decision it needs.

1. Classification and routing

Use Choice to send a request, document, lead, alert, or task into one of several known categories.

2. Scoring

Use Score when the application needs a semantic assessment along an ordered rubric, such as urgency, severity, relevance, or quality.

3. Guardrails and checks

Use Noul for focused conditions such as whether content violates a particular rule or whether a required fact is present.

4. Tool or action selection

An agent can use Choice to select between approved actions or tools when the valid options are known beforehand.

5. High-volume decision workflows

Because several independent questions can share one state, Jev can fit workflows that repeatedly evaluate records against multiple semantic conditions.

The common pattern is the same: known state + bounded judgment + application-controlled action

When is Jev not a good fit?

Not every AI task can be reduced to a bounded decision. Jev is a poor fit when the application primarily needs:

1. Open-ended writing

If you need an email, article, explanation, summary, or code output, use a generative model.

2. Missing information

Jev evaluates the state you provide. It does not make missing evidence appear.

If a pricing decision depends on today’s competitor prices but the application provides last month’s data, the model is reasoning from a stale state.

3. Complex mathematical operations

TypeSafe explicitly recommends keeping arithmetic and counting in code rather than relying on Jev.

4. Long chains of reasoning

Jev is intended for focused judgments. If the problem requires several dependent reasoning steps, it is usually better to decompose the problem, use code between decisions, or involve a generative model.

5. Decisions with no well-defined answer space

Choice works because the allowed outputs are known. When the possible answers cannot reasonably be enumerated, open-ended generation may fit better.

Jev AI limitations to understand

Typed output removes some failure modes, but it does not remove the need for careful system design.

TypeSafe publishes a “jaggedness” guide for Jev 1.13 documenting current limitations.

Jev can interpret instructions literally

Small differences in wording can change what a question means.

TypeSafe recommends writing the exact condition the model should judge and defining boundary cases in the criteria rather than relying on implied intent.

Math belongs in code

Jev is designed for semantic judgment, not precise arithmetic.

If your workflow needs totals, date comparisons, counting, or deterministic calculations, compute those values in code and give Jev the result when a semantic judgment is still required.

More context is not always better

Large state full of irrelevant information can make a decision harder.

Give each judgment the information it needs rather than treating the model’s context window as storage for everything the application knows.

A valid output can still be the wrong decision

Suppose a Choice question offers only:

• billing
• technical
• sales

A legal request arrives.

Jev still has to work within the choices the application provided. Adding other, unknown, or an escalation path gives the system somewhere to send cases that do not fit.

Current Jev input is text-only

Jev 1.13 accepts text, including text represented in strings, JSON objects, or arrays. Images, audio, and video need to be converted into usable text or structured state by another component first.

Jev AI pricing and current model limits

As of September 28, 2026, TypeSafe lists Jev 1.13 (jev-1.13.0) as its current Jev model. Its published specifications are:

Rate limits are currently described by TypeSafe as dynamic, so developers should check the current documentation before designing around a fixed production limit. At the published input rate, a request containing 10,000 input tokens would cost about $0.00042 before considering any other infrastructure in the surrounding workflow.

TypeSafe reports end-to-end response times of 70–500 ms for its service, while noting that its published speed tests were generally run from laptops on the U.S. West Coast near the service location. Production latency should therefore be benchmarked against the workload and deployment environment.

Where Jev fits in an AI agent stack

Jev solves the decision part of a workflow. Agents often need other systems to collect information before making that decision or act on the decision afterward.

A simplified workflow could look like:

collect state → make decision → apply application logic → take action

For internal application data, collecting the state might be as simple as reading a database record.

For live web information, the application needs a web layer.

For example, TinyFish Search can return structured web search results, while TinyFish Fetch can retrieve and extract content from specific pages. That information can become part of the state passed into Jev. TinyFish’s Agent API can then execute goal-based workflows on websites when an approved decision needs a web action.

A price-monitoring workflow might look like:

TinyFish Search/Fetch → current prices and availability → Jev Score → application threshold → approved action

Jev and TinyFish perform different jobs.

Jev evaluates supplied information and returns a bounded judgment. TinyFish can help an application discover, retrieve, or act on information on the live web.

The main idea behind Jev

Jev represents a different way of deciding where AI belongs inside software. Instead of giving one general-purpose model an open-ended task and asking it to generate the next step, an application can keep the workflow in code and use AI for the parts that require semantic judgment.

That makes the central question less:

“What should the model generate?”

and more:

“What specific decision does the software need help making?”

When the answer can be expressed as a Choice, Score, or yes/no probability, Jev provides a model designed around that interface. When the task requires writing, investigation, synthesis, or open-ended reasoning, a generative model remains the more natural tool.