A First Look at Jev

Jev is a language model that never writes a word. You send it text and a set of questions whose answers you have already defined, and it returns a pick from your options, a position on your scale, or a probability that a statement is true. TypeSafe makes it and calls this kind of model System One, after Kahneman’s fast, intuitive mode of thinking.

This is a first look, not a verdict. I sent Jev 1.13 a reminder-assistant message and three questions, changed the question definitions to see what moved the answers, ran 120 held-out routing requests through Jev, four LLMs and one open local model, then measured what happens to the bill and the clock as you pile more questions into one request. Four things came out of it:

• Jev got 113 of the 120 right, at a median of 304 ms. The cheapest paid LLM on OpenRouter with structured output also got 113, for a fifth of the price, taking twice as long. That LLM stays cheaper per answer even when Jev is at its most efficient, so price is not the reason to reach for Jev. Speed and a short slow tail are.
• Its confidence covers the options you wrote, nothing else. Remove the right option and it picks a wrong one at 0.99 confidence, which on its 0 to 1 scale means as good as certain.
• It gets cheap when you ask a lot at once. Twenty questions about one ticket cost a tenth per answer of asking one, and still came back in 608 ms.
• Its probabilities were the best calibrated as they came. Three sources of a probability got about the same number right. Jev’s sat closest to what happened and its bands separated the safe answers from the doubtful ones. The LLM’s token probabilities separated too but ran overconfident, and the numbers it wrote out shifted with the wording of the prompt.

What it is

An LLM writes an answer you then parse or constrain, and reports no uncertainty unless you ask it to write numbers or dig into its token probabilities. Jev returns typed answers with a probability on each, and nothing else: no reasons, no replies, no code. Several questions about the same input go in one call, because the input is read once and every question is answered against it. That input is the state: a string, a JSON object or an array of text. Text only, no images or audio.

TypeSafe presents this as a new class of model, and not everyone agrees. Nandakishor Mukkunnoth, whose company makes Laya, the open model I test below, says he published the idea more than a year earlier, in an arXiv paper and an r/LocalLLaMA post. His claim is about the idea rather than the code, his earlier work is narrower (one model predicting a sales conversion probability from a conversation), and I found no public reply from TypeSafe. Scoring text against labels chosen at request time is older than both.

Three kinds of question

You supply the options: a label and short description per Choice option, ordered levels for a Score, the statement for a Noul. A Score is not a rounded rating; in TypeSafe’s quickstart a support message scores 1.035 on a three-level frustration scale, just past “Frustrated but civil”. You can mix all three in one request and name each question, so your code reads answers by key.

Noul is the odd name. The docs don’t explain it, but TypeSafe’s CEO did on Hacker News: short for Bernoulli, the distribution for a single yes-or-no outcome. He mapped each type to the code it replaces: a Choice to a match statement, a Score to sorting, a Noul to an if-statement.

The first request I sent

One message, three questions of different types. This set up the reminder assistant the rest of the testing used.

{
  "model": "typesafe/jev-1.13",
  "state": "Please remind me to take an umbrella tomorrow morning. It might rain.",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What is the primary request?",
      "criteria": {
        "weather": "Ask for a forecast",
        "reminder": "Ask to set a reminder",
        "other": "Neither"
      }
    },
    "creates_reminder": {
      "type": "noul",
      "instructions": "Does the user ask to create a reminder?"
    },
    "urgency": {
      "type": "score",
      "instructions": "Rate how soon the requested action is needed.",
      "criteria": [
        "No stated time pressure",
        "Needed soon or on a future specified day",
        "Needed immediately"
      ]
    }
  }
}

The answer, with the repeated type fields stripped:

{
  "answers": {
    "intent": { "choice": "reminder", "probabilities": { "weather": 0, "reminder": 1, "other": 0 }, "confidence": 1 },
    "creates_reminder": { "noul": 0.97 },
    "urgency": { "score": 1, "probabilities": { "0": 0, "1": 1, "2": 0 }, "confidence": 1 }
  },
  "usage": { "input_tokens": 407, "output_tokens": 73, "cost": 1.7094e-05 }
}

About 300 ms and $0.000017: 407 input tokens at $0.042 per million, output not billed. Nothing to parse: the Choice answer is one of the options I defined, and the rest are probabilities over levels I defined.

It gets cheap when you ask a lot at once

Say you have 50,000 legal contracts to sort, and want twenty answers about each: document type, governing law, indemnity clause, how risky the termination terms look. An LLM writes those answers one token after another. Jev reads the contract once and answers all twenty in the same pass, and the answers aren’t billed.

So I measured it: one synthetic support ticket, from a customer whose Stripe connection keeps failing, who was charged twice, who mentions a competitor and wants a phone call. Then the first N of twenty questions about it, for N of 1, 2, 3, 5, 10 and 20. A sample of the questions:

• Choice: which team should handle this ticket, from billing, technical, account or sales?
• Noul: the customer asks for a refund.
• Noul: the customer threatens legal action.
• Score: how likely does this customer look to leave, from not likely to likely?

Jev got them in one Decisions request; Mistral Nemo and GPT-5.6 Terra got the same questions in one strict-JSON call with reasoning off.

Per million answers, so the numbers are readable:

Those are rates, not a bill. The six calls behind the Jev column cost $0.00015 in total, Nemo $0.00005 and Terra $0.008. Jev’s line falls fastest, to a tenth, where the LLMs reach about a quarter: the ticket is read once and its answers aren’t billed. Against Terra that is 30x cheaper per answer at one question and 81x at twenty. Against Mistral Nemo it never gets there: the LLM stays roughly 2.3x cheaper per answer even at twenty questions. Against Terra the gap approaches the two orders of magnitude TypeSafe claims, 81x at twenty questions, on this one ungraded ticket. Against the cheap tail it never gets there: a small old open model still undercuts Jev.

This run priced the requests and timed them; it did not grade the answers, because that ticket has no answer key. The LLMs also returned simpler answers, a true or false for each Noul and a whole number for each Score, where Jev returns a probability for every option. Nemo matched Jev on the labelled test further down, but that is one easy task, and nothing here says its twenty answers about a contract would be worth having.

The clock is the bigger difference. Jev answered one question in 280 ms and twenty in 608 ms, near enough flat; Nemo took 808 ms and 9.3 seconds, Terra 1.1 and 2.0 seconds. Those include OpenRouter’s provider routing, and Nemo’s readings bounced by seconds between runs. At TypeSafe’s published limit of 1,200 requests a minute, one request per contract would clear 50,000 in about 42 minutes, a theoretical figure that also assumes the contracts stay under its 250,000 tokens a second; I did not test sustained throughput. The catch is length: the state has to fit in 32k tokens, and TypeSafe’s own advice is to send only the part a question needs.

Confidence covers the options you wrote, nothing else

I kept the umbrella message and varied the questions around it; one row also appends text to the message. Every row is a real call.

Reordering changed nothing, and that one prompt injection didn’t move the answer. The fourth row is the one to remember: with no right answer on offer it picks a wrong one at 0.99, and confidence runs from 0 to 1, so that is the model saying it is as good as certain. An escape option lets it say “none of these” instead. Confidence describes how the probability spreads across the options you gave, not whether the answer is right in the world. Through all five rows the creates_reminder Noul stayed at 0.97 to 0.98, because it doesn’t depend on what the Choice offers.

A message with two requests in it showed the same split from the other side. For “Tell me the weather and set a reminder to take an umbrella.”:

The Choice was asked for the primary request and gave one, confidently. The Noul, asked on its own, was near certain a reminder was wanted. The Score spread across all three levels with a confidence of 0, which I read as two actions with different urgencies. As TypeSafe’s docs put it, a Choice is relative and settles which option, a Noul is absolute and can be low for every option. A router built on the Choice alone would have dropped the reminder. A plain negation was fine: “Do not set a reminder. Just tell me tomorrow’s weather.” came back as weather, with the reminder Noul at 0.04.

The cheapest paid LLM matched it on accuracy

For accuracy, cost and speed I used a six-label slice of the human-labelled CLINC150 intent dataset (weather, translate, reminder, calendar, to-do list, other), 20 rows per label from CLINC’s own test split. The requests are one line each: “las vegas weather today”, “did i put grocery shopping on my todo list”, “how would i say how are you today if i were mexican”. Every model got the same message, labels and descriptions, one question per request, and the LLMs ran through OpenRouter with strict enum JSON and reasoning off. Mistral Nemo was the cheapest paid model on OpenRouter’s list with structured output when I looked. Laya, an open 421M-parameter model with the same three question types, ran on my Mac’s CPU.

Every model answered all 120. Cost is US cents for the whole run of 120, the DeepSeek row is V4 Flash, and nothing was billed for Laya. The cheapest LLM matched Jev’s accuracy for a fifth of the price: Nemo lists $0.019 per million input tokens against Jev’s $0.042, and Jev counted about 414 input tokens per request where the LLMs counted 180 to 220 for the same content. Five of the seven rows each got wrong were the same rows, four of them reminders, three of which both models filed as to-do items. Terra, the model TypeSafe compares itself with, scored best and cost 34 times as much. TypeSafe’s launch post quotes LLM input prices of $0.20 to $10 per million; the cheap end now goes below Jev.

Where Jev won was time, and this was the LLMs’ best case: reasoning off and a median of 7 to 12 output tokens each, a bare JSON label, where TypeSafe’s 40x to 200x speed claims come from different workloads: longer multi-step tasks, and a Terra demonstration run with its default reasoning on. Even so, Jev’s median was half of Nemo’s and under a quarter of Terra’s, and 95% of its answers came back within 448 ms and the slowest of all 120 took just over a second, where the LLMs’ 95% marks ran from 1.7 to 5.9 seconds and their worst cases from 4 to 12 seconds. Laya’s Brier score, for comparison with the next section, was 0.257; the LLM runs in this table returned labels only.

The limits are real: 120 rows, six easy and evenly balanced labels, one run each, one question per request. CLINC150 is public, so any of these models may have seen it in training. OpenRouter picked a different provider call to call for Nemo and DeepSeek, which shows in their slowest answers, and hosted and local timings measure different things. This says something about this task, not about one kind of model against another.

Jev’s probabilities were the best calibrated

Every Choice and Score answer carries the full distribution plus a confidence computed from its shape: concentrated means high, spread out means low. TypeSafe says the probabilities are trained against outcomes, calibrated across groups of predictions rather than promised for any single answer, and suggests three bands: act when high, confirm in the middle, hand the low ones to a person. Their example sends anything under 0.5 to a person and wants 0.9 plus a confirmation step before approving a transfer.

That is testable, so I tested it on the same 120 routing requests, against the two ways to get a probability out of an LLM: ask it to write the numbers, or read its own token probabilities (logprobs).

The LLM got the same label descriptions and the same instruction about “other” that Jev’s question carried, and the table uses the probability on the chosen answer for all three, so they compare like with like. (TypeSafe’s separate confidence field averaged 93.8% on the same answers.)

All three pick about the same number of right answers. Jev’s probabilities were the best calibrated: a Brier score, which measures how far stated probabilities sat from what happened (lower is better), of 0.066, against 0.141 for the token probabilities and 0.108 for the written numbers. The useful question is whether a threshold separates the answers you can act on from the ones you can’t. Jev’s did on this sample, as it came: the 92 requests it put at 0.99 or above were all correct, and the 18 it put between 0.5 and 0.9 were right 61% of the time. Nemo’s token probabilities separate too, 100% for the 78 requests at 0.99 or above and 81% for the 36 between 0.9 and 0.99, but they run overconfident on average, so a threshold would want setting on your own data. The numbers Nemo writes out barely separate at all: 95%, 96% and 96% accuracy across the three bands, so a threshold on them changes nothing. And these are observations on 120 easy requests, not operating thresholds: any threshold would want checking on your own data before it decides anything, which is what TypeSafe’s own guidance says too.

One thing I learned on the way: the written numbers depend heavily on how you ask. My first run gave Nemo bare label names instead of the descriptions, and its written probabilities came out pointing the wrong way, the 0.5 to 0.9 band all correct and the 0.99 band right nine times in ten. Matching the wording removed the reversal and improved its score, but its written numbers still did little to separate doubtful answers from safe ones. Jev’s probabilities also move with the question and options you give it, as the probes above showed, but they come from training against outcomes rather than from being written out on request.

Two cautions from the docs. Confidence summarises the distribution; it is not a measured chance of being correct. And a threshold tuned on a Noul doesn’t carry to a Choice, because a Choice is relative and a Noul is absolute.

Where it falls down

TypeSafe publishes a list of known weak spots for 1.13, which is more than most vendors do. The short version:

• Maths, counting and dates. It reads numbers and dates as text. Keep arithmetic in code; ask Jev for the parts (a Choice over the twelve months) and assemble them yourself.
• Literal reading and indirection. It answers the question you wrote, not the one you meant, and double negatives cost accuracy. Put boundary cases in the option descriptions.
• Big, noisy input. Irrelevant detail distracts it, and planted instructions can move the answer. Filter before you send. My single injection probe held, and that is one probe.
• Writing anything. Use a generative model, or have one propose candidates and let Jev choose.

What I’d pick, on this evidence

Nemo costs about half of Jev per answer, even at twenty questions. Jev held a 304 ms median with 95% of answers inside 448 ms, where the LLMs’ 95% marks ran from 1.7 to 5.9 seconds, and its probabilities were the best calibrated as they came, where the LLM’s token probabilities needed calibrating and the numbers it wrote out did little to flag doubtful answers however the prompt was worded. Terra was the most accurate, by four requests out of 120, at 34 times Jev’s cost.

For an overnight batch where nobody is waiting, the cheapest paid LLM does this job for less money. For something in a request path, or a pipeline that acts on the confident cases and sends the rest to a person, that is what Jev is selling, and it is where Jev had the edge in this sample.

The bigger limit is that both of my tasks are easy. A one-line request against six obvious labels, and a five-line support ticket. Nothing here touches a long document, dozens of overlapping labels, domain jargon, or the kind of judgement where two careful people would disagree. That is exactly where models tend to separate, and where a small cheap LLM might fall behind a purpose-built decision model, or might not. I haven’t tested it, so I can’t tell you.

How to call it

• TypeSafe directly: POST https://api.typesafe.ai/v1/systemone, or the typesafe-sdk Python package. The alias jev-latest tracks the newest version.
• OpenRouter: as typesafe/jev-1.13, on a separate alpha endpoint, POST /api/alpha/decisions, not Chat Completions. It didn’t appear in OpenRouter’s normal model list, so code that discovers models from that list won’t find it.
• Price: $0.042 per million tokens, charged on input only.
• Limits: text only, 32k tokens for the state plus the longest question, 64k per request.
• Weights: no official open checkpoint. Several open projects copy its request and response shape, Laya among them, but the same shape doesn’t make their probabilities mean the same thing.