All you need to know about Jev (typesafe.ai)

Jev has gotten a lot of hype recently for its speed and classification model. But what is it exactly, and does it replace standard LLMs?

TL;DR

Jev is a fast, constrained classifier. It evaluates input text against fixed options and returns structured choices.

What it does:

• Answers boolean (yes/no) questions.
• Selects options from predefined single-choice lists.
• Returns probability scores and percentages (like 10% or 90%).

What it doesn’t do:

• It’s not a replacement for ChatGPT, Claude, or current text LLMs.
• It doesn’t generate free-form text.
• It can’t answer open-ended questions.
• It can’t summarize text or generate titles from descriptions.
• It can’t extract raw strings like street addresses or names.
• It can’t redact or rewrite text inline.
• It doesn’t handle conditional branching inside a single prompt.

Think of it as filling out a web form with zero free-text fields. Every input maps to checkboxes or dropdowns.

My test case: prefilling task forms

I wanted to test Jev on an automated form-filling pipeline. When a user submits a single sentence describing a problem, the system needs to classify the request and prefill form options.

I sent Jev a description like: “My dishwasher leaks water from the bottom door seal every time I run a heavy cycle.”

I tested six question types against that input:

• Bypass detection: boolean check for contact details.
• Scam risk: percentage score estimating fraud probability.
• Scam detection: boolean check for fraud risk.
• Category: matching the job to a category list.
• Service type: picking the specific task type per category.
• Urgency: selecting ASAP, this week, whenever, or other.

Input prompt and schema example

The input payload specifies the model, the target state text, and a dictionary of questions.

Each question defines its type, specific instructions, and explicit criteria per candidate choice. Adding criteria directly to options gives Jev exact decision boundaries.

For example, distinguishing appliance_repair from plumbing often confuses simple classifiers when a leak is mentioned. Defining a criterion like “The broken thing is the appliance itself, even when the symptom is a leak” resolved edge cases cleanly without long system prompts.

Here’s the full request payload I used:

{
  "model": "jev-latest",
  "state": "My dishwasher leaks water from the bottom door seal every time I run a heavy cycle.",
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "Which trade should handle this job?",
      "criteria": {
        "appliance_repair": "The broken thing is the appliance itself, even when the symptom is a leak.",
        "plumbing": "The building's pipes, taps, drains and fixtures.",
        "electrician": "The building's fixed wiring.",
        "other": null
      }
    },
    "appliance_repair:service_type": {
      "type": "choice",
      "instructions": "Which appliance needs repairing?",
      "criteria": {
        "dishwasher_repair": null,
        "fridge_repair": null,
        "other": null
      }
    },
    "plumbing:service_type": {
      "type": "choice",
      "instructions": "Which kind of plumbing work is needed?",
      "criteria": {
        "pipe_repair": null,
        "leak_repair": null,
        "other": null
      }
    },
    "electrician:service_type": {
      "type": "choice",
      "instructions": "Which kind of electrical work is needed?",
      "criteria": { ... }
    },
    "has_personal_info": {
      "type": "bool",
      "instructions": "Does the text contain a phone number, an email address, or a full postal address?"
    },
    "scam_risk": {
      "type": "score",
      "instructions": "How strongly does this read as an attempt to defraud rather than a genuine request for work?",
      "criteria": [
        "A plain request for work.",
        "Something is off, but a real customer could have written it.",
        "A recognisable fraud pattern."
      ]
    },
    "urgency": {
      "type": "choice",
      "instructions": "When does the customer need this done? If the text says nothing about timing, choose `whenever`.",
      "criteria": {
        "asap": "Something is actively causing damage or is unusable right now.",
        "this_week": "The coming days are named, or the job is blocking but not getting worse.",
        "whenever": "No timing is mentioned, or the customer says there is no rush."
      }
    }
  }
}

Jev response and confidence levels

The actual response from Jev is a JSON document containing rich metadata for every question key. Each field includes confidence scores, percentage distributions across choices, and score level breakdowns.

Here is the classification output from my test run:

category                       appliance_repair    100%
appliance_repair:service_type  dishwasher_repair   100%
plumbing:service_type          leak_repair          84%
urgency                        whenever             58%
has_personal_info              0.01
scam_risk                      0.03  (97% on level 0)

Test results and handling conditional questions

Jev performed well on this pipeline. Response speed was fast because Jev doesn’t stream token-by-token.

The main obstacle was conditional questions. Jev can’t do conditional logic inside a prompt. If a question depends on the category result, Jev won’t branch on its own.

That’s why the input payload includes every subcategory question upfront (appliance_repair:service_type, plumbing:service_type, electrician:service_type).

Because Jev evaluates all questions in parallel, it returns an answer for every key in the payload:

category                       appliance_repair    100%
appliance_repair:service_type  dishwasher_repair   100%
plumbing:service_type          leak_repair          84%   ← discarded
urgency                        whenever             58%
has_personal_info              0.01
scam_risk                      0.03  (97% on level 0)

Notice that plumbing:service_type evaluated to leak_repair with 84% confidence. Because the top-level category scored appliance_repair at 100%, backend code must check the top-level result and discard the unused plumbing branch.

I tested two patterns to handle this limitation:

1. Send all subcategory questions in one query. Jev answers every key at once, and backend code filters out unused branches. This wastes tokens by answering questions that don’t apply, but total latency stays low.
2. Two sequential queries. Ask Jev for category first, then send a second query containing only the sub-questions for that specific category. This saves tokens by skipping irrelevant options, but it adds a waterfall delay from running two network round-trips.

Sending all subcategory questions upfront and filtering downstream gave me lower total latency than accepting the waterfall delay.