
What TypeSafe Jev actually is
TypeSafe is a San Francisco AI lab that spent two years in stealth before launching Jev. Its framing is deliberately provocative: on the TypeSafe homepage, LLMs "produce words for people," while "Jev produces typed decisions and is more like code: reliable, fast, self-consistent, and type-safe." The launch post calls Jev "a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."
The name is a two-part in-joke. "System One" borrows from Daniel Kahneman's Thinking, Fast and Slow: the distinction he drew between fast, intuitive System 1 thinking and slow, deliberate System 2 reasoning. Chat models chase System 2. Jev is built for System 1: the snap judgment a knowledgeable person makes in a couple of seconds. "Jev" itself is named after the economist William Stanley Jevons, whose paradox TypeSafe quotes as its thesis: every order-of-magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases.
The premise behind the whole thing is that RLHF, the technique that made chatbots pleasant to talk to, also made them unreliable for machine consumption. TypeSafe's pitch is that it "took the opposite research direction" and trained a new class of model with a new algorithm it calls Reinforcement Learning for Calibrated Decisions (RLCD).
How Jev works: state in, typed decisions out
The core loop is one request to one response. You send a state (either a plain string or a structured object) plus a set of typed questions. Jev evaluates each question in parallel against that same state, and returns typed answers with probabilities and confidence. Your code then branches, sorts, and routes on those answers.

The design choice that matters most: every question is evaluated independently and in isolation against the same state. TypeSafe says adding questions barely changes the response time, and because each one is scored on its own, you do not get the "context-rot" that creeps in when you cram a dozen instructions into one prompt.
TypeSafe's advice is to keep each question atomic. Instead of asking "rate this startup pitch," you ask each dimension separately (market size, technical feasibility, differentiation) and combine the scores with your own formula. When priorities shift, you change a coefficient in code rather than rewriting a prompt. If you have ever fought a mega-prompt to make it behave, that decomposition instinct will feel familiar, and it is the same logic behind good AI workflow automation.
The three primitives: Noul, Choice, and Score
Jev exposes exactly three question types, and you can mix all three in a single API call.

- Noul answers "is this statement true?" and returns a single probability from 0 to 1.
- Choice picks one option from a list you define, and returns the pick, per-option probabilities, and a confidence value.
- Score rates the state on a rubric you define, and returns a numeric value (it can land between levels, like 1.04 out of 2), per-level probabilities, and confidence.
The worked example Cloudflare publishes is, tellingly, a support ticket. Feed Jev the message "Help! My payouts have been failing for 3 days" and three mixed questions, and it comes back with is_urgent (Noul) at 0.95, department (Choice) as billing at 0.8 confidence, and frustration (Score) at 1.04 on a calm-to-very-angry scale, all in one call. That is triage, routing, and sentiment in a single request, which is exactly the kind of decision an AI ticket triage step needs.
Where Jev breaks from a normal LLM
If you only take one mental model away, make it this: an LLM writes, Jev decides.

A language model samples one token at a time, in sequence, until it has produced a string a human reads. Jev generates all its outputs in a single parallel pass and never produces free text at all. That is why it is fast, and it is also why the comparison is not quite apples to apples, a point I will come back to. The practical upshot for builders is that Jev slots in wherever you are currently coercing an LLM into emitting a JSON blob you then parse and hope is valid. This is the same "which layer am I actually choosing" question that shows up in AgentKit vs the Anthropic API.
The numbers TypeSafe is claiming
TypeSafe is not shy with figures, so here they are with the caveats attached.
| Claim | Jev | TypeSafe's stated baseline |
|---|---|---|
| End-to-end latency | 70ms to 500ms | 3 to 329 seconds for frontier LLMs |
| Speed multiple | 40x to 200x faster | on System One shaped queries |
| Workflow headline | 193.6x faster, 444.6x cheaper | "on the higher end of real-world gains" |
| Input price | $0.042 / MTok, output free | 238x lower than Claude Fable 5.1 |
| Context window | 32,000 tokens | model version jev-1.13.0 |
Jev is already live on Cloudflare Workers AI as typesafe/jev, and TypeSafe is opening early access off a waitlist. There is no standalone pricing page yet; the $0.042 figure comes from the homepage and launch post. On sustainability, TypeSafe is refreshingly plain in its launch post: "We can't prove it isn't subsidized; we'll need the long-term to prove the sustainability of our pricing (which we expect to go down, not up)."
The most credible outside data point came from Vercel's CEO, who put Jev into a real product:
"We're seeing extraordinary results from @typesafeai. Default mode in 𝚏𝚡 is auto, with a safety reviewer analyzing every command. That reviewer runs on GPT Luna today. Jev is up to 18x faster (p95) and more accurate."
An 18x speedup on a real safety-review step is a far more grounded claim than the 200x marketing number, and it points at where Jev genuinely shines: the fast checker sitting in front of a slower system.
What "can't hallucinate" really means
This is the claim that lit up the launch thread on Hacker News (1,929 points, 508 comments), and it is worth slowing down on because it is the thing most people will get wrong.
Jev cannot make a type error and cannot return an option that was not in your list. In that mechanical sense, it "can't hallucinate." But a typed answer can still be confidently wrong, and several commenters made the point crisply:
"if it puts a high confidence value on a wrong answer, thats still hallucinating, no?"
The defense is that Jev always hands you a confidence value, so you can act on the certain answers and route the shaky ones to a human:
"they mean they produce a confidence value for every result, so you could see for example it has 0.1 confidence, and you can disregard the result."
The real test is calibration, not the "can't hallucinate" slogan. As one commenter put it, if the model says 0.9 on a thousand answers, about 900 should be correct. RLCD is supposedly optimized for exactly that. Until there are independent calibration numbers, treat "can't hallucinate" as "won't return malformed output," not "is always right." For anyone deploying AI on real customer questions, that distinction is the whole game, and it is why we lean so hard on grounding and testing to prevent AI hallucinations in support.
Who is behind Jev
TypeSafe has a pedigree that is hard to wave away. Founder and CEO Diogo Almeida co-invented RLHF and InstructGPT at OpenAI, the research line that led to ChatGPT, and was previously at Google Brain. He is joined by COO Sasha Sheng (ex-Meta/FAIR) and CTO Erik Gafni, with a team drawn from OpenAI, Google Brain, Meta, Stripe, Airbnb, and Docker.
The company says it is "backed by top-tier investors" but has not published a funding figure on its own pages, so I will not put a number on it. The tagline, "Build Prod, Not God," tells you the posture: this is a team optimizing for shipping reliable production pieces, not chasing AGI.
Should you actually use Jev?
Here is my read after going through the docs, the demos, and the pushback.
Reach for Jev when the job is a narrow, well-scoped decision your code consumes: routing, moderation, intent detection, scoring, extraction gates, or a fast safety check in front of a bigger model. The most convincing developer take on Hacker News was someone who was already doing this by hand:
"this is exactly how I am using LLMs in production, to narrowly make choices and return structured data... Jev's focus on structured I/O and confidence scores are game changing. If this does at all what it claims, I think this is going to quickly become the new standard approach for agentic systems."
Do not reach for Jev when you need generation, explanation, or multi-step reasoning. The top comment on the whole thread nailed the honest framing:
"Seems like a more accurate title would be 'Jev: Trading general purpose generation for fast typed inference.'"
And the loudest skeptics, including developer Theo Browne, argued the viral demos push it into jobs a simple classifier or rule should own. That is a fair caution: a tool this fast invites overuse. The line to hold is that Jev is a primitive. It gives you a great decision; you still own the pipeline, the escalation logic, the deflection strategy, and every action that happens after the decision.
Try eesel
If you run support, the honest translation of all this is: Jev is a brilliant engine, not a car. It will tell you a ticket is urgent, billing, and coming from a frustrated customer in 114 milliseconds. It will not open the ticket, draft the reply grounded in your help center, apply the refund, or hand off to a human when it is unsure. Someone still has to build that.
eesel is that finished teammate. It is an AI support teammate you plug into your helpdesk, and it already makes the triage, routing, and escalation calls Jev exposes as primitives, then acts on them end to end. It joins your existing customer service queue, learns from your past tickets and help center, and you can simulate against historical tickets before it ever touches a live customer.

And if you liked the developer ergonomics of Jev, you will like this: eesel is not dashboard-only. The eesel CLI (npx @eesel/cli) operates the same teammate and workspace from a terminal. A person can run eesel chat, eesel activity, or eesel approvals by hand; scripts can automate it in CI; and coding agents like Claude Code, Codex, and Cursor can drive it, since every command prints JSON and --dry-run shows the exact call before it fires. Every workspace is also an MCP server. Jev gives you the decision; eesel gives you the teammate that acts on it, and lets your agents operate it. You can try eesel free.
Frequently Asked Questions
What is TypeSafe Jev?
TypeSafe Jev is the first public System One model: instead of generating text, it evaluates typed questions against a state and returns typed decisions with probabilities and a confidence score. It is built for the narrow, structured judgments that software consumes directly, like tier-1 triage and routing.
How much does TypeSafe Jev cost?
TypeSafe prices Jev at $0.042 per million input tokens with output free, which the company frames as 238x lower input price than Claude Fable 5.1. There is no published plan-tier table yet, and access is via an early-access waitlist.
Can Jev really not hallucinate?
It cannot produce a type error or invent an option outside the list you gave it, but a confidently wrong typed answer is still possible, a point debated on Hacker News. The real test is calibration. If you want grounded answers on a support queue, the same discipline in our guide to preventing AI hallucinations applies.
Is Jev a replacement for an LLM?
No. Jev makes fast typed decisions, it does not write text, reason step by step, or hold a conversation. Many teams pair it with an LLM, using Jev for the classify-and-route step, similar to how a rule-based versus AI agent split works in practice.
How is Jev different from a normal AI customer service agent?
Jev is infrastructure: a decision primitive you wire into your own code. An AI customer service product like eesel is the finished teammate that makes those decisions and takes the action inside your helpdesk. You can even drive it from a terminal with the eesel CLI.

Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.








