Most of the calls inside a production agent are not writing. They are deciding: which queue, how urgent, is this tool call safe, does this answer break policy. Today those decisions go to a frontier model that generates a paragraph, which you then parse. A System One model answers typed questions about a piece of state with calibrated probabilities, in one forward pass, for a few thousandths of a cent. TypeSafe's Jev launched the category on 15 September 2026, six open-source clones appeared within two days, and five independent calibration tests have already been published. This leaf is what they found, and what it changes.
An autoregressive LLM produces one token at a time, each conditioned on the last. Ask it "is this ticket urgent?" and it writes a sentence you then parse, hoping the format held. A System One model skips generation entirely. You send it a state (a support ticket, a tool call, a candidate profile, a game frame) and a set of questions, each with a declared answer type. It returns a probability distribution over the allowed answers for every question, in a single query. All questions are evaluated in parallel against the same state, so the tenth question costs tokens but almost no time.
The name is borrowed from Kahneman's fast, intuitive "System 1" thinking, and the vendor positioning is that the model "is more like code: reliable, fast, self-consistent, and type-safe." Strip the marketing and three properties survive contact with independent testing: schema conformance by construction (the output cannot fall outside the options you declared), parallel evaluation (latency does not grow with question count), and probabilities that are usable as a routing signal under conditions this leaf spells out in section 04.
Pick one option from a bounded list of up to 255. Returns the chosen option, a probability per option, and a confidence statistic.
Place the state on an ordered rubric of 2 to 10 described levels. Returns a fractional position plus the distribution over levels.
TypeSafe's name for a yes/no question. Returns the probability that the statement is true of the state, from 0 to 1.
Jev is TypeSafe AI's first public System One model, API-only, trained with a method the company calls Reinforcement Learning for Calibrated Decisions (RLCD). Where RLHF optimises for answers human raters prefer and RLVR for answers a program can verify, RLCD is described as optimising for "epistemically honest probabilities." The training details are unpublished. The public facts are the interface, the price, the limits, and the growing body of third-party measurements. Context limit is 64k tokens per call, with 32k for the state. Python and TypeScript SDKs wrap a single REST endpoint, and the model is also reachable through Vercel's AI Gateway and LangChain's integration.
A call is a state plus a dictionary of named questions. The keys are yours and should be descriptive, because the answer comes back under the same key. Instructions are read literally: the model answers the question you wrote, not the one you meant.
# pip install typesafe-sdk from typesafe import TypeSafe, Choice, Score, Noul client = TypeSafe() r = client.evaluate( state="Gold-tier customer. Third email this week. Order 4471 charged twice, no refund yet.", questions={ "queue": Choice( instructions="Which team should handle this ticket", criteria={"billing": "Payments, refunds, double charges", "shipping": "Delivery status, damaged goods", "technical": "Login, app or integration faults", "none_of_these": "Does not fit any queue above"}), "angry": Noul(instructions="The customer expresses anger or frustration"), "urgency": Score(instructions="How time-sensitive the request is", criteria=["Can wait a week", "This week", "Today", "Now"]), }, ) # r.queue.choice == "billing", r.queue.probabilities == {...}, r.queue.confidence == 0.97 # r.angry.probability == 0.91 ; r.urgency.score == 2.6 (fractional position on the rubric)
Two numbers come back, and they are not the same thing. The probabilities field is the distribution over options. The confidence field is a single statistic derived from the shape of that distribution: concentrated on one option means high, spread out means low. For a three-option Choice the docs give the formula as (3 × p_max − 1) / 2. The docs recommend three bands: above 0.9 act automatically, 0.5 to 0.9 confirm or flag, below 0.5 route to a human, with the threshold set per action according to what a wrong answer costs. A read-only lookup can tolerate a lower bar than a refund.
Independent testers have a sharper recommendation, covered in section 04: threshold on the maximum probability, not on the confidence field, and calibrate per question on your own traffic before you trust either.
The model is the cheap part. The engineering skill being sold is question design: breaking one fuzzy judgment into atomic questions and combining the answers with weights you control in code.
Ask every question you might need in one call, including ones you may not use. Parallel evaluation makes the marginal question nearly free in latency. TypeSafe's own figure for a 13-question briefing is 12x cheaper and 10x faster than sequential calls.
Use the answer as one axis and the probability as a second. High and clear: automate. Middling: confirm. Low: escalate. Different actions get different bars.
Never ask "is this a good candidate." Ask five narrow Scores and weight them in code. The weights are yours, auditable, and changeable without touching the model.
System One model classifies. Code handles the clear majority. A frontier model gets the hard minority. Humans get the low-confidence residue. TypeSafe's worked example: a million tickets for roughly $6,500 instead of $30,400.
An independent shadow evaluation on 2,000 phishing emails asked Jev a single question, "is this phishing?", and got 62.6% accuracy against Claude Haiku 4.5's 81.3%. The same evaluator then decomposed the judgment into five narrow signals (shortened URLs, free hosting, sender domain mismatch, and so on), fitted logistic-regression weights on 1,000 labelled examples, and re-ran. Jev reached 95.0%; Haiku on the same five signals reached 93.2%, a difference that was not statistically significant. Cost per thousand emails was $0.038 for Jev against $0.46 to $1.02 for Haiku. Same model, same data. The only thing that changed was the questions.
TypeSafe's launch numbers (193.6x faster, 444.6x cheaper) come from its own workflows against its own LLM wrapper, and the company says so. What matters operationally is one narrower question: is the probability worth routing on? Five groups measured it within a week of launch. Expected calibration error (ECE) is the gap between stated probability and observed accuracy; lower is better, and a well-calibrated classifier sits near 0.02.
| Test | Task | Finding |
|---|---|---|
| jev-benchmark (Portland, 2026-09-17) | Classify 60 agent tool calls as readonly / destructive / privileged / exfiltration, with adversarial wrappers | 91.7% accurate. 100% on clear cases, 71% on ambiguous, 11 of 12 adversarial caught. Never wrong at confidence 1.0. ECE 0.05 to 0.07. No frontier baseline yet. |
| ASSAY-001 (pre-registered, sealed protocol) | Intent classification on CLINC150 (150 classes) and Banking77 (77 classes) | Calibrated on CLINC150 (ECE 0.020). Overconfident on Banking77 (ECE 0.094). Zero type errors across 8,576 responses. |
| jev-ood-calibration (900 synthetic tickets it cannot have seen) | Queue (Choice), anger (Noul), priority under an organisational rule absent from the text (Score) | 89% on queue, 92% on anger. 45% on the policy question while stating 0.74 average probability. Choice and Score overconfident, Noul underconfident, on the same inputs. Probabilities quantised to 0.01 and often exactly 0 or 1. |
| Phishing shadow eval (2,000 emails) | Single question vs five decomposed signals, against Claude Haiku 4.5 | 62.6% asked once, 95.0% decomposed. Jev struggled with date comparison, double negatives, large irrelevant state, and prompt injection. Wrong criteria text pushed accuracy below the random floor. |
| JevBench v1.2 (534 decisions, 42 systems, 2026-09-21) | Geometric mean of accuracy, calibration, speed and cost | Jev 1.13.0 leads at 75.4. Open-weight SemIf on Qwen3.5-4B scores 74.7, faster and cheaper to run. Jev's calibration sub-score (82.7) is its widest lead. |
Calibrate per question, not per model. The direction of miscalibration flips by primitive: yes/no answers ran underconfident, choice and score answers ran overconfident. One global threshold is unsafe for Choice and Score.
Threshold on the max probability, not the confidence field. On every set where both were measured, the confidence statistic was never better calibrated than the max probability and was sometimes much worse.
It does not know what it cannot know. When the right answer depended on a rule that was not in the text (a tier bump in the priority policy), the model was near chance while stating high probability. That is the exact case a human-routing path depends on. The fix is structural: put the policy in the state or in code, and give every Choice an explicit "none of these" option.
Two claims deserve a plain reading. "Zero hallucinations" is true only in the narrow sense that output cannot fall outside the schema, and TypeSafe concedes the figure "is not empirical." Picking the wrong option inside the schema is measured above. And "cannot prove it isn't subsidised" is TypeSafe's own phrase about its price. Pin a model version (jev-1.13.0) when you tune thresholds; the vendor changes behaviour between releases.
Within 48 hours of launch, six reproductions existed, and by day six a public leaderboard was ranking 42 systems against the same wire format. None reproduces RLCD, because the method is unpublished. All reproduce the interface: Choice, Score, Noul, probabilities per option, one forward pass. That tells you where the durable value sits. The training recipe is TypeSafe's edge for now; the shape of the call is becoming a de facto standard that LangChain, Vercel's gateway, and the open projects all speak.
| Project | Approach | Where it lands |
|---|---|---|
| SemIf (formerly OpenJev) | Qwen3.5-4B backbone with a small NLI classification head on the last token; no retraining of the base | JevBench 74.7 vs Jev's 75.4. The strongest open option; runs on one GPU in-country. |
| Bespoke Nimble | LoRA fine-tune of Qwen3.5-9B with contrastive data curation | Reported 90% against Jev's 93% on the same set, up from a 66% base. |
| djev | Diffusion-based on diffusion-gemma | Fastest on JevBench (91.4 speed), weakest calibration (65.4). |
| Laya | 421M-parameter ModernBERT-large encoder with a decision head | ECE 0.466 as shipped, 0.081 after temperature fitting. Calibration is a post-processing step here, not a training property. |
| NanoJev, Kev-0.5B, mini-jev | Sub-1B models, LoRA adapters, or logit-reading over a frozen vocabulary | Laptop-class. Approximate the interface; trade accuracy for control. |
| GLiNER, SetFit, OpenDecision | Classical encoders, few-shot classifiers, 400M ModernBERT | CPU-only. Where you have a fixed label set and labelled history, a fine-tuned encoder is cheaper and likely more accurate on your own labels. |
The honest reading is that Jev's moat on quality is real but thin, its moat on calibration is the widest and the least reproduced, and its moat on distribution is what it is actually racing to build. Vercel reported Jev in use by about 13% of teams on its gateway within a day. Design for portability: keep the call shape, keep thresholds in code, and keep an open model in the cascade as the backstop.
List price is $0.042 per million input tokens, and output is unmetered, which is honest given that output is a handful of floats. A typical tool-call classification runs about 400 input tokens, so a decision costs roughly $0.000017. In rand that is a few hundredths of a cent at any plausible exchange rate. Latency claimed is 70 to 500ms end to end; independent medians ran 240ms from France and 420ms from the US west coast. Rate limits as documented: 250k tokens per second and 1,200 requests per minute, both subject to change, and the free tier throttles to a handful of requests per minute, which broke one evaluator's concurrency.
The documented jagged edges of jev-1.13 are the ones that bite in production. Literal reading: negations, scoping words and implied conditions land at face value, so write the exact boundary condition. Counting and arithmetic: count in code, or ask one Noul per item. Dates: extract with a Choice over enumerated values plus a "not stated" option, then compare in code. Large irrelevant state: accuracy degrades with padding, so filter in code and send only the fields the question needs. Adversarial content: text engineered to argue for its own classification can move the answer. Contradictory instructions: a Noul mapped as "true means no" underperforms. None of these is exotic. All of them are the difference between a demo and a system.
Three ways to make a bounded decision inside software. Volume, label stability and the cost of a wrong answer decide which is rational.
For a team paying for inference in dollars, this is the rare launch where the cheap thing is also the well-tested thing. The decisions that make or break South African service businesses are exactly this shape: which queue, which adviser, is this claim complete, is this document the one we asked for. Two disciplines make it safe. Filter the state: send the fields the question needs, not the customer record, which is both the accuracy-correct and the POPIA-correct design. Shadow-evaluate before you route: replay a month of decisions your people already made, measure accuracy and calibration per question, and only then set thresholds. The whole exercise costs a few rand in API calls.
Vendor documents for the interface and the claims; the independent repositories for the measurements, each publishing raw responses. Last reviewed 2026-09-21.