Questions readers ask

We give it a state, which is the text to judge, and a list of questions, each with its allowed answers. It returns one typed answer per question, with probabilities. TypeSafe calls its model Jev a "System One model". "Decision model" is the general word that OpenRouter and others use. Start with Chapter 1.

You can, and it works. In experiment 0003, gpt-5.1 got all three answers right on 96.7% of 215 requests, and Jev on 92.1%. But gpt-5.1 took 1,064 milliseconds at the median against 251, and cost $0.756 per 1,000 requests against $0.029. gpt-5.1 wrote the requests, so it had a home advantage. Chapter 16 does the arithmetic.

It cannot write a reply, explain an answer or produce code. The documentation says so, and adds that Jev "is not a calculator". In experiment 0009 a question that needed a sum was right on 92% of 100 cases, and on 100% when our code sent the total. All 8 misses were quotes within 60 of the 250 limit (experiment 0038). Chapter 13 lists the weak spots.

TypeSafe says "System One" comes from Daniel Kahneman's book Thinking, Fast and Slow, and that Jev is named after William Stanley Jevons. "Noul" is short for Bernoulli. That comes from a forum comment by TypeSafe's chief executive, and the documentation does not explain the word.

Ask what your code will do with the answer. The documentation's rule is to prefer the type your code can act on directly. A Choice feeds a match statement, a Noul feeds an if, and a Score feeds a sort or a threshold. Chapters 3, 4 and 5 take one each.

The documentation says up to 255. In experiment 0011, on 80 requests, the model was right on 100% with 6 options and on 92.5% with 255. Experiment 0033 re-read the six misses at 255. Four chose "painting", for requests about scratched or discoloured surfaces, so part of the drop is our label. Chapter 3 has the table.

Because a bare label gives the model nothing to match the message against. In experiment 0006, on 108 requests, bare labels gave the exact level 29.6% of the time and four described levels gave 88.0%. The documentation's advice is to describe situations, not degrees. Chapter 8 shows all the wordings we tried.

Because the number is the answer and the certainty in one. A value near 1 is a strong yes and a value near 0.5 is a shrug. Your code turns it into a decision with a threshold that you choose. A Noul has no separate confidence. If you want one, the documentation suggests the distance from the middle: for 0.98 that is |2 x 0.98 - 1| = 0.96. See Chapter 4.

It is the level numbers weighted by their probabilities. One of our requests had 0.27 on level 1 and 0.73 on level 2, and 1 x 0.27 + 2 x 0.73 = 1.73. The documentation warns against reading the exact distance between two levels from a score. Round it, or compare it with a threshold, as Chapter 5 does.

The documentation says this version leans toward the option listed first. At six options we saw no such lean: across six fresh orders the first-listed option won 16.5% of calls on 291 requests and 15.0% on 60 close calls, where no effect gives 16.7% (experiment 0042). Order did have a modest effect. The trade changed on 4 of 291 messages and 3 of 60, against 0 and 2 when one order was sent six times (experiment 0044). On close calls the winner's probability moved by a median of 0.07 across orders and 0.03 across identical calls. The winner changed only on messages torn between two trades. Longer lists were not tested.

TypeSafe publishes the formulas. For a Choice it is how far the top probability sits above an even split. With six options and a top probability of 0.96, that is (0.96 - 1/6) / (1 - 1/6) = 0.95. In experiment 0014 the formulas matched the returned values within 0.006. Chapter 6 works through them.

No. It means the model did not hesitate. In experiment 0004, severity answers with confidence below 0.50 were right 38.5% of the time, and those above 0.97 were right every time, so confidence is useful. But in Chapter 21 a thank-you note was filed under heating with confidence 0.94.

TypeSafe says the model is trained for calibrated probabilities, and publishes no chart to show it. Our answer depends on whose truth we use. Of 30 requests given a danger probability between 0.5 and 0.7, 20.0% were dangerous by our severity label, in experiment 0010. That label was written for a different question. When three language models read the Noul's own statement and voted, 73.3% of the same 30 were dangerous. That is experiment 0029, and its readers were models, not people. Jev's Brier score, an error measure where lower is better, was 0.080 against the old label and 0.073 against the readers. Chapter 6 explains both.

Nearly. In experiment 0005 we sent five requests 30 times each. The chosen trade never changed in 150 calls, and the severity score of one unsure request moved between 0.59 and 0.77. In experiment 0032, with 100 requests sent 10 times each, the trade changed on none and the desk's route changed on 5. See Chapter 15.

Anything that has an exact answer: sums, counts, dates and look-ups. In experiment 0041 a question about a 14-day limit, on 100 distinct pairs of dates, was right on 93 from the raw dates and on 100 when code sent the number of days. All 7 misses were open exactly 14 days. Rewording changed the count and did not remove the misses. In experiment 0040, on 100 varied date pairs per wording, "more than 14 days" was right on 94, "at least 15 days" on 97 and "14 or more days" on 79. Chapter 10 gives the test for splitting a task.

No. The documentation says unrelated material costs accuracy. In experiment 0008 we added 150 old messages and accuracy barely moved, but our noise was easy to tell apart. The bill did move: from $0.000030 to $0.000720 per call, 24 times more. Chapter 7 is about the state.

From labelled examples and from the price of each kind of mistake. In experiment 0010 the rule "miss nothing dangerous" gave 0.41 on one half of the data. On the other half it caught 33 of 33 dangerous requests, with 23 false alarms. Never choose a threshold and report it on the same rows. Chapter 12 has the method.

The documentation says questions in one call cannot see each other. In experiment 0007 the trade probabilities of 12 requests were the same asked alone and asked among 30 questions. On 30 unsure severity scores the mean gap was 0.011, inside the mean spread of 0.054 between identical calls (experiment 0037). The documentation says a second request is needed only when your code cannot build it without the first answer. Otherwise ask everything at once, as in Chapter 9.

It fills fixed phrases. The model picks the trade and the level, and code looks up the promise. Experiment 0045 checked the 94 automatic replies of experiment 0017 and found no promise outside the policy. Experiment 0030 ran the fuller design of Chapter 11, a catalogue of five candidates. With nine questions in one call and no gate, the whole reply was right on 96 of 107 requests, which is 89.7%.

They go to a person. In experiment 0017 the gate handed 13 of 107 requests to a person, and the model's level was wrong on 3 of them. We also tried sending those 13 to gpt-5.1. It was right on 10, the same count as Jev alone, and the cost rose from $0.029 to $0.120 per 1,000 requests (experiment 0024).

Yes. In experiment 0012 we took 60 mild requests and typed a fake staff note inside each. Jev, gpt-5-mini and gpt-5.1 all put 100% of them at level 3. Chapter 14 is about this.

An instruction that fences the message off as text to be judged and not obeyed. It brought Jev's forced share to 0%, and real dangers were still found: 46 of 47 with and without the fence. Putting staff notes in a field of their own was not enough. A fake note in the tenant's text still moved 31 of 60.

TypeSafe guarantees the shape of an answer: a Choice returns one of your options. It does not guarantee the right one. In 215 requests we saw one wrong trade, a sparking hob sent to electrical when the label said appliance. And a message that fits no option still gets one, unless you offer other. With it, 38 of 40 off-topic messages went there in experiment 0025.

The documentation says English is the main training language and accuracy is lower elsewhere. In experiment 0013, with the questions left in English, trade and permission were right on 100% in six languages. Severity was right on 96.7% in English and on 90.0% to 95.0% in the other five.

TypeSafe says it does not train on customer requests and offers zero data retention to enterprise customers. It publishes no default retention period. Our calls went through OpenRouter, which has terms of its own. We tested none of this. Read both policies before you send anything private.

We measured a median of 251 milliseconds and a 95th percentile of 386 for three questions, in experiment 0002. TypeSafe says "about 100 ms" on one page and "70ms-500ms" on another. Ours include the trip from a laptop through OpenRouter.

Our desk call used 694 input tokens on average. The published price is $0.042 per million input tokens, and output is free. So 694 x 0.042 / 1,000,000 = $0.000029, or about $29 for a million requests.

Hardly. In experiment 0007, on 12 requests, one question took 222 milliseconds at the median and 100 questions took 305. Each extra question added about 50 input tokens. So Chapter 9 says to ask everything in one call.

Mostly not to the message. In experiment 0027 the smallest call we made, a one-word state and one bare Noul, used 272 tokens. The 33 words of our first message added 41. The trade Choice with its six descriptions added 147 more than a bare Noul, the severity Score 102 and the permission Noul 63. That makes the 625 tokens of the first call: 272 + 41 + 147 + 102 + 63.

In experiment 0016 Jev judged "has the caller finished?" correctly on 40 of 40 written examples, with a median of 231 milliseconds. We used typed text only, so pauses and tone were not tested. In experiment 0034 five more decisions shared one call at a median of 216 milliseconds and were right on 21 to 24 of 24 written moments. Chapter 19 builds the budget.

It is the same idea with different field names. OpenAI's guide describes POST /v1/decisions with the model gpt-6-luna, in public beta, at $0.10 per million input tokens. We could not call it: we had no key, and it was not on our Azure resources on 7 October 2026. So Chapter 17 rests on the guide alone.

According to the guide, state becomes input, the questions become an array in which each has a name, a Noul becomes a predicate, and options and levels become arrays of small objects. The guide also shows an answer of type refusal, which Jev lacks, and image input.

By list price per input token, Jev: 0.10 / 0.042 = 2.4 times cheaper. But the two may count tokens differently for the same request, and we could not measure OpenAI's count. Treat 2.4 as the ratio of two price tags, not of two bills.

It is not public. TypeSafe says it has a new architecture, a parallel sampler and a training method called RLCD, and has published no paper. Anything more is a hypothesis. Chapter 18 explains the ideas such a model could be built from, and labels them as guesses.

Yes, in two ways, and we tried both in experiment 0018 on 281 requests. Asking gpt-5.1 for one word and reading its own probability of "yes" gave numbers that were almost always near 0 or 1: only 3.2% fell between 0.1 and 0.9. Asking gpt-5.1 to say a number did better: a Brier score of 0.088 against our severity label, where Jev had the best score of the four ways, 0.080. Against the readers' vote of experiment 0029 the four scored 0.063 to 0.073 and Jev was not the best, though gpt-5.1 was one of the readers (experiment 0038). Chapter 18 has the table.

A key and one HTTP request with three fields: model, state and questions. We used OpenRouter's endpoint, https://openrouter.ai/api/alpha/decisions, with the model typesafe/jev-1.13. Chapter 2 reads it field by field.

A versioned one. TypeSafe's documentation says the alias jev-latest moves when a new release ships, so answers can change without any change on your side. If you tuned thresholds, pin the version they were tuned on.

No. The documentation says the same weights serve every account, and the request has no temperature and no seed. What you tune is the wording of your questions and the thresholds in your code.

We know of no published number. Count the mistake you care about: if it happens once in 100 requests, 200 examples will show it about twice, which is too few to set a threshold on. Our 215 requests are far too few to say anything about rare errors.

One question on real messages of your own, with 50 answers checked by hand. Then the desk of Chapter 21: facts, one call, a gate, templates and an audit line. Then play with the gate in Chapter 22 before you choose your thresholds.