Many features in a product come down to a small decision on a piece of text. Which queue should this ticket go to? Is this message urgent? Does this retrieved paragraph actually answer the user's question? You can ask a general chat model these things, but it replies in prose. You then write a parser for that prose, and you still have no clear idea how sure the model was. For a decision that drives code, that is an awkward shape of output.
JEV 1.14 is a decision model from TypeSafe, built for this shape of problem. You send it a piece of context and a set of typed questions. It sends back typed answers that your program can read field by field. This post is about what it takes in, what it gives back, what kinds of judgment it handles well, and where it stops being useful. It is written for developers deciding whether a feature should depend on it.
What JEV 1.14 is
JEV belongs to the family TypeSafe calls System One Models. It reads a situation and makes a judgment about it. It does not generate prose, write code, or hold a multi-turn conversation, so it is not a replacement for a chat model. Third-party coverage dates the 1.14 release to 14 October 2026, as the successor to 1.13.
The distinction matters when you design the system around it. A chat model is a text producer whose output you then interpret. A decision model is a classifier and scorer with a richer output format. You ask a question with a defined answer space, and you get back a structured result for that question.
What goes into a JEV 1.14 request
A request carries three things: the model name, the context, and a set of questions. The context is the text or structured information the judgment is about. Each question has a name you choose, a type, and an instruction that says what to decide. Choice questions also list the options you allow, each with a short description. Score questions list the levels on the scale, from lowest to highest, with a description for each.
Because the answer space is defined by you, the model cannot invent a department that is not on your list. That is one of the main practical benefits: a whole class of parsing and validation work disappears.
What JEV 1.14 returns
The response contains an answers object keyed by the question names you chose. Each answer carries its type. A Choice answer gives the selected option, a probability for every option, and a confidence value. A Noul answer gives a single probability between 0 and 1. A Score answer gives a numeric score, usually fractional, and a confidence.
The response also names the model that actually answered, and reports usage in input and output tokens. Read the model field from every response and store it with the answer. The name you send is not a reliable indication of which version processed the call; in the test, the older name returned the newer model.
The three JEV 1.14 question types in practice
Choice is for routing and triage. Use it when exactly one of several labels applies. The probability spread tells you how contested the decision was. A dominant option at a probability near 1 is a clear case; a flat distribution is a warning that your options overlap or the context is thin.
Noul is for yes/no signals such as urgency or relevance. Its output is a probability, not a boolean, so you need to choose the threshold that triggers an action, and you should choose it from labelled examples rather than from intuition.
Score is for graded judgments such as severity or fit. Its output is a weighted position on your scale. Fractional values are normal. Treat the levels as boundaries you defined, and check that the boundaries match how your team actually grades things.
JEV 1.14 with several questions in one request
A single request can carry several questions over the same context, and each answer is returned as its own field. For a support message, you can ask for the department, the urgency and the customer's frustration level in one call. Your code then combines the three answers, instead of making three calls or parsing one long reply.
This is useful for cost and latency, but it has a limit. The questions share the same context, so if one question's answer depends on another, read the first answer in your code and send a second request. Do not expect the model to chain the answers for you.
What JEV 1.14 adds, and its status
Compared with 1.13, version 1.14 adds three capabilities, and they are not at the same stage.
Image input lets a picture be part of the context, for example a screenshot of an error. The output is still a choice, a probability or a score over your own definitions, not a description of the image. It must be enabled explicitly.
Box is a new answer type that returns a bounding box and a confidence. It is useful when the question is where something is, such as the region of a product photo with a visible defect. The box is the model's estimate, not a precise segmentation, so anything with compliance consequences needs a human review.
The 262K context mode allows long documents in one request. It must be enabled explicitly. Third-party sources describe all three additions as high-risk, and TypeSafe says they are not yet ready for production. Reports also disagree on the context size, so use the official documentation for that number.
None of the three was exercised in the test described below. Treat them as capabilities to evaluate separately, not as tested behaviour.
What the JEV 1.14 test showed
The test ran on 9 November 2026 through the api.crazyrouter.com endpoint. It covered nine requests in total. Eight succeeded. One returned a not-found response because it used an alias that the catalogue does not list. No request timed out. The purpose was to see the shape of the judgments and how stable they were, not to measure accuracy.
Requests were sent to https://api.crazyrouter.com/api/alpha/decisions with the model name jev-1.14.
For a clear support message about an integration failing for three days, the model returned the technical department with probability about 0.92 and urgency 0.98. Repeating the call returned the same department with a probability of 0.91. The labels matched; the numbers moved a little. That is the stability you should expect, and it is why comparisons should use exact equality on labels and a tolerance on numbers.
For a message asking about next month's pricing, with no urgency stated, the model returned sales at 0.99 and urgency 0.05. For a message reporting a suspected double charge, with no verified transaction, it returned billing at 1.00, but urgency was only 0.41. This is the most informative case in the set. The department was clear and the urgency was genuinely uncertain, so the urgency needs its own threshold, a fallback, or a person.
For retrieval, a snippet about the timeout parameter of the requests library was rated highly relevant, with a 0.90 probability of answering the question on its own. A snippet about image models was rated 0 for relevance and 0.02 for answerability. The model separates clear matches from clear misses. Near-miss snippets were not tested.
Latency for the single-question calls in the api.crazyrouter.com run fell between about 0.68 and 0.75 seconds. Input usage ranged from roughly 390 to 470 tokens across the successful calls, and output usage from about 35 to 75 tokens. The single-question example used 380 input tokens and 38 output tokens, so the output side is small for these decisions. Plan for input size, since your context drives most of the cost.
Where JEV 1.14 stops being useful
It cannot write or converse, so it is the wrong tool for anything that must produce text for a reader. It answers only the questions you define, so a vague question produces a vague answer, and a badly chosen set of options produces spread-out probabilities. Its probabilities describe how concentrated its answer is, not how often it is right, so a high confidence is not a guarantee.
It is also the wrong place to make irreversible decisions. Refunds, account freezes and deletions should use its output as one input to a rule or a human check, not as the decision on their own.
Where JEV 1.14 fits
It fits decisions with clear boundaries and a finite answer set, made on text, many times a day: triage, urgency ranking, and filtering snippets before they reach a generator. It is most valuable when the answer is consumed by code, because the typed fields remove much of the parsing that a chat model would require.
A sensible first step is to pick one decision, write its questions precisely, and assemble a set of examples with known answers. Check the labels on those examples before you connect the output to anything that acts. Keep low-reliability questions, such as urgency in the test above, behind a human check until you have evidence they are reliable on your data.
JEV 1.14 summary
JEV 1.14 takes a context and a set of typed questions, and returns typed answers with probabilities or scores, along with the model that answered and the token usage. Its strength is judgments with clear boundaries that code can consume directly. Its limits are that it does not generate text, its probabilities are not accuracy, and its newer image, Box and long-context features are high-risk and need their own evaluation.
JEV 1.14 references
Tracking link (DEV.to version, ID: cr_16fbe997e4ed)
To see decision scenarios in a browser, open the JEV Decision Playground and edit a scenario.
SEO link: the JEV 1.13 guide covers the previous version.
Top comments (0)