Jev: When the Right Answer Is a Typed Decision, Not a Paragraph

Most conversations about AI in software still revolve around text generation: prompts in, prose out. But a large share of the decisions that applications actually need to make do not require prose at all. A support ticket needs a queue. A lead record needs a quality grade. A risky action needs a stop-or-continue verdict. Jev is a hosted decision model from TypeSafe AI — often referred to as TypeSafe Jev or Jev AI — built specifically for that second category of work. Instead of writing sentences about what it thinks, Jev returns structured answers that code can act on directly.

That distinction sounds small until you try to put an LLM inside a control flow. The moment a downstream service has to parse free text to discover which of forty routing buckets applies, the reliability advantages of a deterministic system evaporate. Jev’s design takes the opposite approach: the output contract is fixed before the request is sent, and the model’s job is to fill it in.

What Jev Is and Why Typed Decisions Change the Architecture

Jev accepts two kinds of input: application state and typed questions. Application state is whatever record already exists in your system — a support ticket with its subject line and thread history, a JSON object describing a customer, an event payload, a document excerpt. The typed question is a constraint on what shape the answer must take. Jev then returns a decision in one of three forms.

The first is a choice: the model selects exactly one option from a set of up to 255, and returns the selection along with probabilities across the options and a confidence value. That upper bound of 255 matters in practice, because real taxonomies are rarely binary. Routing trees, intent catalogs, product categories, escalation tiers and compliance classifications frequently run to dozens of labels, and a model that can only answer yes/no forces teams to decompose a single decision into a chain of awkward sub-questions.

The second form is a score: a level on an ordered scale of 2 to 10. Ordered levels are the natural fit for anything graded rather than classified — urgency, severity, risk bands, account health, priority. Because the levels are explicitly ordered, the result carries more information than a bare label, and thresholds can be tuned without retraining anything downstream.

The third form is called a noul: a yes/no probability. This is the shape that guardrail logic tends to need. Before an autonomous agent takes an irreversible action, a noul question such as does this request violate the refund policy? produces a number that a threshold can act on, rather than a paragraph that a human must read.

TypeSafe describes Jev as a “System One” model — fast, reflexive, pattern-recognition-oriented rather than deliberative. That framing aligns with the workloads it targets: routing, intent classification, urgency and risk scoring, lead quality assessment, policy checks and guardrails positioned ahead of an AI agent’s actions. In each case, the value comes from a quick, consistent judgment on state that already exists, not from open-ended reasoning. The probabilities and confidence returned alongside every answer are what make the model composable: a low-confidence decision can be escalated to a human or a slower model, while a high-confidence one passes straight through.

For teams that want the full answer-type reference and the exact request schema, the documentation behind Typesafe JEV lays out how state, questions and decision types fit together in practice.

Jev in Production: Pricing, Limits, and the Shape of a Request

The current release is Jev 1.13. According to TypeSafe’s documentation as of October 2026, pricing is $0.042 per one million input tokens with output free of charge. That asymmetry is worth pausing on. In most LLM pricing, generated tokens dominate the bill because reasoning models produce long outputs; with Jev, cost is a function of how much application state you send. Trimming a ticket thread to its relevant messages, or sending a compact JSON record instead of a full serialized object, has a direct and predictable effect on spend, while a longer list of candidate options adds nothing to the output side of the invoice.

The technical envelope is narrow by design. Jev accepts text and JSON input only — no images — and supports a 64k token context. Throughput is listed at 80 requests per second per key, which is ample for many internal workflows but implies a key-sharding strategy for anything with spikier, higher-volume traffic. Official Python and JavaScript SDKs exist, so integration does not depend on hand-rolling HTTP calls. There is no listed free tier, which means an honest evaluation requires a budget line rather than a trial-and-error session on a complimentary quota.

Two further details shape how the service is positioned. First, requests are not used for training, a commitment that matters to teams sending customer records, ticket contents or internal policy text into any hosted model. Second, the model is hosted and managed by TypeSafe rather than self-hosted, so the operational burden is limited to prompt and schema design rather than GPU capacity planning.

Because the output is typed, integration work shifts earlier in the pipeline. Instead of post-processing text, engineers define the decision contract up front: which of the three answer types applies, how many options the choice set contains, what the ordered levels mean, and where the confidence thresholds sit. That definition work is the real integration cost, and it pays off in return values that can be logged, audited, aggregated and thresholded without a parsing layer. A support organization, for instance, can route on the chosen option, escalate on low confidence, and trend the score distribution over time — all from the same response object.

Benchmarking Jev Against Alternatives: What the Numbers Suggest

Jev is not the only model answering typed questions with probabilities. The most directly comparable alternative documented alongside it is DecisionNode, from Bynn Intelligence, Inc. It shares the core premise — structured questions in, probability-weighted answers out — but extends in several directions that Jev does not cover. DecisionNode also reads images and video frames, and it adds number, point and box answer types beyond choice, score and yes/no. Operationally it offers batch discounts, WebSocket streaming sessions and a free tier. For a workload built around scanned documents, product photos, camera feeds or coordinate extraction, the input-type gap alone rules Jev out.

For pure text decisions the comparison is closer, and preliminary benchmarks dated October 2026 sketch a nuanced picture. Across a mean of 15 text suites, Jev scored 0.803 against 0.816 for DecisionNode MoE — a narrow gap that favors the alternative on aggregate text performance. On prompt injection, the spread widens: 0.600 for Jev versus 0.764 for DecisionNode, a meaningful difference for any deployment where untrusted user text reaches the model. Yet on MMLU-Pro, Jev leads clearly at 0.820 against 0.698, suggesting stronger recall and reasoning on knowledge-heavy questions.

Read together, those three results resist a single verdict. A team classifying intent in short, well-formed records is looking at a near-tie. A team processing inbound email, public form submissions or any content an attacker could influence should weigh the injection figure heavily, since guardrail questions are precisely where adversarial input arrives. A team asking policy questions that depend on regulatory or domain knowledge has reason to prefer Jev’s stronger knowledge profile. The benchmark suites are labeled preliminary, and their composition — which 15 suites, how the injection tests are constructed — determines how far the numbers generalize.

The practical conclusion is not to pick a leaderboard winner but to build a small evaluation set from real production data. Pull a few hundred historical tickets, leads or records, hand-label the correct choices, scores and yes/no answers, and run both models against the same typed questions. Measure accuracy per answer type rather than in aggregate, watch calibration as well as raw correctness, and confirm that latency holds under the intended request rate. That exercise, run on your own state and your own decision contract, will say more about production fit than any cross-vendor average.