Jev by TypeSafe AI: A Non-Chatting Model for Typed Decisions

Jev is the debut model from TypeSafe AI, a San Francisco startup that emerged from stealth mode on September 15, 2026, backed by a $40 million seed round led by DCVC.

Unlike most AI systems making headlines, Jev is not a large language model. It cannot produce sentences, generate code, or draft explanations. Instead, you feed it a snapshot of state, such as a customer support ticket or a product listing, alongside a set of structured, typed questions. In return, it delivers typed answers, each attached to a probability distribution and a confidence score. There's no prose to interpret and no JSON structure to fix after the fact.

TypeSafe describes this approach as a "System One" model, trained through a method the company calls Reinforcement Learning for Calibrated Decisions, or RLCD. According to the company, response latency ranges from 70 to 500 milliseconds, and pricing sits at $0.042 per million input tokens, with output tokens costing nothing at all.

That pricing detail isn't an error. Output is free simply because there's almost no output to speak of.

Who founded TypeSafe AI

The company's founder and CEO, Diogo Almeida, previously worked as a researcher at OpenAI, contributing to reinforcement learning from human feedback, InstructGPT, ChatGPT, and GPT-4. He is credited as one of the co-creators of RLHF, the technique that transformed raw language models into usable conversational assistants.

Rounding out the leadership team are Erik Gafni as CTO and Sasha Sheng as COO. TypeSafe was founded in 2024 and operated in stealth for close to two years before going public. Forbes put the company's valuation at roughly $200 million following this funding round.

There's something notable in the fact that Almeida helped engineer the very approach that made models skilled at satisfying human preferences, yet he now argues that satisfying humans was never actually the same challenge as making software dependable. When someone pushes back against the thing that made them famous, it's usually a sign they've spent considerable time reconsidering the problem.

The company name references William Stanley Jevons, the nineteenth-century economist known for Jevons paradox, the observation that as a technology becomes more efficient, overall consumption of it tends to rise rather than fall. The underlying bet here is straightforward: make intelligence cheap enough, and usage will expand dramatically.

The aspect

Anyone who has shipped AI features for ecommerce has likely run into the same recurring friction point.

Consider the kinds of judgments these systems are asked to make: Is this search query about a brand or a category? Is this product photo suitable for the homepage? Is this review complaining about shipping delays or product quality? These are minor decisions, the sort a competent category manager could resolve in a couple of seconds.

Yet the standard solution is to route these questions through a language model. It produces a paragraph of text. That text then gets forced into a JSON structure. You build a parser for it. You add validation logic. You write retry handling. You create a fallback path for when the retry also breaks. And eventually, in production, often in the middle of the night, the model returns a category value that doesn't exist anywhere in your taxonomy, quietly corrupting a downstream merchandising table.

The bottleneck was never the intelligence itself. It was the interface surrounding it.

This is precisely the gap Jev is designed to close.

The core claim isn't that this model reasons better than others. It's that the shape of its output finally matches what applications actually need.

How Jev actually works

The entire API surface consists of just three question types.

A Choice question lets the model select one option from a list you provide, and you get back the chosen item along with a probability assigned to every option plus an overall confidence value. You can supply as many as 255 candidate options in a single list.

A Score question has the model grade the input against a scale of ordered levels that you specify yourself, things like bug severity, how frustrated a customer sounds, or how finished a product listing appears. The number that comes back can sit between two neighboring levels rather than landing exactly on one, and the response also includes the complete distribution behind that score.

A Noul question represents a binary yes-or-no statement. The response is a single number between 0 and 1, representing the probability that the answer is yes.

These three types can be combined freely within a single call. Every question is evaluated against the same input state, each one is judged independently, and all of them run concurrently. Because of this parallel handling, adding more questions to a request barely affects response time. Each call operates within a shared budget of roughly 32,000 tokens covering both the state and the questions.

That token-budget detail reshapes how you'd approach designing a system around Jev. Since additional questions cost almost nothing extra, the recommended strategy is to ask everything you could conceivably need, even questions whose answers are only relevant for certain inputs, and simply discard whatever your application doesn't use. TypeSafe refers to this pattern as speculative fan-out. For anyone accustomed to a world where every additional model call adds cost and delay, this reversal of incentives takes a moment to fully sink in.

How Jev is different from an LLM

Four distinct features set this apart from a language model dressed up with structured output formatting.

First, the training goal itself is different. RLHF optimizes a model to give answers that humans rate favorably. RLVR optimizes for answers that a verifier can check, which is the technique behind reasoning models. Jev instead uses something called RLCD, which trains the model to produce decisions paired with honest probability estimates. If Jev outputs 0.8 as a confidence score, the implicit promise is that across a large sample of similar answers, about 80 percent will actually be correct. Calibration isn't a byproduct here — it's the entire point of the system.

Second, sampling happens in parallel rather than sequentially. A typical language model produces text token by token, with each new token depending on everything generated before it. Jev instead produces a complete answer in one pass. That's the source of its speed, and it's also why generating output costs nothing extra — there's no lengthy sequence of tokens being billed one at a time.

Third, the output format isn't just encouraged, it's guaranteed. Jev is physically limited to returning values from a predefined set you specify ahead of time. This isn't "usually compliant" behavior — returning anything outside that set is not possible by design. A hallucinated category isn't merely rare, it's structurally excluded from the space of possible outputs. TypeSafe advertises a 0 percent error rate for malformed structured output, and unlike most benchmark figures, this one is a direct consequence of the architecture rather than something measured empirically.

Fourth, uncertainty itself is treated as a real output rather than an afterthought. Any Choice or Score response comes bundled with a confidence value calculated from how sharply peaked the underlying probability distribution is. A distribution that's spread out flat signals genuine model uncertainty. This lets your application logic respond to confidence directly — automatically acting when confidence clears one threshold, escalating to a person when it falls below another, and setting a stricter bar for higher-stakes actions than for low-risk ones.

That last capability is arguably the most valuable one. Being wrong five percent of the time has rarely been the actual obstacle with these systems. The recurring problem has been having no way to identify which five percent.

What the benchmark numbers actually say

This is the section where some skepticism is warranted, since the marketing materials do a lot of framing work, and much of the coverage online has simply repeated the top-line figure without digging in.

TypeSafe ran its own benchmark spanning four use cases: security incident response, agent trace observability, invoice processing, and customer support, totaling roughly 711 test cases. Rather than relying on human-verified ground truth, the reference answers were generated by averaging the judgments of GPT 6 Astra and Claude Fable 5.1.

Against that reference set, Jev matched the expected answer 67.8 percent of the time. GPT 5.6 Terra came in essentially tied at 67.9 percent — a result that looks great for TypeSafe on its face.

But scan further down the results table and the picture shifts. GPT 5.6 Sol hit 74.1 percent accuracy, and Claude Opus 5 reached 73.1 percent. Zooming into the invoice-processing subset specifically, Jev scored 61.8 percent versus Sol's 79.1 percent — a seventeen-point difference, and not a small one, on precisely the kind of structured extraction task many prospective users would expect this model to excel at.

Where Jev clearly dominates is cost and speed. It runs at roughly $0.0004 per case and 0.4 seconds of latency, compared to about three cents and ten seconds for Terra — a gap of roughly two orders of magnitude in both dimensions.

Put together honestly, Jev performs somewhere in the middle of frontier-model accuracy, while costing between a fortieth and a four-hundredth as much and responding in a fraction of a second. Whether that tradeoff makes sense depends entirely on the cost of getting an individual answer wrong. Classifying a million search queries, this tradeoff looks excellent. Approving a refund automatically, you'd want the confidence-gating mechanism doing real, meaningful filtering.

Two caveats are worth keeping in mind. These are numbers reported by the vendor itself, and no independent large-scale reproduction has appeared yet. And because the reference answers were produced by OpenAI and Anthropic models, the whole comparison is quietly tilted toward rewarding agreement with those two model families specifically.

Where I would use it

Consider a team building discovery and merchandising features for a grocery and general-merchandise ecommerce platform operating across several Gulf markets. Here's roughly how such a team might prioritize Jev in its backlog.

Query understanding at catalogue scale would likely come first. A platform spanning multiple markets and languages sees an enormous long tail of search queries. Tasks like classifying intent, separating brand names from category terms and attributes, and flagging queries likely to return empty results are currently handled through a patchwork of rules that decay over time, plus occasional LLM calls that are too costly to run on the full volume. At roughly $42 per billion input tokens, running this kind of classification across every single query, every day, becomes financially realistic.

Content quality scoring is another strong candidate. Every product listing could be scored on title clarity, image quality signals, and attribute completeness, with the lowest scorers routed back to the catalogue team for fixes. This is essentially one repeated Score-type question applied at a scale of millions — work that's traditionally been too expensive to run through an LLM and too nuanced to encode as rigid rules.

Relevance judging for search tuning is a third use case. Rather than purchasing human-labeled relevance data or paying for an expensive model to generate it, query-product pairs could be scored in bulk to construct an offline relevance dataset. TypeSafe's own documentation on reranking cites a jump in first-result accuracy from 5 percent to 18 percent on a legal-document retrieval benchmark — a promising signal, even though that domain has little in common with ecommerce search.

Finally, guardrails around existing LLM-powered features are a natural fit. Screening the inputs and outputs of any conversational feature for jailbreak attempts and policy violations requires a check that's fast and cheap enough not to become a bottleneck itself, which is exactly the profile Jev is built for.

Where I would not use it

Any situation demanding an explanation is off the table. Jev never produces reasoning, full stop. When a merchant asks why their listing got pushed down in ranking, telling them "the model gave it a 2.1 out of 4" satisfies no one.

Tasks that require chaining reasoning across dependent steps are also a poor match. TypeSafe says this outright in its own documentation: break your problem into standalone questions or reach for a different tool, since items bundled into a single request have no visibility into each other's answers.

Anywhere precision outweighs throughput, be cautious. That weak spot on invoice processing isn't a minor caveat — it's a genuine warning sign.

And you shouldn't deploy it anywhere you can't first validate it against your own data. A 67.8 percent blended score across someone else's four benchmark tasks tells you next to nothing about how the model will cope with Arabic product names or the way groceries get categorized in Gulf markets.

The bigger idea

Set aside the launch-day metrics, and there's an underlying claim that still holds up regardless of whether Jev specifically becomes the winner in this space.

Text was never the right interface between a model and the software meant to act on its output. We ended up using it simply because it was the format available, and then spent years afterward constructing parsers, validators, retry logic, and schema checkers just to compensate. Each of those layers exists purely to translate something built for human reading into something a machine can safely consume.

If the majority of AI usage eventually happens inside software pipelines rather than chat interfaces — and that seems like the likely trajectory — then the system doing that work probably shouldn't be optimized for generating readable sentences in the first place. TypeSafe itself estimates that automation at scale ends up being roughly 99 percent machine-to-machine communication. The precise figure is debatable. The overall direction is much harder to dispute.

Jev might not turn out to be the model that gets the industry there. It's narrow in scope, still new, relies on self-reported numbers, and falls behind top-tier models on raw accuracy. But what it has managed to do is put forward a concrete, testable claim about exactly where the friction point in our current systems really sits.

That friction point is something teams have been designing around for as long as they've been shipping AI-powered features. It would be a welcome change to see it finally disappear.