Our View on Jev and LLMs: One Brain, Many Reflexes
TypeSafe's Jev answers closed questions in milliseconds with calibrated confidence and cannot generate text. Here is what it is, how it compares with an LLM, and exactly where it slots into an agent harness.
Sep 26, 2026 · 10 min read
A new kind of model appeared this month, and the interesting thing about it is what it refuses to do. Jev, from TypeSafe AI, does not generate text. You give it a piece of text, a question, and a fixed set of allowed answers, and it returns a probability for each answer in around a tenth of a second. It cannot write a paragraph, cannot explain itself, and cannot return anything outside the options you defined. TypeSafe's line is that it is "not an LLM", and for once that is not marketing: it is a description of the architecture.
We have spent the last year writing about what breaks when you put large language models into production loops: the cost of calling a reasoning model for every routing decision, the guardrails that exist in a policy document but not in the code path, the evaluation judges that are themselves unverified LLMs. Jev is a direct answer to a specific slice of that problem. This piece is our view of what it is, where it is useful today, how it compares with the models everyone already runs, and, most usefully, where it slots into an agent harness. We will be clear throughout about which numbers are the vendor's and which are ours.
What Jev is, in one call
The call has three parts. The state is the text to judge: an email, a ticket, a tool output, a description of a game screen. The question is what you want to know about it. The options are the only answers allowed. TypeSafe exposes three question types: Choice (pick one from a list), Noul (how true is this, as a probability), and Score (grade against a rubric). Every answer comes back with a confidence.
The two properties that matter most are easy to miss in the demo. First, the output is schema-constrained by construction. An LLM asked the same question with structured output can still return an option that is not on the list, malformed JSON, or a sentence that begins "this could be shipping or billing". Jev's answer head only scores the options you gave it, so those three failure modes do not exist. It can still pick the wrong option. It cannot pick a non-option.
Second, the confidence is trained to be calibrated. TypeSafe calls the training objective RLCD, and the claim is that when the model says 0.9 it is right about 90 percent of the time. If that holds, and TypeSafe has not yet published a calibration curve, it turns the confidence from a decoration into a control surface: a threshold you can set policy on.
How it differs from an LLM mechanically
An LLM call has two phases. Prefill reads the whole input at once and builds an internal representation. Decode then generates the output one token at a time, each token waiting on the last. Decode is where the seconds go and where the reasoning tokens are billed. Jev, as far as the published material and the community's probing suggest, keeps prefill and removes decode entirely. In place of the language-model head that predicts the next word, an answer head scores each allowed option from the prefilled representation, and a softmax turns those scores into probabilities.
That one change explains almost every number TypeSafe quotes. It also explains the limits: with no decode there is no chain of thought, so there is no reasoning to inspect, no ability to work through arithmetic, and no way to answer a question whose answer is not one of the options. The published architecture claims are a mix of confirmed and unconfirmed; the base model is widely assumed to be a repurposed open decoder, possibly Qwen, but TypeSafe has not said.
The other structural trick is parallel questions. One prefill of the state can feed several question branches at once. Five questions about the same email cost roughly the same as one, because the expensive part, reading the email, happens once.
The numbers, and what we make of them
TypeSafe's launch figures put a Jev decision at 70 to 500 milliseconds against 3 to 329 seconds for a frontier LLM on the same triage job, and the input price at a small fraction of a frontier model's, with output unmetered. On the worked example from the walkthrough we studied, 10,000 support emails a day at 1,000 tokens each, that is roughly an 81-fold difference in annual cost, almost all of it from reasoning tokens the LLM emits and Jev never does.
Our read: the speed claim is structurally credible, because removing decode has to produce it. The cost claim depends on pricing that may be subsidised at launch. The only benchmark we have seen, JevBench, is run by a third party but built specifically for this class of model, and it shows Jev narrowly ahead of several open re-implementations, with a general LLM well down the table and about six times the cost per decision. Independent evaluation on real workloads is the thing missing, and until it exists the right posture is to measure on your own traffic before committing anything to it.
Jev against an LLM: what each is for
| Jev-class decision model | LLM | |
|---|---|---|
| Output | A probability per option; typed; cannot leave the list | Free text, or JSON that usually validates |
| Latency | Tens to hundreds of milliseconds (vendor) | Seconds to minutes with reasoning |
| Cost per decision | Fractions of a cent; output free | Cents to dollars; reasoning tokens dominate |
| Confidence | Calibrated by training objective (claimed, curve unpublished) | Self-reported in text; unreliable |
| Explanation | None | As much as you want |
| Knowledge | Only the state you pass | Broad world knowledge, plus tools |
| Reasoning, maths, dates, counting | Weak; reads literally | Strong, especially with reasoning enabled |
| Many questions per input | One pass, near-zero marginal cost | One call each, or one long prompt |
| Openness | Closed weights, one vendor, early; open clones exist | Both closed and open options, mature |
| Built for | Closed, frequent, System 1 judgements inside software | Open, infrequent, System 2 work: planning, writing, novel cases |
The System 1 / System 2 framing comes from TypeSafe's founder and it is the right one. Kahneman's fast, automatic judgement versus slow, deliberate reasoning maps almost exactly onto "is this spam, which team, is this urgent" versus "draft the reply, plan the migration, explain the anomaly". Most decisions inside software are the first kind. For two years the industry has been paying System 2 prices to make them.
Real-world use, with examples
The community directory that appeared within days of launch already lists several hundred builds. The ones that hold up, in our view, share a shape: a high-volume stream of text items, a small fixed set of decisions per item, and a downstream action that code can take on the answer.
Support and operations triage. Queue, urgency, refund requested, sentiment, language, in one pass per email. The lecture we studied showed a 1,500-email inbox sorted in a single run, and a 500-email run for under four cents. The confidence threshold is what makes this safe: below it, a person routes.
Claims intake. In our piece on the claim intake loop we described extraction, coverage-check and fraud-signal agents feeding a decision gate. Several of those checks are closed questions: is coverage in force, is the claimed peril listed, does the loss date fall inside the policy period, is this a duplicate. Those move to the reflex layer; the ambiguous coverage language stays with the LLM and the adjuster.
Trust and safety. Moderation, spam, jailbreak detection and slop scoring are all Noul questions asked of every item, and the economics finally allow "every item" rather than a sample. One community build scores posts for quality as you scroll.
Unstructured to structured. The demo we watched turned fifty free-text phone reviews into per-aspect star ratings with fourteen questions per review in one call each: seven "is this aspect mentioned" checks and seven satisfaction scores. That is a data pipeline, not a chat feature.
Lead and risk scoring. 700 leads scored in 40 seconds; competitor ad libraries broken down in under a minute. Score questions against a rubric, at a volume where an LLM would be both too slow and too expensive.
Real-time systems. Game characters, live UI adaptation, trading loops making a decision every 300 milliseconds. This is the category TypeSafe labels "not just cheaper, newly possible", and it is the one with no LLM equivalent at all.
# One call, many closed questions, one pass. SDK shape as shown in the
# TypeSafe console; treat names as illustrative and check current docs.
from typesafe_sdk import TypeSafeClient
client = TypeSafeClient() # TYPESAFE_API_KEY from env
email = "We were charged twice for our May invoice and nobody has replied."
r = client.system_one(
model="jev-latest",
state=email,
questions=[
{"id": "queue", "type": "choice", "question": "Which queue should handle this?",
"options": ["billing", "shipping", "technical", "general"]},
{"id": "urgent", "type": "noul", "question": "Is this urgent?"},
{"id": "refund", "type": "noul", "question": "Is the customer asking for a refund?"},
{"id": "tone", "type": "score", "question": "How angry is the customer?",
"rubric": "1 = calm ... 5 = furious"},
],
)
a = r.answers
# a["queue"].choice == "billing", a["queue"].confidence ~= 0.9
# a["urgent"].p ~= 0.8, a["refund"].p ~= 0.95, a["tone"].score ~= 4
if a["queue"].confidence < 0.6: # flat distribution: let a person decide
route_to_human(email, reason="low routing confidence")
else:
route(a["queue"].choice, priority="high" if a["urgent"].p > 0.8 else "normal")
Where it fits in an agent harness
This is the use that interests us most, because it addresses problems we keep running into. An agent harness is a loop: plan, pick a tool, act, observe, verify, decide whether to continue. Today the LLM does every step of that loop, including the closed decisions that do not need it, and the harness pays reasoning-model latency and cost at each one. Worse, the checks that should protect the loop, the safety gate, the verifier, the escalation decision, are either skipped because they are expensive, or delegated to another LLM whose confidence means nothing.
Step through the loop below. Each slot shows where a Jev-class check goes, what it asks, and what the harness does with the confidence.
Which tool, and which model
An agent with twenty tools asks the LLM to choose one on every turn, which costs a full reasoning call for what is usually an obvious decision. A Jev-class model takes the current goal and the tool descriptions as state, the tool names as options, and returns a distribution in around 100 ms. High confidence: call it. Flat distribution: hand the choice back to the LLM, which is the case where you actually wanted the reasoning.
The same trick routes between models. "Does this step need the frontier model or the small one?" is a Choice question, and answering it cheaply is how the expensive model stops being the default.
Is this step safe to take
Before any irreversible action, the harness asks a fixed set of Noul questions about the proposed call: is this destructive, does it touch production data, does it send anything externally, does it match what the user asked for. Each comes back as a probability. The gate policy lives in ordinary code: block above 0.9 on any danger question, route to a human between 0.5 and 0.9, proceed below. The check costs less than the log line that records it.
This is the guardrail layer from our earlier piece on agent guardrails, made cheap enough to run on every step rather than on a sample.
What can be dropped from the window
Long-running agents drown in their own history. The most liked community build on the awesome-jev list rates every past tool call in a Claude session and drops the ones that no longer matter. That is a Score question per item ("how relevant is this to the current goal?") run over the whole context in one parallel pass. The window stays small, the LLM stays sharp, and the compaction decision never touches the LLM at all.
Because every item is scored in the same pass, compacting a 200-item context costs about the same as compacting a 5-item one.
Did the step actually succeed
After a tool returns or the LLM drafts a response, the harness asks: does this output answer the question that was asked, is it grounded in the retrieved context, does it contradict anything earlier, is it on-topic. Today teams either skip this or spend a second LLM call as a judge. A Jev-class verifier runs all four questions in one pass, and its calibration means a 0.6 on groundedness is a real signal, not a hedge.
The LLM-as-judge pattern survives for the open-ended questions. The closed ones, which are most of them, move to the reflex layer.
Finish, retry, or hand to a human
At the end of a loop iteration the harness has to decide whether the task is done, whether to try again, or whether to stop and ask. Asked to the LLM, this is where agents talk themselves into "done". Asked to a calibrated decision model with the goal and the current state, it is a Choice with three options and a confidence you can threshold. Below the bar, the agent stops and a person looks.
Calibration is the whole point here. A model that says 0.9 and is right 90 percent of the time is a model you can set an escalation policy on. One that says 0.9 and means "probably" is not.
What Jev does not replace
Planning, writing the reply, reading a document the agent has never seen, handling the customer whose situation matches none of the options: that is System 2 work and it stays with the LLM. Jev has no world knowledge beyond the state you hand it, gives no explanation, and is weak at arithmetic, counting and dates. In this design it never plans and never writes. It answers closed questions between the steps, thousands of times, for almost nothing.
One brain, many reflexes. The interesting engineering question becomes which decisions are closed enough to move down a layer, and where the thresholds sit.
# A minimal agent loop with the reflex layer inserted. The LLM plans and
# writes; the decision model answers closed questions between the steps.
def run(goal, tools, llm, jev, policy):
ctx = Context(goal)
while True:
step = llm.plan(ctx) # System 2: propose next action
# 1. tool selection (only ask the LLM when the reflex is unsure)
pick = jev.choice(state=ctx.summary(step), question="Which tool?", options=tools.names())
tool = pick.choice if pick.confidence >= policy.tool_conf else llm.pick_tool(ctx, step)
# 2. pre-action safety gate: one pass, several questions
g = jev.ask(state=describe(tool, step.args), questions=policy.safety_questions)
if any(g[q].p >= policy.block for q in g): return escalate(ctx, g, "blocked")
if any(g[q].p >= policy.review for q in g): await_human(ctx, g)
result = tools.call(tool, step.args) # act
ctx.append(step, tool, result) # observe
# 3. context compaction: score every item, keep what still matters
scores = jev.score_many(state=ctx.goal, items=ctx.items, question="Relevance to the goal?")
ctx.keep(i for i, s in zip(ctx.items, scores) if s >= policy.keep_above)
# 4. verification: closed checks on the reflex, open judgement stays with the LLM
v = jev.ask(state=ctx.summary(result), questions=policy.verify_questions)
if v["grounded"].p < policy.grounded_min: llm.revise(ctx, reason=v)
# 5. finish, retry, or escalate: calibrated, so the threshold means something
d = jev.choice(state=ctx.summary(), question="What now?",
options=["done", "retry", "escalate"])
if d.choice == "done" and d.confidence >= policy.done_conf: return ctx.final()
if d.choice == "escalate" or d.confidence < policy.min_conf: return escalate(ctx, d)
Three things change when a harness is built this way. The frontier model is called for planning and for the cases the reflex is unsure about, which is a fraction of the calls it makes today. The safety and verification checks run on every step, because they cost less than logging them, which is what the guardrail lifecycle we described earlier actually requires. And the thresholds become the engineering: which decisions are closed enough to move down a layer, and where each bar sits. TypeSafe's own prediction is that "writing the options and thresholds is the actual work now", and we think that is right.
Our view
Jev is real, the idea behind it is sound, and the category will outlive the product. Non-autoregressive decision heads on top of a pretrained decoder are not hard to reproduce; open re-implementations appeared within a week and sit within a point or two on the only benchmark available. Whether TypeSafe's model or an open clone ends up in your stack, the pattern of a calibrated, schema-constrained, millisecond decision primitive next to a reasoning LLM is one we expect to be standard in agent harnesses by next year.
What we would tell a client today:
Do not replace anything yet. Add the reflex layer alongside the LLM in shadow, log both answers, and measure agreement and calibration on your own traffic for a few weeks. Every number in this article is vendor-reported or from a benchmark built for the category.
Start with the closed decisions you already make badly. Tool selection, safety gates, escalation and context compaction are the four places where an LLM is currently overpaid and under-trusted. They are also the four where a wrong answer is cheap to catch.
Treat calibration as a claim to verify, not a feature to assume. Bucket the confidences, check accuracy per bucket on labelled data, and only then set thresholds. If the curve is off, the model is still useful; the thresholds just move.
Keep the LLM for everything open. Planning, writing, novel cases, anything needing arithmetic, dates or knowledge the state does not contain. Jev has no world knowledge, gives no explanation, and reads literally. Those are design choices, not bugs, and they define the boundary.
Plan for the vendor risk. Closed weights, one provider, launch pricing, a model that can change under you. Wrap the call behind an interface so that an open clone can take its place, and keep the labelled decision set that lets you check whichever model is behind it.
The deeper point is the one TypeSafe's founder made at launch: models have been superhuman at conversation for years, and the automation still has not arrived. Part of the reason is that we have been trying to build reflexes out of a brain. Jev is the first widely available model that is only a reflex, and that turns out to be exactly what the loops around the brain were missing.
Sources
Jev Makes Fast and Cheap Decisions, AI Changes Everything, on the 18 September 2026 launch, RLCD and pricing.
Jev Explained: TypeSafe AI's Non-Autoregressive System-1 Model, MindStudio.
Is the 200x Faster Decision Model Too Good to Be True?, Flowtivity, for the sceptical read.
Daniel Kahneman, Thinking, Fast and Slow, for the System 1 / System 2 framing.
Jev launched on 18 September 2026. Speed, cost and calibration figures are TypeSafe's own unless stated; API names follow the console at the time of writing and should be checked against current documentation.