← Back to Blog
Hot TopicOn This Site

Jev and System One Models: What TypeSafe Built, and How It Differs From an LLM

Five days ago a $40M startup launched a frontier model that cannot write a single word. Jev takes your program state and returns typed decisions with probabilities, in under a second, for almost nothing. I read the launch, the docs, the Hacker News fight, and four independent tests so you don't have to. Here's what it is, what's real, and where I'd actually use it.

·11 min read

Every AI product I've shipped has the same hidden layer inside it. Not the chat, not the generation, but the dozens of small yes-or-no and which-one-of-these decisions the code has to make around the model: is this message spam, which queue does this ticket go to, is this tool call safe to run, does this answer actually cite the document. I've built that layer with regex, with fine-tuned classifiers, and lately with a cheap LLM and a JSON schema. None of those options felt finished.

On September 15, a company called TypeSafe AI came out of two years of stealth with a $40M seed round and a model called Jev that is built for exactly that layer, and nothing else. Jev cannot generate text. It takes your program state and a set of typed questions, and returns a probability for every answer, in one pass, in well under a second, at a price that rounds to zero.

I have not put it into production yet. What I have done is read the launch post, the API docs, the 500-comment Hacker News thread, the TechCrunch and Register coverage, and four independent benchmark write-ups from the first week. This is my read as someone who builds AI products for a living: what Jev is, how a "System One model" differs from the LLMs you already use, which claims survive contact with the evidence, and where I'd put it in a real architecture.

A small humanoid robot sitting on a bench, reading a book

What Jev actually is

Jev is a hosted model with one endpoint and three question types, and no ability to produce a string. You send it a state (text, a JSON object, or an array: a support ticket, a document, a game board, a database row) plus a map of questions. Each question is one of three primitives. A Noul asks whether a statement is true and returns a probability between 0 and 1. A Choice picks from a list you supply, up to 255 options, and returns the winner plus the full probability distribution. A Score places the state on an ordered rubric of 2 to 10 levels. Every question in a request is answered in parallel against the same state, and the docs say adding more questions barely changes the response time.

The numbers TypeSafe publishes: $0.042 per million input tokens, output free, a 64k-token context window, latency claimed at 70 to 500 milliseconds, text-only input, English-first. There are Python and JavaScript SDKs, and Vercel added it to AI Gateway within a day. It launched as a waitlist and, going by TypeSafe's own posts, is opening to everyone as I write this.

The company is run by Diogo Almeida, who was part of the InstructGPT and RLHF work at OpenAI that became the research behind ChatGPT. That pedigree is the strongest marketing asset they have, and it's also why the launch got 1,953 points on Hacker News, more than Gemini's same-day release.

TypeSafe calls this category a "System One model," after Kahneman's split between fast intuitive thinking and slow deliberate reasoning. The model's name honours William Stanley Jevons, whose paradox says that making a resource cheaper increases total consumption of it. That's the bet in one line: make a decision cost less than the log line that records it, and software will make a hundred times more decisions.

How a System One model differs from an LLM

The difference is mechanical, and it explains almost everything else. An LLM generates one token at a time, and each token requires a full pass through the model. A one-word answer to a classification question still costs a prefill pass over your input plus at least a few decode steps, and a reasoning-mode model burns thousands of hidden tokens before you see the first visible one. That's why TypeSafe's comparison table shows frontier models taking 3 to 329 seconds on its workflows.

Jev skips the decode loop entirely. It reads the input once and emits a fixed-size probability vector for each question. No sequential generation, no tokens to sample, nothing to parse. Prefill is compute-bound and batches well; decode is memory-bound and serial. Removing decode is the same reason a fine-tuned BERT classifier has always been orders of magnitude cheaper than a generative model on the same task, and it's why "output tokens: free" is coherent pricing rather than a gimmick. The output is a handful of floats.

The second difference is training. LLMs are optimised with RLHF (reward what human raters prefer) or, for reasoning models, RLVR (reward what can be verified). TypeSafe says Jev is trained with something it calls Reinforcement Learning for Calibrated Decisions, or RLCD, which rewards probabilities that are honest: if the model says 0.8, the answer should be right about 80% of the time. Their argument is that human preference and machine trustworthiness are different targets, and that RLHF actively rewards confident-sounding wrong answers.

Here is what I want to be straight about. TypeSafe has published no paper, no parameter count, no architecture, no reward function, and no calibration figure. Almeida told Latent Space that public benchmarks are "extremely gameable" and won't be published. TechCrunch reports that outside observers suspect Jev sits on top of an open-weight LLM. Within 48 hours, six functional clones appeared on GitHub built from ordinary parts (ModernBERT plus PPO, Qwen 3.5 plus an NLI head), and the best of them match hosted Jev on flat classification benchmarks. So the interface is genuinely useful, but the model underneath is a black box, and the moat, if there is one, is the synthetic training data, not the architecture.

What "cannot hallucinate" really means

Jev cannot produce an output that is outside your schema. That is the whole claim, and TypeSafe's own launch post admits the 0% hallucination number is "not empirical" but definitional. When a user on Hacker News pushed, Almeida conceded that type safety is not factual correctness and that Jev "can still emit a completely wrong valid value."

That's the same guarantee a softmax classifier has always had, and it's also a guarantee you can already get from Anthropic, OpenAI and Google, all of which now use constrained decoding to force valid JSON. Schema compliance is table stakes in 2026. A benchmark of 21 models this April found near-perfect schema validity but only 83% value accuracy on text: the failure mode has moved from broken JSON to well-formed JSON with the wrong answer in it.

TypeSafe's own evals make the same point in numbers. On the four workflows the company published, Jev agrees with the reference labels 67.8% of the time. GPT-5.6 Sol scores 74.1% and Opus 5 scores 73.1%. Jev is not the most accurate model on TypeSafe's own benchmark; it's the one that gets to 68% for $0.0004 and 0.4 seconds per case instead of $0.08 and 23 seconds. Roughly one decision in three disagrees with a frontier judge. That's a useful tool, not an oracle.

The 444x claim, with the arithmetic

TypeSafe's homepage says 193.6x faster and 444.6x cheaper. Those numbers are real in one specific comparison: against GPT-6 Astra and Claude Fable 5.1 in reasoning mode, running through TypeSafe's own wrapper, on workflows TypeSafe's team wrote. The launch post itself says these are "on the higher end of real world gains."

Nobody I know runs a 500-token classification through a flagship reasoning model. They run it through the cheap tier. So here's the same call priced from list prices, per million calls:

  • Jev: about $21
  • GPT-5 nano: about $29
  • Gemini 2.5 Flash-Lite: about $54
  • Claude Haiku 4.5: about $550
  • Sonnet 5 or GPT-5.6 Terra: about $1,100
  • Fable 5.1 or GPT-6 Astra: about $5,500

Against the flagships, Jev is roughly 260x cheaper. Against GPT-5 nano, it's 1.4x cheaper. And with prompt caching, cached input on Haiku 4.5 costs $0.10 per million and on GPT-5.6 Luna $0.02, both below Jev's headline price. Jev bills the full state every call. That's why one CTO quoted in TechCrunch found Jev 10 to 20 times more expensive than his Gemini setup, even while praising the confidence scores.

Latency follows the same pattern. Independent measurements in the first week put Jev at a p50 of roughly 0.4 to 1.0 seconds from outside the West Coast. A short non-reasoning call on Haiku or Gemini Flash lands at 0.5 to 1.5 seconds. That's a 2x to 10x edge, not 200x. The one place the raw speed is unarguable is real-time loops: in Ably Labs' Pong demo, Jev made 47 decisions in 12 seconds while Gemini, Haiku and GPT managed two or three each. If your product needs an intelligent decision every 200 milliseconds, there is no LLM substitute.

The honest version of the headline: Jev is single-digit multiples cheaper and faster than the models you'd actually use for classification, and hundreds of times cheaper than the ones you wouldn't.

Calibration is the real claim, and the evidence is mixed

Speed and price are nice. The thing that would change how I architect systems is a probability I can threshold on. If the model says 0.95 and it's right 95% of the time, I can automate the 0.95 cases and route the rest to a human or a bigger model. That's the difference between a demo and an automation. Every LLM I've asked for a confidence number gives me one that is prompted, not trained, and usually overconfident.

Four independent tests looked at exactly this, and they don't agree. A 60-item test of agent tool-call risk found 91.7% accuracy with every wrong answer carrying confidence below 1.0, which is the behaviour you want. A much larger study of 4,621 items found Jev accurate and well calibrated on public benchmarks (expected calibration error around 0.02) but overconfident on out-of-distribution synthetic support tickets, with error 4.4 times the noise floor and a priority score that was right only 44.7% of the time while carrying 0.74 average probability. A second audit concluded the probabilities are not calibrated at any difficulty level, but they are monotone: higher probability really does mean higher hit rate. Both larger studies land on the same advice: treat Jev's output as a ranking score, not a probability, and fit your own threshold on a few hundred labelled examples per question.

Two more things the docs are candid about. The confidence field is not a separately learned uncertainty estimate; it's a linear rescale of the top probability, so it can't tell you anything the distribution doesn't. And TypeSafe's own "jaggedness" page lists the known weaknesses: Jev does not count reliably, reads dates as text rather than ordered quantities, gets worse as irrelevant context grows, and can be steered by instructions injected into the state. That last one matters if you're using it as a guardrail; I've written before about why prompt injection is the SQL injection of this era, and a decision model reading untrusted input inherits the problem.

Where I'd use it, and where I wouldn't

The pattern that every vendor guide and community project has converged on in a week is simple: LLMs for anything that produces a string, a decision model at the branch points where code needs a number. That's the pattern I'd adopt whether the model in the branch slot is Jev, one of its open clones, or a fine-tuned encoder.

Four branch points earn a decision model:

  • Intake routing. Which agent, which queue, which model tier handles this request. High volume, enumerable answers, and every millisecond is in the user's path.
  • Pre-execution gating. Is this tool call safe, does this message contain an injection, does this content violate policy. Guardrails run on every call, so cost and latency are the binding constraint, and this is where Vercel reported 5x to 18x speedups after swapping ChatGPT for Jev in safety classification.
  • Post-generation verification. Does the LLM's answer actually cite the source, does it match the rubric, is it on topic. A second opinion for a fraction of a cent.
  • Batch scoring over data. Deduplication, entity matching, tagging every row in a large table. One cookbook example asks 13 questions of a 54,000-character document in a single call at about a tenth of the cost of 13 sequential LLM calls.

Where I wouldn't use it: anything whose output is text (summaries, replies, SQL, code, extracting a name or address), anything with images, anything with arithmetic or date logic, multi-step reasoning, and any decision with more than 255 options unless you decompose it. And before any of that, the rule Zyte's engineers wrote in their test applies: if a regular expression, a status code or a CSS class can answer the question, don't ask a model at all.

One more choice to make. If you have thousands of labelled examples and a stable label set, a fine-tuned encoder still beats Jev on accuracy, latency and marginal cost, and you can calibrate its softmax on a held-out set yourself. Jev's real competition isn't the encoder; it's the small LLM with an enum schema that most teams use today when they have no labels and the categories keep changing. That's the head-to-head worth running on your own traffic.

What this means if you're building an AI product

The durable thing about this launch isn't the model. It's the interface it normalises. "Unstructured state in, typed probabilities out" as a hosted primitive is the decision-tier version of what the embeddings API was in 2022: a known technique whose packaging and price make it a default building block. Open clones matched hosted embeddings on flat tasks within months; here they matched Jev on flat classification within days. TypeSafe's defensible ground is narrow and specific: calibration under distribution shift and judgment on decisions that need a bit of reasoning, which are precisely the two things it has neither published nor had independently confirmed.

For a founder, three practical consequences:

  1. Budget decision calls as free and model the escalation rate instead. At a hundredth of a cent per decision, the cost that matters is what happens to the 20% of cases the model isn't sure about.
  2. Build a labelled eval set per question, a few hundred examples, before trusting any threshold. Simon Willison's note on this is the one I'd pin up: for a model that returns only a number, evals matter more than they do for regular LLM projects, not less.
  3. Wrap the call behind an interface. The model is closed, has no SLA, and Almeida has said current versions won't be supported long-term. Open clones already match it on the easy cases, so keep your lock-in exposure to the hard ones.

If you want to try it, the pilot I'd run is unglamorous: take one enum classifier already in production on a cheap LLM, shadow-run Jev on the same traffic for a week, and measure agreement with your current classifier, agreement with human labels, calibration on the human-labelled slice, and p95 latency from your own region. Then automate the low-risk path first and keep deterministic code wherever it already decides correctly.

This is the kind of decision I make with founders every week as a fractional CTO: not "is this new model exciting" but "where in our architecture does it earn its place, and what breaks if the vendor changes the price." If you're designing that layer for an AI product right now, get in touch and I'll give you an honest read on whether a decision model belongs in it.

Frequently asked questions

What is Jev in one sentence? Jev is a hosted AI model from TypeSafe AI that takes program state and typed questions and returns calibrated probabilities for each answer, in one parallel pass, without generating any text.

What is a System One model? TypeSafe's name for a class of models built for fast, structured decisions rather than text generation, after Kahneman's "System 1" intuitive thinking. Simon Willison and others prefer the plainer term "decision model." No other lab uses the category name yet.

How is Jev different from structured outputs or JSON mode? Structured output modes on Claude, GPT and Gemini guarantee valid JSON but give you no trained confidence signal. Jev's pitch is a probability distribution trained to be calibrated. Independent tests so far find the probabilities monotone but overconfident out of distribution, so you still need your own thresholds.

Is Jev really 444x cheaper than an LLM? Only against flagship reasoning models on TypeSafe's own workflows. Against the cheap tiers you'd actually use for classification, the gap is about 1.4x to 10x, and with prompt caching some LLMs are cheaper per cached token.

Can Jev hallucinate? It cannot return anything outside your schema. It can, and does, return a well-formed wrong answer: on TypeSafe's own evals it disagrees with a frontier judge on about one decision in three.

What should I use Jev for? Routing, guardrails, verification and batch scoring: high-volume decisions with an enumerable answer set where latency matters. Not for anything that needs generated text, images, arithmetic, or an explanation of its reasoning.

Does it replace my LLM? No. The pattern is an LLM for generation and a decision model at branch points. LangChain's own guide says plainly that Jev is not a drop-in replacement for an LLM.

Sources: the TypeSafe launch post and docs, TypeSafe's workflow evals, the Hacker News launch thread, TechCrunch, Simon Willison, LangChain's harness guide, Zyte's scraping test, and the independent calibration studies by scienthoon and SamuelSacco. Prices are list prices as of September 20, 2026.

Written By

Kunal Vohra

Kunal Vohra

Technical Co-Founder & Fractional CTO

I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.

Comments

Loading comments…

Enjoyed this article?

More writing on AI, Web3, and building startups.