desktop[ library ]communitycoursesorbits / membership
<- back to librarytools-and-plugins_
[ notebook ]2026-09-19

Jev: the decision model that doesn’t chat

You do not chat with Jev.

There is no soft opening message. No "what should we build today." Your code posts a state and a list of typed questions. Back come typed answers and probabilities. That is the whole shape.

I keep saying this out loud because every model reflex wants to put you in a conversation. You paste a blob. You hope the model writes something useful. You scrape a label out of a paragraph. It works until it doesn't, and then you are debugging prose instead of branching on a value.

Jev is TypeSafe's System One model. Named after Kahneman's fast side. Built for decisions that software can act on, not for chat as a product. The colloquial "Jev AI" floats around; the official name is just Jev.

What it is

Think of it as a narrow common-sense layer you wire into an app.

You are classifying a ticket. Scoring severity. Checking whether a passage contradicts the query. Guarding a tool call before it fires. The control flow stays in your code. Jev supplies the judgement over messy text.

Under the hood TypeSafe talks about a parallel sampler and training called Reinforcement Learning for Calibrated Decisions (RLCD). You do not need the paper to use it. You need the call shape: state in, questions out as structured values with probabilities and, for most question types, confidence.

System One borrows Kahneman's fast System 1: intuition-speed judgements, not slow multi-hop deliberation. Jev borrows William Stanley Jevons: when the cost of intelligence falls, demand rises. TypeSafe positions that stack against RLHF chat LLMs. Different architecture. Parallel sampling instead of token-by-token prose. Outputs meant for machines to branch on.

Three primitives, and you mix them freely in one request. All of them see the same state. All of them evaluate independently, in parallel.

Choice asks which option. You get a choice, probabilities, and confidence. Category on a support ticket. Intent on a voice banking turn. Whether a quote supports, contradicts, or says nothing about a claim.

Score asks which level on an ordered rubric. You get a score, a legend, probabilities, and confidence. Harm severity. How frustrated the customer sounds. How strong the evidence feels.

Noul asks whether something is true. You get a probability from 0 to 1. Noul has no separate confidence field. That is easy to miss and worth writing down once. Is this a refund request. Is this passage usable evidence. Does this turn need a skill at all.

 Choice Score Noul
 +-----------------+ +-----------------+ +-----------------+
 | which option? | | which level? | | is this true? |
 | choice + probs | | score + legend | | noul 0-1 |
 | + confidence | | + probs + conf | | (no separate |
 | | | | | confidence) |
 +-----------------+ +-----------------+ +-----------------+
 \ | /
 \ | /
 +-------- same state, parallel ------+
Choice, Score, and Noul as three sequential System 7 cards
Choice asks which option. Score asks which level. Noul asks whether something is true.
Choice, Score, and Noul boxes converging on one shared state
Three primitives. Same state. Parallel answers.

As of mid-September 2026 Jev is in early access. The company blog landed on 15 Sep 2026. The homepage still shows Join Waitlist and Sign in. Pin jev-1.13.0, or use jev-latest. Right now jev-preview points at the same build, not ahead of it. Text only. No images, audio, or video yet.

Who it is for: builders where code owns control flow, and the model only needs to classify, route, score, verify, or guard. Who it is not for: generation, multi-hop reasoning, maths, date arithmetic, or anyone hoping for a conversational product surface. English is the strongest language. Test others before you lean on them.

One soft house note. Imaginary Tools is opening in the stack. We are already running Jev-shaped decisions there, and inside CXN. Not a chat demo for the blog. Live product wiring, the kind of place a decision model is meant to sit.

How you use it

One call. State holds the facts. Questions hold the judgements. Code owns rules and side effects.

POST /v1/systemone
+--------------------------------------+
| STATE |
| ticket · order · policy · passage |
+------------------+-------------------+
 |
 +-------------+-------------+
 v v v
 Choice Score Noul ...more
 | | |
 +-------------+-------------+
 |
 v
 typed answers + probabilities
 |
 v
 your thresholds -> act | caution | escalate
State, Questions, and Answers windows chained across a System 7 notebook
State in. Questions out. Typed answers your code can branch on.

State can be a string, a JSON object, or an array of text. Keep it curated. Dumping a whole object that is mostly irrelevant softens the decisions. Point at nested fields with backticked paths when you need them, like `ticket.messages[0].text`. Put the full question in instructions. Question IDs are for your code; they are not sent to the model.

The useful rhythm is almost boring.

Filter the state first. Break a broad judgement into atomic questions. Ask them together. Compose the answers with weights and thresholds you control. Gate what happens next on confidence: act, caution, or escalate to a human or a slower System 2 LLM. Ask speculative questions in the same call when fan-out is cheap. Only make a second request when a later question truly depends on an earlier answer.

Worked beat: support triage

That speculative fan-out pattern is the default shape, not an optimisation trick.

Picture a ticket about an app that freezes on Export. The customer is firm, not raging. They name versions. They say they are not asking for a refund. One request can still carry five judgements at once: a Choice for category, a Score for bug severity, a Noul for whether there are enough steps to reproduce, a Noul for refund intent, and a Score for frustration.

Illustrative only (not a live API run): category lands on bug report. Severity and repro light up. Refund stays quiet. Frustration sits concerned, not churn-threat. Your code enters the bug branch, escalates on severity plus repro, and simply ignores the refund answer. That is speculative fan-out. Not a second round trip "once we know it is a bug."

The speculative fan-out pattern is the docs name for that habit. The parallel questions cookbook shows thirteen questions over a long GDPR page in one call, with TypeSafe's own measurement on jev-1.12 coming back 12.2x cheaper and 10.0x faster than thirteen singles, same answers.

Worked beat: confidence as a gate

Confidence is a second axis. The answer says what. Confidence says whether you should act. High confidence can auto-run. Low confidence routes to review. Calibration is group-level. It is for routing, not for promising any single call is right.

Treat confidence like a gate, not a blessing. Act when the Choice lands clean and confidence is high. Caution when the answer is usable but soft. Escalate when stakes are real and the signal is thin. Your application owns those bands. TypeSafe supplies the assessment. The confidence-gated routing pattern walks stake-based thresholds: a soft floor for ordinary turns, a higher bar before anything irreversible fires.

Worked beat: RAG filter

Retrieval still finds noisy scraps. Between retrieval and generation, score each passage.

Four Nouls per passage: relevant? usable evidence? contradicts the query's premise? prompt injection? Then code thresholds route to evidence, conflict, or drop. A planted forum scrap that tries to override instructions gets dropped before the generator ever sees it. A clean help-centre line about EU trash retention stays as evidence. A US-only retention note soft-drops or carries a caveat you write in code.

Keep the cookbook's honesty: a score is a filter, not a security boundary. Full recipe: classifying RAG passages.

Worked beat: citation check

Agents cite. Sometimes they invent the quote.

Cheap string match first. If the quoted span is missing from the source file, verdict is fabricated with no model call. Surviving quotes get one Choice: relative to the claim, does the quote context support, contradict, or say nothing? Confidence decides whether your agent auto-accepts or a human gets the last click.

That two-stage shape is the whole point. Deterministic where you can be. Decisions-shaped where you cannot. Recipe: citation check.

Guardrails and dates

Screen both sides of an LLM call when you need to. The LLM guardrails cookbook runs hazard Nouls plus a severity Score in one request, then your thresholds choose pass, review, block, or support. Self-harm can route to support rather than a blunt block. TypeSafe's own line sticks: TypeSafe supplies the assessment; your application owns the decision.

For dates, the date extraction cookbook lets the model name the parts it sees, then resolves the calendar in code. The model reads. Your code computes. That is also a jaggedness lesson wearing a friendly face.

Patterns live together at docs.typesafe.ai/patterns. The menu is short on purpose: fan-out, confidence routing, composite scoring, intent routing. You compose them in code. Playground path is the same softness: paste state, add Noul or Choice or Score, watch parallel results land.

What you get in software

What lands in the software is quieter than the launch posts.

You get machine-native decisions. Typed outputs and probabilities your code can if on, without fishing JSON out of prose. The branch is a value, not a paragraph you hope contains one.

You get many judgements per request with little added latency, because questions share one state payload and evaluate independently. Speculative questions stop feeling wasteful. They become the default.

You get a cost and speed envelope aimed at decision-shaped work. List price on the Models page is $42 per billion input tokens, output free. TypeSafe's own workflow evals report large speed and cost gaps versus frontier LLMs on their demos, including figures like ~100 ms for many queries, blog bands of 70-500 ms end-to-end, and high-end multipliers on site. Treat those as vendor-reported. TypeSafe itself notes it cannot prove pricing is not subsidised.

You get confidence as a control knob, and schema-constrained answers that stay inside the option set you defined. TypeSafe argues inventing an out-of-schema value is not how the constrained space works. Typed still does not mean always correct. A wrong choice is still a validly typed choice. Choice tops out at 255 options before a two-stage path.

And you get a clean complement to generative models. LLM generates. Jev decides. Route. Guard. Triage. Screen RAG passages. Check citations. Suggest a skill, then verify it still fits. The control flow never leaves your hands. That is the quiet shift: generation stays generative, and the decision layer becomes something your software can actually own.

Integrations OBSERVED

You will find this shape on the TypeSafe API and SDKs: Python typesafe-sdk, JS @typesafe-ai/sdk, env TYPESAFE_API_KEY, and an agent skill via typesafe-ai/skills.

On Vercel's AI Gateway the model is typesafe-ai/jev, with AI SDK 7's experimental evaluate. On Cloudflare Workers AI it is typesafe/jev through env.AI.run. On OpenRouter the slug is ~typesafe/jev-latest, still Decisions-shaped rather than a chat completion you scrape. LangChain ships langchain-typesafe with TypeSafeClassifier and experimental middleware for model routing and tool-call guardrails. Pydantic AI exposes TypeSafeModel / typesafe:jev-latest, where each output field becomes a question and the prompt is the state.

Everywhere the mental model stays the same: state plus questions. Not a conversation you hope to parse later. Surface names may shift (Vercel's yes/no can read as boolean rather than Noul), but the Decisions shape holds.

Honest edges

Early access is early access. Waitlist still visible as of the research fetch on 19 Sep 2026. Keep that framing until the site says otherwise.

Context, in TypeSafe's Models wording: 64k tokens per request, with 32k for state plus the single longest question. Prefer that wording over marketplace pages that flatten it to "32k".

Maths, counting, and date arithmetic are weak spots. Keep them in code. Let the model read named date parts if you must; resolve the calendar yourself. Large irrelevant state hurts. Contradictory criteria hurt. Indirection hurts. Adversarial content in state can push a decision off course. Schema constraint is not injection immunity. There is no guarantee that a Noul and a Choice about the same fact will behave as structural twins. English is the strongest language. Do not use Jev for generation.

Typed is not correct. Shape is constrained. Truth is not. Confidence routes. It does not bless.

Rate limits on the Models page are dynamic, with published figures like 250,000 tokens per second and 1,200 requests per minute before a 429. Higher limits exist on custom and enterprise plans via sales@typesafe.ai. None of that makes the model omniscient. It only tells you the pipe has edges too.

Trust, softly: TypeSafe's public Privacy Policy and customer agreement say customer Input is not used to train or fine-tune models, and the docs say Jev is not trained on customer requests or responses. Zero data retention is offered for enterprise via privacy@typesafe.ai. This is a public-docs note, not legal advice.

Soft close

Reach for plain code when the rule is deterministic, when the work is arithmetic or dates, when a side effect must fire exactly once.

Reach for Jev when the work is classify, route, score, verify, or guard over unstructured text, and you want typed answers your code can gate.

Reach for a System 2 LLM when you need generation, multi-hop reasoning, or open-ended chat.

Reach for Jev plus a confidence gate when the decision has real stakes, and escalate the uncertain ones.

That is the whole table, told in prose: code for rules, Jev for judgements, an LLM for generation, and a gate when the stakes ask for one.

Docs and Playground live at docs.typesafe.ai. Paste a state. Add a few questions. Watch the parallel answers land. Try one Choice and one Noul on a real ticket, email, or passage. Then put the thresholds in your code, where they belong.

If you are building creative-compute systems where models decide and code holds the last click, this is the kind of dial that fits: narrow, typed, honest about its edges.

Not a chatbot. A decision model you wire in.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_