Jev AI Explained: How It Works and When to Use It

TL;DR

• Jev AI is TypeSafe's System One model for structured decisions. Give it context and a specific question; get a choice, a rubric-based score, or a probability that a statement is true.
• Use it for bounded judgments: routing requests, screening retrieved information, or choosing among known options. Use generative models for writing and code for exact calculations.
• Start with the input/output examples. Clear criteria and relevant context determine whether a question is useful.
• Build a Glasser workflow around endpoint discovery and execution, then add Jev where a decision is needed. In our workflow comparison, code chaining reduced the observed median duration to 1.839 seconds, compared with a 30.016-second original run.

What Is Jev AI, and Why Does It Matter?

Jev is a model from TypeSafe that evaluates questions against a supplied state: the message, document, or structured data you want it to assess. TypeSafe calls this a System One model, designed for quick, narrowly defined judgments whose answers feed directly into software. TypeSafe introduction.

Consider a support workflow. Before writing a reply, the application needs to determine which team owns a ticket, whether it is urgent, and whether it needs a person to review it. These decisions have defined outputs. A selected queue can route the ticket; a relevance probability can determine whether to retain a document.

Jev can evaluate several independent questions against the same state in one request. Questions that depend on a previous answer still need the application to manage that dependency. This distinction matters when designing an agent: combine independent checks, then let code decide what happens next. Question evaluation.

TypeSafe describes its training approach as reinforcement learning for calibrated decisions (RLCD). The goal is for probabilities to reflect how often outcomes occur across many predictions. A probability expresses uncertainty; it does not guarantee that an individual answer is correct. TypeSafe AI primer.

Jev vs. Other AI Models: Which Should You Use?

Choose a model by the work required at each step. An agent may need a generated plan, a bounded routing decision, and a written explanation within the same task.

General-purpose and reasoning-capable LLMs overlap, and some support structured outputs and tool calling. The useful comparison is whether a model handles your specific decision accurately, with acceptable latency and cost. Jev's role is particularly relevant when an agent repeatedly makes small classification or routing decisions. LangChain's Jev integration guide.

For example, a generative model can interpret a research request and prepare the final report. Jev could choose among candidate data endpoints during that workflow. Code can validate the selection and submit the request. This gives each stage a clear job and lets the application move directly from a decision to its next data call.

When Should You Use Jev?

Look for a recurring semantic judgment with a clear answer space. These are practical starting points:

Treat these as application designs. Their quality depends on the context, the criteria, and the decisions your workflow actually needs.

For a first implementation, write one direct question and define what each answer means. Include a fallback such as none_fit when the available options may be incomplete. Keep exact arithmetic, date comparisons, and copying known values in code. Use a generative model when the task requires new prose or an open-ended plan. TypeSafe documents these boundaries in its Jev limitations.

Jev Inputs and Outputs: Three Simple Examples

Each example starts with context and a question. The question type determines the answer format: Choice selects an option, Score evaluates an ordered rubric, and Noul estimates whether a statement is true.

The following JSON snippets show the input and an illustrative answer for each question type. Output values are invented for explanation; response envelopes and some fields are omitted.

Choice: Route a Request

Define the queues and what belongs in each one. A Choice answer identifies the selected option and includes probabilities across the options. Choice documentation.

Input · choice-input.json

{
  "state": "I was charged twice for the same order.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which queue should handle this request?",
      "criteria": {
        "billing": "Charges and payments",
        "technical": "Product errors",
        "other": "Requests outside these categories"
      }
    }
  }
}

Illustrative output · choice-output.json

{
  "choice": "billing",
  "probabilities": {
    "billing": 0.95,
    "technical": 0.01,
    "other": 0.04
  }
}

Here, the application has a queue identifier it can use directly. Choice also returns confidence, a summary of the probability distribution's concentration; it is omitted from this abbreviated display.

Score: Rate a Review Against a Rubric

Use Score when the answers have an order. Define the levels before interpreting the number. Score documentation.

Input · score-input.json

{
  "state": "Search is fast, but exports frequently lose columns.",
  "questions": {
    "sentiment": {
      "type": "score",
      "instructions": "How positive is this review overall?",
      "criteria": [
        "Negative: criticism dominates",
        "Mixed: meaningful praise and criticism",
        "Positive: praise dominates"
      ]
    }
  }
}

Illustrative output · score-output.json

{
  "score": 0.7,
  "probabilities": {
    "0": 0.4,
    "1": 0.5,
    "2": 0.1
  }
}

The score lies on the defined 0–2 scale. A value of 0.7 places the review between the negative and mixed levels. The distribution shows how the model weighs the rubric levels. Score also includes confidence.

Noul: Check Whether a Result Is Relevant

Use Noul for a proposition that can be true or false. Its output is a value from 0 to 1 representing the model's probability that the proposition is true. Noul documentation.

Input · noul-input.json

{
  "state": {
    "query": "Battery recycling technologies",
    "passage": "A process for recovering lithium from used batteries."
  },
  "questions": {
    "relevant": {
      "type": "noul",
      "instructions": "Does the passage describe a battery recycling technology?"
    }
  }
}

Illustrative output · noul-output.json

{
  "noul": 0.96
}

Your application can compare that value with a relevance threshold. Noul has no separate confidence field. For Choice and Score, confidence summarizes the distribution; it should not be read as a measured accuracy rate. Select thresholds using examples from your own task. Understanding confidence.

How to Use Jev with Glasser

Start with a concrete data task. Glasser provides access to data endpoints through search → inspect → run; Jev can participate in the decisions between those calls. In the integration described here, an external program calls Jev through OpenRouter and calls Glasser for data. This requires custom orchestration; Glasser's setup alone does not install a Jev router.

Connect Your Agent to Glasser

Open Glasser. In an agent that can run shell commands, paste this setup instruction into its chat:

set up https://glasser.ai/SKILL.md

Follow the browser login flow, match the displayed code, and approve the connection. The agent installs the CLI and receives a key scoped to your workspace. Glasser setup guide.

Prepare Your First Data Request

Give the agent a specific target, market, and desired output. For the task used in our case study, a starting prompt is:

Using Glasser, retrieve the domain ranking overview for pollo.ai
for Google in the United States, in English.

Search for a suitable endpoint, inspect its required inputs and
price, then run one request within my available balance.
Report the returned metrics, endpoint version, and actual charge.
If the requested market or language is unsupported, explain that.

Search identifies available endpoints. Inspect supplies the selected endpoint's input contract and price. Use those fields to construct the request; then run it and read both its result and charge. Glasser workflow.

Add Jev at the Decision Points

For a developer building the integration, OpenRouter exposes Jev through its Decisions API with state and typed questions. Configure model access separately from the Glasser connection. OpenRouter Decisions documentation.

Keep the first integration focused on these two decisions:

1. After search: send the task requirements and candidate descriptions to Jev. Use Choice to select an endpoint, with none_fit as an explicit fallback. Inspect the chosen endpoint before execution.
2. After inspect: use Choice only for ambiguous parameter meanings or allowed values. Code fills known fields, validates the schema and task constraints, and continues to run. Missing required information should trigger clarification.

For the pollo.ai request, the domain is already known and can be copied directly. A judgment might be needed when several endpoint descriptions appear relevant. Required fields and supported values must still come from inspect.

Use Case: Reducing the Wait Between Glasser Calls

Getting data involves more than waiting for an API response. An agent must compare endpoints, read their input requirements, and construct a request before it can run the call. Model turns, scheduling, and progress updates between these steps can consume more time than the data calls themselves.

The proposed Jev integration places focused decisions inside Glasser's existing workflow:

Jev chooses among candidate endpoints and resolves ambiguous parameter choices. Code copies known values, validates the request, and immediately continues to the next Glasser call. The design aims to shorten repeated decision turns while keeping data access in a single search → inspect → run workflow.

To examine the orchestration overhead, the recorded comparison used the same pollo.ai request for Google US English through domain_rank_overview v2. Parameters and returned metrics were reported as identical. The code chain used a known endpoint.

The code-chain median was 1.839 seconds, 93.9% lower than the original run. Between-call waiting accounted for 86.9% of the original duration, making orchestration the largest observed source of delay. Search also became faster across the runs.

Recorded sample: one original run and three code-chain runs. These timings cover code orchestration. Jev's request hit its monthly quota and returned no decision; its incremental effect remains unmeasured.

Glasser's consistent API workflow makes this optimization practical: keep discovery, inspection, and execution connected in code, and reserve model calls for the choices that need judgment. The result in this example was the same requested data with substantially less waiting.