Jev AI: what it is, how it works, and SaaS use cases

We use LLMs for decisions that often do not need a single generated word.

Should this lead talk to an assistant or to sales? Can this return continue automatically? What action should a copilot take inside a known interface? Does this command look dangerous? Which documents matter for analyzing a risk?

GPT or Claude can handle it. They are still models built to generate tokens.

Jev tries to solve something else: structured decisions your software can consume directly.

It does not replace the LLM. It does not replace code either. Used well, it sits in the space between the two.

Official docs: docs.typesafe.ai/introduction

What Jev actually is

TypeSafe calls Jev its first System One model. Instead of asking for text, you pass a state and questions with a predefined answer space.

state + typed questions
        ↓
       Jev
        ↓
decisions + probabilities

state + typed questions
        ↓
       Jev
        ↓
decisions + probabilities

state + typed questions
        ↓
       Jev
        ↓
decisions + probabilities

There are three primitives:

Full primitive documentation: docs.typesafe.ai/primitives

The difference from an LLM looks small until you put it in code.

How to use it: a realistic example

Imagine a returns SaaS. This message arrives:

The order arrived yesterday but it was broken. I want my money back.

Instead of asking an LLM to analyze the request and emit JSON, you send Jev a state and several decisions:

{
  "model": "jev-latest",
  "state": {
    "message": "The order arrived yesterday but it was broken. I want my money back.",
    "order_status": "delivered",
    "days_since_delivery": 1
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "What should handle this request?",
      "criteria": {
        "automated_flow": "The request can continue through the standard return flow",
        "assistant": "More information must be collected conversationally",
        "human_review": "The case requires human review"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Is the customer explicitly asking for a refund?"
    },
    "risk": {
      "type": "score",
      "instructions": "How risky would it be to automate the next step?",
      "criteria": [
        "Low risk",
        "Medium risk",
        "High risk"
      ]
    }
  }
}

{
  "model": "jev-latest",
  "state": {
    "message": "The order arrived yesterday but it was broken. I want my money back.",
    "order_status": "delivered",
    "days_since_delivery": 1
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "What should handle this request?",
      "criteria": {
        "automated_flow": "The request can continue through the standard return flow",
        "assistant": "More information must be collected conversationally",
        "human_review": "The case requires human review"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Is the customer explicitly asking for a refund?"
    },
    "risk": {
      "type": "score",
      "instructions": "How risky would it be to automate the next step?",
      "criteria": [
        "Low risk",
        "Medium risk",
        "High risk"
      ]
    }
  }
}

{
  "model": "jev-latest",
  "state": {
    "message": "The order arrived yesterday but it was broken. I want my money back.",
    "order_status": "delivered",
    "days_since_delivery": 1
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "What should handle this request?",
      "criteria": {
        "automated_flow": "The request can continue through the standard return flow",
        "assistant": "More information must be collected conversationally",
        "human_review": "The case requires human review"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Is the customer explicitly asking for a refund?"
    },
    "risk": {
      "type": "score",
      "instructions": "How risky would it be to automate the next step?",
      "criteria": [
        "Low risk",
        "Medium risk",
        "High risk"
      ]
    }
  }
}

Official endpoint:

POST /v1/systemone

API: docs.typesafe.ai/api

The response is not an explanation. It looks like this:

{
  "answers": {
    "route": {
      "type": "choice",
      "choice": "automated_flow",
      "confidence": 0.91,
      "probabilities": {
        "automated_flow": 0.93,
        "assistant": 0.05,
        "human_review": 0.02
      }
    },
    "refund_requested": {
      "type": "noul",
      "noul": 0.98
    },
    "risk": {
      "type": "score",
      "score": 0.4,
      "confidence": 0.88
    }
  }
}

{
  "answers": {
    "route": {
      "type": "choice",
      "choice": "automated_flow",
      "confidence": 0.91,
      "probabilities": {
        "automated_flow": 0.93,
        "assistant": 0.05,
        "human_review": 0.02
      }
    },
    "refund_requested": {
      "type": "noul",
      "noul": 0.98
    },
    "risk": {
      "type": "score",
      "score": 0.4,
      "confidence": 0.88
    }
  }
}

{
  "answers": {
    "route": {
      "type": "choice",
      "choice": "automated_flow",
      "confidence": 0.91,
      "probabilities": {
        "automated_flow": 0.93,
        "assistant": 0.05,
        "human_review": 0.02
      }
    },
    "refund_requested": {
      "type": "noul",
      "noul": 0.98
    },
    "risk": {
      "type": "score",
      "score": 0.4,
      "confidence": 0.88
    }
  }
}

The important part: Jev should not decide what happens next. Your code does.

const route = response.answers.route;
const refund = response.answers.refund_requested.noul;
if (route.confidence < 0.70) {
  return sendToHumanReview();
}
if (refund > 0.95 && route.choice === "automated_flow") {
  return startReturnFlow();
}
return continueWithAssistant();

const route = response.answers.route;
const refund = response.answers.refund_requested.noul;
if (route.confidence < 0.70) {
  return sendToHumanReview();
}
if (refund > 0.95 && route.choice === "automated_flow") {
  return startReturnFlow();
}
return continueWithAssistant();

const route = response.answers.route;
const refund = response.answers.refund_requested.noul;
if (route.confidence < 0.70) {
  return sendToHumanReview();
}
if (refund > 0.95 && route.choice === "automated_flow") {
  return startReturnFlow();
}
return continueWithAssistant();

That split matters.

In our piece on agent architecture we already argued that the model is not the system: tools, state, permissions, execution, and policy still live around it. Jev does not change that idea; it makes it more obvious.

Jev or an LLM: a quick rule

There is a third invisible column: code.

If you know the rule exactly, you need neither Jev nor an LLM.

Where it can make sense in a SaaS

The good pattern usually has three traits: natural language or unstructured input, a limited set of possible decisions, and that decision happens often.

Returns and support

A return may require detecting intent, checking for missing information, choosing the right policy, and knowing whether to escalate to a human.

Not every step needs generative reasoning.

A decision layer can return:

• refund

• exchange

• need_information

• human_review

and reserve the LLM for when conversation is actually needed.

Reference benchmark: in an external test on 1,895 real GitHub issues, with the same nine questions per issue, Jev had a total cost of $0.11 versus $18.36 with Sonnet. That is roughly 160x less cost for the same classification load.

The win is not writing a better return email. It is stopping text generation when you only need to choose which path to take.

On full agent cost: the token price is not the cost of your agent.

Lead qualification and routing

Another case is deciding whether a lead should stay with an assistant or move to a person now.

The decision can use signals such as intent, fit, complexity, or urgency:

• assistant

• ask_more_information

• sales

• discard

The LLM handles the conversation. Jev can do the routing.

Reference benchmark: in that same external test, 767 issues were compared to labels maintainers had applied. Jev matched 96% versus 94% for Sonnet. It is not a leads benchmark, but it is a useful signal for routing with known classes: a specialized decision layer can match or beat accuracy without paying for a generative LLM.

Here a few percentage points matter: the failure is not a worse sentence, but sending a good lead down the wrong path.

Smart filters

Marketplaces, travel, insurance, configurators, or B2B catalogs often see requests like:

"I want a quiet hotel, but not an isolated one."

"I need a solution for 200 employees and SSO."

"Which of these vendors fits best?"

An LLM can score options, but with hundreds of candidates you are using generation where you really need scoring or classification.

Reference benchmark: on 1,895 issues and nine questions per issue, Jev took 12.9 s versus 28.9 s with Sonnet: about 2.2x faster. That is well below the 193x maximum TypeSafe published, but probably a more useful product reference: even a 2x gain hurts when the UI chains several decisions.

Document analysis

In credit, insurance, or compliance you can retrieve documents first and then decide:

Does this passage provide evidence?
Does it contradict other information?
Is it relevant to this risk?
Should it be escalated

Does this passage provide evidence?
Does it contradict other information?
Is it relevant to this risk?
Should it be escalated

Does this passage provide evidence?
Does it contradict other information?
Is it relevant to this risk?
Should it be escalated

The LLM can still do the heavy analysis. Jev can filter what is worth sending to it.

Orientative benchmark: when several questions run on the same document, moving from sequential inferences of about 2-3 seconds to 250-400 ms is a reasonable range for this pattern, roughly 5-10x less latency.

TypeSafe documents the pattern of classifying RAG passages before the generative model: classifying RAG passages

The side effect matters too: better filtering upstream means less unnecessary context in the downstream LLM.

Guardrails before running commands or tools

An agent proposes:

git status
npm install
git push --force

git status
npm install
git push --force

git status
npm install
git push --force

You can evaluate:

Is it read-only?
Is it reversible?
Can it delete data?
Can it access secrets?
Does it run remote code

Is it read-only?
Is it reversible?
Can it delete data?
Can it access secrets?
Does it run remote code

Is it read-only?
Is it reversible?
Can it delete data?
Can it access secrets?
Does it run remote code

and then let a policy decide:

ALLOW
CONFIRM
BLOCK

ALLOW
CONFIRM
BLOCK

ALLOW
CONFIRM
BLOCK

Reference benchmark: on the external issue test, Jev reached 96% accuracy versus 94% for Sonnet when a human label existed to check against. The interesting nuance is that both models almost always agreed on relatively objective facts (for example, bug versus feature) and diverged more when judgment entered, such as whether an engineer could start work without asking for more information. For guardrails that pattern matters: concrete, bounded signals can be automated; ambiguous decisions should escalate.

But Jev should not be the permission system.

It can say something looks dangerous. Authorization still lives in code.

We cover that here: AI agent identity, permissions, and limits.

The most interesting case right now: navigating interfaces

One of the projects with the most traction around Jev is browser-use/jev-ultrafast.

The idea is clean.

The browser turns the page into elements:

[1] button     Change ticket type
[2] combobox   Where from?
[3] combobox   Where to?
[4] textbox    Departure

[1] button     Change ticket type
[2] combobox   Where from?
[3] combobox   Where to?
[4] textbox    Departure

[1] button     Change ticket type
[2] combobox   Where from?
[3] combobox   Where to?
[4] textbox    Departure

and Jev chooses among known operations:

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

It does not need to generate a description of what it sees. It decides the next action and which element to use.

For an assistant embedded in a SaaS, the pattern is interesting: the LLM understands what the user wants to achieve and Jev can help decide what to do next.

Repository: github.com/browser-use/jev-ultrafast

Where we would not use it

Jev works worse when we artificially turn a reasoning problem into a hundred independent decisions.

The most debated example right now is compacting agent memory.

Some projects use Jev to score each message or tool call and decide what to keep:

Is this still relevant? (yes / no)

Relevance and memory are not the same thing.

Deciding what information an agent will need later can depend on all the reasoning it has accumulated. A line that looks irrelevant can explain why a hypothesis was dropped twenty steps back.

So we would not assume that:

Is this message still useful?

is equivalent to:

What state does the agent need to keep reasoning?

The second question needs much more than classification.

A project experimenting with this pattern: github.com/tamaratran/fast-jev-compaction

The same applies to math, dates, exact rules, or permissions. If you can write the condition, use code.

If you need generation, planning, hypothesis exploration, or a long chain of reasoning, use an LLM.

Known limitations of Jev 1.13 are documented here: docs.typesafe.ai/model-jaggedness/jev-1.13

"Jev does not hallucinate" needs a lot of context

One of the most repeated lines is that Jev does not hallucinate.

That is only true under a very specific definition.

If you define:

{
  "billing": "...",
  "technical": "..."
}

{
  "billing": "...",
  "technical": "..."
}

{
  "billing": "...",
  "technical": "..."
}

Jev cannot invent:

marketing

The output is bounded by the schema.

But it can pick billing when the right answer was technical.

The popular strawberry example shows it: ask how many r's a word contains and the model can pick a wrong answer among allowed options. It can also change its prediction between runs.

So:

Jev avoids outputs outside the contract. It does not avoid wrong inferences.

For a developer, that means confidence and probabilities are not decoration.

if (decision.confidence > 0.95) {
  execute();
} else if (decision.confidence > 0.70) {
  verify();
} else {
  humanReview();
}

if (decision.confidence > 0.95) {
  execute();
} else if (decision.confidence > 0.70) {
  verify();
} else {
  humanReview();
}

if (decision.confidence > 0.95) {
  execute();
} else if (decision.confidence > 0.70) {
  verify();
} else {
  humanReview();
}

The thresholds above are illustrative. Calibrate them against your product's real distribution and, above all, against the cost of being wrong.

Documentation: docs.typesafe.ai/confidence

If a decision changes system behavior, it should show up in the trace: can you prove how the agent got there?

What the community is already building

Three projects help show where Jev is heading.

Browser Use, Jev Ultrafast. Uses Jev to pick actions and elements during web navigation.

github.com/browser-use/jev-ultrafast

Fast Jev Compaction. Uses Jev to decide which parts of context to keep or drop in Claude Code. It is interesting precisely because it is one of the uses we think deserves careful evaluation.

github.com/tamaratran/fast-jev-compaction

Vercel Eve. Uses Jev in its evaluation layer for routing and tool-related decisions.

github.com/vercel/eve

Evaluation docs: evaluate.md

Community experiments with navigation, memory, routing, and approvals are probably more interesting than another positive/negative sentiment demo.

The rule for using Jev well

Do not ask:

"Can I turn this into a Choice?"

Almost anything can be forced to look like classification.

Ask:

"Do I have a semantic, bounded, repetitive, evaluable decision?"

If you have an exact rule, use code.

If you need reasoning or generation, use an LLM.

If you have a narrow semantic decision that happens thousands of times, Jev is worth a try.

If that decision can change data, spend money, or run an action, do not turn a probability into a permission.

Jev does not remove the system around the model.

It adds a new piece inside it.