What Is Jev AI? TypeSafe's System One Model, and Where It Fits in an Agent Harness

Agents run in a loop. A model decides what to do, a tool executes, something evaluates the result, and the loop continues until the task is done.

Agents were hard to put inside real software at first, because software wants structured data and predictable interfaces. Two primitives fixed that:

• Tool calling let models make structured requests.
• Structured outputs let models return structured results.

Even with both in place, the loop is still slow and costly. Every decision inside it is another model call.

Jev is a new model from TypeSafe AI, released on September 15, 2026 alongside a $40 million seed round led by DCVC. TypeSafe calls it a System One model, and it does not generate text. You send it program state and typed questions; it returns typed answers with calibrated probabilities, every question in the request evaluated in one parallel pass. The company reports 70ms to 500ms end to end and $0.042 per million input tokens with output free. LangChain shipped an integration two days later.

Most turns in a production loop are not open-ended reasoning. They are multiple-choice questions with the answers known in advance, billed at essay prices: a router picking between two models, a gate deciding whether a shell command is safe, a validator deciding whether a scrape came back usable. Those are the turns Jev is built for.

This post covers what Jev is, how it plugs into a LangChain agent loop, what the documented use cases and the published evals actually show, and, from a team that builds agent harnesses for clients, which decisions to hand it first and which never to hand it at all.

Key Takeaways

• Jev is a System One model from TypeSafe AI. It takes unstructured program state plus typed questions and returns typed answers with calibrated probabilities. It does not generate text.
• Because it never produces a string, it cannot produce a type error or a hallucinated value. The possible answers are defined before the call. TypeSafe calls type safety mathematically guaranteed rather than empirically measured.
• Three question types cover the surface: Choice picks from options, Score rates against ordered levels, Noul answers yes or no. Many questions about one state are evaluated in parallel in a single request.
• TypeSafe reports 70ms to 500ms end to end and $0.042 per million input tokens with output free. The headline speed and cost multipliers come from the company's own workflow evals and carry the company's own caveats.
• LangChain exposes it through TypeSafeClassifier, plus experimental middleware for model routing and tool-risk gating.
• The rule we use: move the decisions where you can list the valid answers in advance and where being wrong is cheap to catch. That means guardrails and classification first. Anything that needs a string, and anything irreversible, does not move.

What Is Jev AI?

Not an LLM, and not a small one either

The easiest mistake is to file Jev as a cheap classifier model. TypeSafe's own framing is sharper than that. An LLM is trained with reinforcement learning from human feedback or verifiable rewards, optimizing for responses people prefer or outputs a program can check. Jev is trained with what TypeSafe calls Reinforcement Learning for Calibrated Decisions, optimizing for something different: answers whose stated probabilities are honest. An LLM samples sequentially, one token conditioned on the last. Jev samples in parallel, producing every output in one query. An LLM returns strings, which are flexible enough to be a chat response, working code, a refusal or a hallucination, and which software has to parse and validate before trusting. Jev returns typed values whose shape was fixed before the call.

Founder Diogo Almeida frames the whole company around a question rather than a capability: models have been superhuman at chat for years, so where is all the automation. He spent four years on that. At OpenAI he helped build the methods that made language models useful at following instructions and talking with people, work he says ended up as the research behind ChatGPT. TypeSafe was founded in 2024 with Erik Gafni and Sasha Sheng, spent two years in stealth, and launched alongside a $40 million seed round led by DCVC.

His shorthand for what Jev is: a frontier-intelligence function call. Unstructured state in, typed probabilistic decisions out.

What a call actually looks like

You send a state, which is the context, and a set of questions about it. Here is the support-ticket example from the TypeSafe quickstart, cut down to a single question as LangChain reproduces it:

{  
  "model": "jev-latest",  
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",  
  "questions": {    
    "is_urgent": {      
      "type": "noul",      
      "instructions": "The message conveys urgency or time-sensitivity"    
    }  
  }
}

Single-question cut-down as published by LangChain. The quickstart's own version asks three questions at once. LangChain | TypeSafe quickstart

Jev returns this, with the response envelope stripped out:

{  "is_urgent": {    
  "type": "noul",    
  "noul": 0.999  
}}

A 99.9% probability that the message is urgent. This figure is LangChain's. Source

One thing worth knowing before you build against it, because it is the kind of detail that gets lost in secondhand write-ups: that is not the whole response. The live API wraps every answer inside an answers object and returns the resolved model version and a token count alongside it, so the real shape is closer to {"model": "jev-1.13.0", "answers": {...}, "usage": {...}}. The quickstart's own three-question version of this same ticket returns 1.0 on that urgency question rather than 0.999, which is a useful reminder that these are live outputs from a model still in early access, not fixed constants to quote.

That 0.999 is what separates this from a classifier call. You did not get back the word urgent. You got a number your code can threshold, log, and compare against last month. A language model asked the same question returns the string "yes" and, asked for a confidence, tends to say 95% about everything. TypeSafe's argument is that a model which can do a task 95% of the time but cannot tell you when it is in the 5% has not automated the task.

The numbers, and whose numbers they are

Every performance figure below is TypeSafe's, from their launch post and their published workflow evals. We have not run Jev against a client workload yet, so we are reporting the vendor's claims as vendor claims and reproducing the caveats they attached, which are more candid than most:

• End-to-end response time of 70ms to 500ms, which TypeSafe describes as 40x to 200x faster than frontier models for System One shaped queries. Their published evals are run from laptops on the West Coast, where the service is based.
• Input at $0.042 per million tokens, output free. TypeSafe notes plainly that they cannot prove the pricing is not subsidized and that the long term will have to demonstrate it.
• The 193.6x faster and 444.6x cheaper figures on their homepage come from the workflow evals, not from the side-by-side demo. Those evals use the average of GPT-6 Astra and Fable 5.1 as the reference answer. TypeSafe says the numbers are on the higher end of real world gains, that the workflows were built by their own model-capabilities team so some bias could exist, and and that using OpenAI and Anthropic models to build the reference likely understates both their own model and DeepSeek's.
• No type errors, which is the one claim TypeSafe treats as structural rather than measured. Schema matching is guaranteed by construction, so a single counterexample would falsify it and none is possible. Their hallucination comparison, by contrast, is explicitly flagged as not empirical.

Reproducing a vendor's own hedges is not throat-clearing. It is the difference between a number you can bring to an architecture review and a number you read on a homepage. TypeSafe published theirs; the dozen explainers that went up in the following week mostly did not.

The Three Question Types: Choice, Score and Noul

Everything you can ask Jev fits one of three shapes, and the shape determines what comes back.

• Choice. Pick from a set of options. You get a probability for each option plus an overall confidence score. This is intent classification, category assignment, routing between named branches.
• Score. Rate an input against ordered levels such as low, medium and high. You get a continuous score, the distribution underneath it, and a confidence value. This is severity, priority, risk level, quality.
• Noul. Answer a yes-or-no question. You get the probability that the statement is true. This is the one you reach for most in a harness: is this urgent, is this in scope, did the tool succeed, is this a jailbreak attempt.

The parallel questions are the actual feature

You can ask many questions about the same state in one request, and LangChain's write-up puts the consequence plainly: every question in a request is evaluated in parallel, so adding questions barely changes the response time and costs only the tokens for the extra questions.

That is what turns Jev from a classification endpoint into a harness primitive, and it is the detail most of the explainers mention and then walk past. A classification API answers one question per call, so a harness that needs four checks pays four round trips and you start rationing which checks are worth it. Here the state is uploaded once and interrogated from several angles at once. Is this ticket urgent, is it in scope for this agent, is it a refund request, does it look like a prompt injection attempt, has the customer asked this before. One call, one latency, four answers, each with its own probability.

Once checks are close to free, you stop designing around their cost. That changes what you are willing to put in a loop, which matters more than the headline multiplier does.

How to Use Jev With LangChain

LangChain shipped an integration two days after launch. It exposes Jev through TypeSafeClassifier. You pass state and questions to .invoke() and get classification results back rather than a chat response. Install langchain-typesafe, set TYPESAFE_API_KEY, then:

from langchain_typesafe import Noul, TypeSafeClassifier 

classifier = TypeSafeClassifier() 
  
response = classifier.invoke({    
  "state": (        
    "The deploy failed twice and customers are seeing 500s. "
    "Can someone look now?"    ),
  "questions": {        
    "urgent": Noul(            
      instructions="Does this need attention right now?"        
    ),
               
  },
}) 
  
urgency = response.nouls["urgent"].noul

Reproduced from LangChain's integration post. Source | LangChain docs

The state can be text, structured data, or LangChain messages, which is the part that makes this cheap to adopt. You are not building a new context pipeline. Whatever your agent already holds at that point in the graph is a valid state, so the call drops into a node or a middleware hook without restructuring anything around it.

Where the call actually goes in the graph

LangChain tells you the call works from a node or a middleware hook. Having built a number of the loops an agent actually runs, there are three positions worth naming, because they answer different questions and they fail differently.

• Pre-model, on the way in. State is the incoming request. Routing, scoping, intake classification. A wrong answer sends the turn down the wrong branch, usually recoverable and usually visible.
• Tool-call interceptor, between the decision and the execution. State is the proposed call and its arguments. This is the risk gate, and a wrong answer here executes something it should not have. It is the position that needs the deterministic layer described below.
• Post-tool validator, on the way back. State is the tool result. Did the scrape return the page or a captcha, did the API return data or an empty success. A wrong answer feeds bad data into the reasoning step, where everything downstream still looks plausible.

Send the question only the state it needs at each of those positions, rather than handing over whatever the agent happens to be holding. TypeSafe is explicit that accuracy falls as the state fills with content unrelated to the decision, and the path of least resistance in a harness is always to pass the whole context along.

At every one of those call sites, log the question text, the returned probability and the branch you took, keyed to the run. Not the decision alone, the probability. You will need the distribution later to set thresholds, and if you only stored the branch you will have to re-run everything to get it back. This is the cheapest thing to do on day one and the most annoying to retrofit.

‍

Use Case 1: Model Routing

A refund-policy lookup does not need the model that handles a multi-step debugging task, but most agents give both the same one because picking between them costs a call. LangChain's routing middleware lets Jev make that pick:

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (    ModelChoice,    ModelRouterMiddleware,) 
  

router = ModelRouterMiddleware(    
  choices={        
    "fast": ModelChoice(            
      model="openai:luna",            
      criteria="Direct lookups, extraction, and localized changes.",        
    ),        "powerful": ModelChoice(            
      model="openai:sol",            
      criteria="Architecture and high-stakes decisions.",        
    ),    
  },    
  instructions="Choose the least costly model that can complete the task.",
) 
  
agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

The router classifies on the latest user message and that choice holds for the run, with the probabilities and confidence still available in agent state. Four things decide whether this works in production.

Measure the break-even, and write the criteria like a stranger has to apply them

Routing adds a call to every request in order to remove cost from some of them. At Jev's pricing that call is close to free, which is exactly why it is easy to skip the arithmetic, and the arithmetic is still what tells you whether this was worth building. Take the share of traffic that actually routes down, multiply by the per-request cost difference between the two models, and set it against the routing cost plus the latency you added to every request including the ones that did not move. If ninety percent of your traffic is complex, you have built a small tax on your whole loop and saved almost nothing. That is a fine thing to discover in a spreadsheet and an expensive one to discover in production.

We have had to run this arithmetic on agents operating over large ecommerce catalogs, where the volume is high enough that a fraction of a cent per decision compounds into a real number either way.

The criteria strings are the actual interface. The model is answering a Choice question whose options are your named branches, so the answer is only as good as whether those branches are distinguishable in words. Make them mutually exclusive, so a request satisfying one does not plausibly satisfy the other, and make them testable, meaning you can read the criteria against a real request and say which it matches without consulting your own intentions. "Complex tasks" fails both. "Requests that touch more than one system of record" passes both.

Keep the confidence and use it

The probabilities stay in agent state, which is not a debugging convenience, it is the escalation mechanism, and TypeSafe documents it as a pattern in its own right: confidence is a second axis, where the answer tells you what and the confidence tells you whether to act on it.

Route to the cheap model on a confident classification and route to the capable one when the router is unsure. A low-confidence routing decision is the router telling you this request does not sit cleanly in either bucket, and those are exactly the requests where the cheap model disappoints. Escalating on uncertainty costs you a little of the savings and removes most of the tail risk.

One last ordering point. The instinct is to route the most expensive decision, because that is where the money is. Do the opposite for the first one. Take the highest-volume, lowest-stakes step in the loop, the one running on every turn where a wrong answer produces a slightly worse response rather than an incident. You get the largest sample of real decisions fastest, which is what calibration needs, and you learn how the model behaves on your data somewhere being wrong is survivable.

‍

Use Case 2: Auto Mode and Tool-Risk Gating

This is the more interesting of the two, and LangChain's framing of it is the sharpest idea on the whole subject. Agents can be talked into things, by accident or by someone trying. Coding harnesses such as Claude Code, Codex and Cursor have all shipped some way of classifying dangerous actions before they are taken, and that is a large part of why people have grown willing to let them run. As LangChain puts it, "this classifier step has been locked away in the closed source parts of the harness." A cheap, fast, well-calibrated classifier is what makes the same pattern available to everyone else:

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (    AutoModeMiddleware) 
  
guardrail = AutoModeMiddleware(tools=["bash"]) 
  
agent = create_agent("openai:gpt-5.6-luna", middleware=[guardrail])

Two lines to put a check in front of every bash call, evaluated in milliseconds. That is a real change in what is affordable, and it is the first thing we would move in most of the harnesses we have built.

A probabilistic gate is a filter, not a guarantee

Here is the part that needs saying plainly, because the excitement around a calibrated classifier makes it easy to skip. A model that returns 0.98 on "this command is safe" is right far more often than a prompt instruction, and it is still a probability. Two percent of something that runs on every tool call is not a rounding error, it is a schedule. Calibration makes the number trustworthy as a number. It does not make the number a one.

So the gate is a layer, not the whole safety story, and the ordering matters more than the model does:

• A deterministic deny-list goes in front. Anything irreversible, and anything you would have to explain to a customer, never reaches the classifier at all. Deletes, transfers, sends, production writes, anything touching money or personal data. This is a set membership test in code and it is either correct or it is a bug you can fix, which is the property you want for the actions where being wrong is unrecoverable.
• The Jev gate goes behind it. Everything else, which is the large and truly ambiguous middle, gets classified. This is where the speed pays off, because a check that costs milliseconds can sit in front of every action without anyone noticing it is there.
• Human review catches the high-risk denials. A denial is not an error, it is a signal that something unusual happened. Route it to a person rather than letting the agent quietly rephrase and try again, which is what an agent will do if you let it.

That ordering is not theoretical for us. It is the same structure we put around agents working on regulated healthcare data, where the set of actions a model is never allowed to reach is written down before anything else gets designed.

Guardrails are the right thing to move first, for a reason that has nothing to do with cost. Move a classification step and you are trading accuracy for price, which is a real trade requiring real evidence. Move a guardrail and you are mostly adding a check that was previously too slow or too expensive to run on every action. Security work that used to be sampled can become universal, which is the kind of change that is hard to argue with in a review.

‍

What People Actually Use Jev For

Almost every write-up of this model stops at the two use cases above, and there is a structural reason for that: LangChain shipped two middlewares, so two is what there is to write about. It is not the usage surface. TypeSafe documents four architectural patterns and sixteen worked cookbooks, most with runnable code and measured results. Several of them are closer to the work we do for clients than model routing is.

Speculative Fan-Out, the Pattern That Follows From Parallel Questions

Parallel questions were listed earlier as a feature. Speculative fan-out is what you do with it: send every question you might need in one call, including the ones you probably will not use, and let your code decide afterwards which answers were relevant.

The parallel questions cookbook puts numbers on it. A compliance team wants 13 things checked against the Wikipedia article on the GDPR, roughly 54,000 characters: eight Noul questions, two Choice, three Score. Asked as one batched call it costs $0.000497 and takes 0.27 seconds. Asked as 13 single-question calls it costs $0.006090 and takes 2.71 seconds. That is 12.2x cheaper and 10.0x faster, and the reason is simple rather than clever: the document dominates every request, so 13 separate calls pay for it 13 times.

The part that makes the pattern safe to adopt is the control. Each strategy was run five times and compared question by question. Most answers came back byte-identical across all five repeats under both strategies, a standard deviation of exactly 0.0. The two questions that did wobble wobbled the same amount either way. Batching neither shifts an answer nor adds noise, because each question is scored on its own against the state and does not depend on what else shares the request.

For harness design that inverts a habit. Most of us ration checks, because each one historically cost a model call, so you ask the two questions you are sure you need and skip the five that would have been useful to have. When the marginal question is a rounding error, you ask all seven and throw away what you did not use. The checks you skipped are usually the ones that would have caught the problem.

Walking a Taxonomy With One Choice Question Per Node

This is the documented use case closest to our own work, and it is the one we would have written first. A hierarchical classification cookbook treats every node in a taxonomy as a Choice question whose options are that node's direct children. The returned probability distribution is the set of edges out of that node. You classify at the root, move to the most probable child, and repeat until you hit a leaf.

Done greedily, that has an obvious failure mode, and it is the one anybody who has built a categorization pipeline already knows: a single wrong turn near the root is unrecoverable, because everything below it is the wrong subtree. The cookbook's answer is beam search. Keep the best three paths rather than one, score them by the geometric mean of their edge probabilities so shallow and deep leaves compare fairly, and prune the rest. Because every frontier path runs as parallel questions, exploring three routes instead of one costs almost no extra wall-clock time, which is exactly the property that makes beam search affordable here and not elsewhere.

Across four hierarchies, patent classifications, the Shopify product taxonomy, biomedical subject headings and a source tree, beam search at width three matched the expected leaf 4 times out of 4. Greedy managed 2. On the Shopify taxonomy, greedy landed on Pet Chairs for a wall-mounted padded window shelf; beam recovered the correct Cat Window Beds and Perches.

We have been doing this categorization work by hand for years, most recently at 97% top-level accuracy across a 5,585-category marketplace taxonomy, and the early-wrong-turn problem is the one that eats the accuracy budget. The other benefit the cookbook names is the one that matters on a live pipeline: because each node is its own question, you can see which node your misclassifications cluster at, count how often each edge is traversed, and unit-test the effect of a taxonomy change. A single flat classifier over thousands of leaves gives you none of that.

The Retrieval Jobs: Filtering Passages, Re-Ranking, Checking Citations

Three documented uses sit in the retrieval layer rather than the generation layer, which is where a lot of RAG systems actually leak quality.

• Filtering retrieved passages. Score each retrieved passage with one request, then decide in code which ones are worth putting in front of the answering model. The generation step gets shorter and cleaner context, which is the cheapest quality win in most RAG stacks.
• Re-ranking. One question per query and candidate pair over 30-passage BM25 shortlists across 40 legal queries took top-1 accuracy from 5% to 18% and top-10 from 38% to 62%. Re-ranking with a frontier model is usually too slow and too expensive to run on every candidate, which is why most stacks skip it.
• Checking citations. One Choice question deciding whether the quoted context actually supports the claim, run against the source document. This catches the failure that damages trust fastest, an answer that cites something real for a claim the source does not make.

All three are the sort of thing you want on every request and historically could not afford on any. If you are already running an agentic RAG system or a retrieval pipeline in production, these are a more direct win than model routing, because they improve what the answering model is given rather than which model answers.

Guardrails, Composite Scoring and Intent Routing

Three more worth knowing by name. A guardrails cookbook screens every message going into and out of an LLM application in a single request, thresholding hazard probabilities and severity to pass, review, block or route, which is the Auto Mode idea applied to content rather than tool calls. Composite scoring breaks one complex judgment into several atomic scores and combines them with weights your code controls, so the weighting is reviewable and versioned instead of buried in a prompt. Intent routing classifies an incoming request and sends it to the right handler, which may be deterministic code, a specialist model or a person.

That last one is worth sitting with, because it is the honest general case. The interesting routing decision is usually not which model, it is whether this needs a model at all.

What Not to Give Jev

The fastest way to waste a quarter on a new model is to find out at the end of it which parts of the job it was never going to do. Two categories do not move, and one of them is obvious while the other is the one teams actually get wrong.

Anything That Has to Be Written in Words Stays With the LLM

Jev does not generate text. Not as a limitation to be worked around, but as the design decision the entire architecture rests on: giving up strings is what buys the parallel sampling, the price and the type safety. So drafting a customer reply, summarizing a document, writing code, explaining a decision back to a user, producing anything a human will read as prose, all of that stays with the language model. TypeSafe says it themselves, and LangChain repeats it: this is not a drop-in replacement for an LLM. It is a complement, and the harnesses that work put an LLM at the reasoning and generation steps with Jev on the decisions between them.

The Nine Failure Modes TypeSafe Publishes Itself

The most useful page in the documentation is the one almost nobody has written about. TypeSafe maintains a dated jaggedness page for jev-1.13 listing nine known failure modes with a recommended workaround for each. Reviewed 17 September 2026, published under the model version it applies to. The summary in their own words: the model is fast, calibrated and good at common-sense judgment, it struggles with tasks needing extra levels of indirection, it can be quite literal, and it struggles with numeric precision.

Four of the nine matter most when you are deciding what to move:

• Arithmetic belongs in code. Jev is not a calculator and does not count reliably, whether that is characters in a word, occurrences of a term or items in a long list. TypeSafe's own guidance is to iterate in code and ask one question per item rather than asking for a count. Their sharper point: if a regular expression could find the unit, the model has nothing to add.
• Dates are read as text, not as ordered quantities. Which of two dates comes first, how far apart they are, whether one falls in a window, all unreliable, and worse across mixed formats and domain boundaries such as quarters or settlement windows. Extraction is a judgment and belongs to the model; the comparison afterwards does not.
• It reads instructions literally. It answers the question you wrote rather than the one you meant, with negations and implied conditions taken at face value. The test TypeSafe suggests is worth stealing: when you look at a wrong answer and find yourself explaining what you really meant, that explanation is the missing half of the instruction.
• Large state full of irrelevant detail costs accuracy. They name it context rot. Retrieve and filter in code first, and send only the fields the question needs. This is the one most likely to catch a harness out, because the easiest thing to do with an agent's existing context is pass all of it.

Read that list next to the eval results and the invoice-processing gap stops being mysterious. Reconciling a bill against a purchase order and a delivery record is numeric comparison across several documents with dates in it, which is three of the nine failure modes at once. Customer service, where Jev came within 2.3 points of the best model on the board, is one situation read once and matched to a known response. The two sources are telling you the same thing from different directions.

Anything Where Being Wrong Is Expensive and Hard to Notice Stays Put

One test on top of the vendor's list, because a decision can clear all nine and still be the wrong thing to automate. A misrouted support ticket fails loudly and gets fixed in minutes. A mis-scored loan eligibility decision does not fail at all, it quietly produces a wrong outcome that looks exactly like a right one, and you find out when somebody audits it. That second kind keeps a strong model or a human on it, however well-shaped it looks.

How to tell whether a Jev tutorial is real

Worth knowing, because there are already tutorials on the web using Jev's name for something else. One well-trafficked walkthrough imports a package called jev, constructs a decision by passing a prompt and an OpenAI model name, and gets back a parsed object. It even advises readers to check whether the package exists and to substitute a different library if not. That is a general structured-output tutorial with Jev's name applied to it, and following it will teach you a useful pattern while telling you nothing about this model.

Four things identify the real interface, and you can check all of them in about ten seconds:

• The call takes a state and a set of typed questions. Not a prompt.
• There is no LLM model name being passed in. Jev is the model.
• Nothing returns text. Answers come back as Choice, Score or Noul.
• Every answer carries a probability. If there are no numbers in the response, it is not Jev.

There are four real surfaces, and a sample that looks like none of them is describing something else: the HTTP API at api.typesafe.ai/v1/systemone, the official Python and JavaScript SDKs (in Python, typesafe-sdk gives you TypeSafeClient().system_one(state, questions)), and the LangChain integration through TypeSafeClassifier.

‍

What the Published Evals Actually Show

Most of the coverage of this launch repeats two multipliers and stops. TypeSafe published four full workflow evals with the queries, the disagreements and the per-task breakdowns, which is more than most labs put out, and the interesting findings are not the ones in the headline.

How the eval is built, which decides what the numbers mean

Every task is decomposed the way you would decompose it to automate it: narrow independent questions for the model, typed as Noul, Choice or Score, with code making the final decision from the answers. Rather than argue about whether the harness is right, TypeSafe assumes the code is correct and measures the model's answers against a reference. That reference is not ground truth. It is the average of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the same harness. Every other model runs at its provider's default reasoning setting.

So accuracy here means agreement with a consensus of two frontier models on the same decomposed questions. That is a reasonable proxy and it is not the same thing as being right, which matters for how much weight the small differences deserve.

Structure beats prompting, for every model on the board

The finding with the widest application has nothing to do with Jev. Every model tested was more accurate, cheaper and faster running the decomposed workflow than running the same policy as a single prompt. Not most models. Every one.

How far apart those two scores are is the part worth sitting with. Haiku 4.5 scores 18.1% as a prompt and 53.6% as a workflow, on identical tasks with identical policy, which is a 35 point swing purely from decomposition. Luna goes from 51.9% to 66.8%. Even Opus 5, which handles the one-shot version better than anything else, gains 8 points and halves its cost. If you take nothing else from this article: decomposing the decision is worth more than upgrading the model, and it is available to you today without changing providers.

Jev lands mid-table on accuracy and off the chart on cost

Averaged across the four workflows, Jev scores 67.8%. That is identical to Sonnet 5 and a tenth of a point behind Terra, so on this eval it is not the most accurate model and TypeSafe does not claim it is. Sol leads at 74.1%.

What is different is everything else on the row. Sonnet 5 reaches that same 67.8% at $0.1174 and 78.1 seconds per case. Jev reaches it at $0.0004 and 0.4 seconds. Same agreement with the reference, roughly 290 times cheaper, roughly 195 times faster. Against Opus 5, which scores 5.3 points higher, Jev is about 440 times cheaper and 95 times faster. Those are the same order as the multipliers TypeSafe puts on its homepage, and seeing the underlying table is far more useful than the multipliers alone, because you can see exactly what accuracy you are trading away to get them.

The per-task spread is what should decide your first move

Averages hide the useful part. Jev's accuracy varies more across the four workflows than the mean suggests, and the variation lines up with how much unstructured judgment each task needs.

On customer service, deciding what an assistant should say and do next from a thread and an account state, Jev is within 2.3 points of the best model on the board while costing a hundredth of a cent. On invoice processing, reconciling a bill against the order behind it and what was actually delivered, it is 17.3 points behind. That is not a small shortfall you can threshold your way around, and it is the single most actionable number on the page.

The pattern is not subtle once you look for it. Tasks that are mostly reading a situation and picking from known responses sit well inside Jev's range. Tasks that require holding several documents against each other and reasoning about the discrepancies do not, yet. If you are choosing where to start, start where the decision is a judgment about one state rather than a reconciliation across several.

What the Eval Numbers Do Not Tell You

Three caveats, and TypeSafe states all three themselves rather than burying them. The workflows were built by their own model-capabilities team, so some bias could exist even though the tasks were not chosen to flatter the model. The reference labels come from OpenAI and Anthropic models, which the company says likely understates both Jev and DeepSeek's models. And accuracy against a consensus of two frontier models is a proxy for correctness, not correctness itself.

One trap to know about before you start tuning on any of this. TypeSafe warns that the question types are not interchangeable and that structural invariants you would expect to hold do not. A threshold tuned on a Noul does not carry over to a Choice, and the same question asked as a Noul and as its own negation can return probabilities that sum to more than one. Their worked example has a refund question scoring 0.22 as a Noul and 0.01 as the yes side of a Choice on the same ticket. Tune per question, and do not hold the model to arithmetic identities across separate ones.

The more practical limit is that none of these four workflows is yours. Security alerts, agent traces, invoices and support threads are a fair spread of shapes, and they still tell you where to look rather than what you will get. What the evals do give you, which is rare enough to be worth saying, is a published harness, the per-question disagreements and the full queries, so you can read the cases where the models split and judge whether those splits would matter on your own decisions.

That is the same question we work through when a client asks whether an open model they host themselves is good enough to replace an API call. The published benchmark narrows the search. The decision gets made on their inputs, by reading the cases where the two disagree.

What We Would Do This Quarter

LangChain points at early projects: Browserbase running browser-use agents for fractions of a cent, a live trading agent, and email triage at scale. Three different answers to one observation: once a decision costs almost nothing, you make a lot more of them.

If you already run an agent loop in production, four moves are worth making this quarter, in this order.

• Instrument the loop and label every turn. Log every model call with what it was deciding and what it cost, then label each one: open-ended reasoning, or a question whose valid answers you could have listed in advance. Most teams are surprised by the ratio, and that labelled list is what the other three moves run on.
• Move the guardrails out first. Deterministic deny-list in front, classifier gate behind. Best ratio of safety gained to risk taken, because you are adding checks that were too slow to run everywhere rather than replacing a judgment you relied on.
• Pick one step and run the comparison. Highest volume, lowest stakes, one step. Not five at once. One step with a real threshold teaches you more than five with assumed ones.
• Make the model a per-step config value. The durable move, and the one that outlasts Jev. If every decision point names its model in configuration rather than in code, adopting a System One model is a config change and so is the next one. TypeSafe will not be alone in this category for long.

Those four moves are roughly the order we work in when we build an agent system for a client, and the last one is the only one that is still paying off two model releases later.

If you do not run an agent loop in production yet, none of this is urgent. Build the loop first and instrument it. The decision layer is an optimization on a thing that exists, and optimizing a harness you have not shipped is how quarters disappear.

‍

Building an Agent Loop You Have to Trust?

We build production agent harnesses: the routing, the risk gates, the confidence thresholds and the escalation paths that decide whether an agent is safe to leave running. Tell us what your loop does today and where you do not trust it, and we will tell you what we would move and what we would not.

Frequently Asked Questions

What is Jev AI?

Jev is the first System One model, released by TypeSafe AI on September 15, 2026. It takes unstructured program state plus typed questions about that state and returns typed answers with calibrated probabilities, without generating any text. It is built for the fast structured decisions inside software rather than for conversation, and it is in early access.

What is a System One model?

A System One model is a class of model built to make fast, structured decisions that software can use directly, as opposed to producing text a human reads. The name comes from Daniel Kahneman's distinction between fast intuitive System 1 thinking and slow deliberate System 2 reasoning. Where a language model is optimized for responses people prefer, a System One model is optimized for decisions whose stated probabilities are honest.

Is Jev an LLM?

No, and it is not a smaller one either. It does not generate text at all. An LLM samples sequentially, one token conditioned on the last, and returns strings that software has to parse and validate. Jev samples in parallel and returns typed values whose possible shapes were defined before the call, each with a probability attached. Giving up string generation is what buys the speed, the price and the type safety.

How fast and how cheap is Jev, really?

TypeSafe reports end-to-end response times of 70ms to 500ms and input pricing of $0.042 per million tokens with output free, which they put at 40x to 200x faster than frontier models on System One shaped queries. The larger figures quoted around the launch, 193.6x faster and 444.6x cheaper, come from the company's own workflow evals against a reference built from GPT-6 Astra and Fable 5.1. TypeSafe describes those as being on the higher end of real world gains and notes their own team built the workflows. They are vendor numbers, published with vendor caveats, and the only figures that matter for your decision are the ones you measure on your own inputs.

Can Jev hallucinate?

It cannot return a value outside the schema you defined or a type that does not match, and TypeSafe treats that as guaranteed by construction rather than measured, since the possible outputs are fixed before the call. That is narrower than it sounds, and the distinction matters. Jev can still be wrong: it can assign a high probability to the wrong option. What it cannot do is invent a category you never defined or return a malformed value that breaks the code downstream. TypeSafe is explicit that their broader hallucination comparison is not empirical, while the type-safety claim is structural.

How do I use Jev with LangChain?

Install langchain-typesafe, set TYPESAFE_API_KEY, and call TypeSafeClassifier().invoke() with a state and a set of questions. The state can be text, structured data or LangChain messages, so the call fits into a node or a middleware hook using context your agent already holds. There is also experimental middleware for two patterns: ModelRouterMiddleware for choosing a model per request and AutoModeMiddleware for checking tool calls before they execute.

What should I not use Jev for?

Anything that has to be written in words: drafting, summarizing, code, explanations. It does not generate text, so those stay with a language model. Beyond that, keep any decision where being wrong is expensive and hard to detect, even when the valid answers are listable. A misrouted ticket surfaces immediately and gets fixed. A quietly mis-scored eligibility decision looks exactly like a correct one until somebody audits it, and that is the kind of step that keeps a strong model or a human on it.

Is Jev generally available?

Not yet. TypeSafe opened early access on September 15, 2026 and is bringing developers off a waitlist. The LangChain middleware imports from an experimental namespace, which is worth taking literally: the request shape and the middleware API can both still move. Date and link any code you build on, and expect to revise it.

‍