Jev, Explained Like You're Five (Then Like You're Actually Building With It)

Originally published on iHateReading

Every few months, an AI lab ships something that isn't trying to be a better chatbot, and those are usually the launches worth actually stopping for. On September 15, 2026, a small San Francisco lab called TypeSafe AI came out of stealth with exactly that kind of launch: a model called Jev, and a new category they're calling System One models. It doesn't chat. It doesn't write code. It doesn't generate a single word of text. And a decent chunk of the AI engineering internet spent the following week arguing about whether that's a gimmick or the missing piece nobody noticed was missing.

We got early access this week, so let's actually walk through what it is — starting stupid simple, then all the way down to how you'd wire it into something real.

Jev, explained like you're five

Imagine you have a friend who is incredibly fast at answering yes-or-no questions, or "pick one of these three things" questions. Not slow-and-thoughtful fast — instant. You show them a messy pile of information, ask them ten quick questions about it at once, and they answer all ten before you've finished reading the last one. They never make up an answer that wasn't one of your choices. And they tell you how sure they are, every single time.

That friend is bad at writing you an essay. Ask them to explain something in their own words and they just stare at you — that's not their job. But for "which pile does this go in," "is this true or false," or "how bad is this on a scale of 1 to 3," they're basically unbeatable, and they barely cost you anything to ask.

That's Jev. It's not a smaller ChatGPT. It's a completely different shape of tool, built to sit inside software and make small decisions, over and over, extremely fast and extremely cheap.

Okay, now for real: what is Jev

Jev is TypeSafe AI's first public System One model — a new class of AI model built to return typed, probability-scored decisions instead of generated text. You send it a block of information (they call this the state) plus a set of questions with fixed possible answers, and it returns an answer to every question, each with a confidence score, in one fast pass. Nothing to parse. Nothing that can technically go off-script, because the set of valid answers was defined by you before the model ever saw the input.

The name is a reference to Daniel Kahneman's Thinking, Fast and Slow — the distinction between fast, intuitive "System 1" judgment and slow, deliberate "System 2" reasoning. TypeSafe's bet, laid out in their launch post, is that most of the decisions software actually needs aren't the slow, deliberate kind chat models are built for — they're small, fast, repeated judgments, and nobody had built a frontier model specifically for that job until now.

"Jev" itself is named after the 19th-century economist William Stanley Jevons, of Jevons-paradox fame — the observation that making something more efficient tends to increase total consumption of it, not decrease it, because cheaper access unlocks new uses. TypeSafe is explicitly betting that making a "decision" cost a fraction of a cent will create demand for decisions nobody would have paid an LLM to make.

Developer Flavio Copes put the core idea about as plainly as it gets in his deep-dive on the model: Jev is basically a smart if statement — the kind of conditional you'd reach for the moment the condition you actually care about is a judgment call rather than something code can compute directly.

Who built it, and why it matters that they did

Jev comes from TypeSafe AI, founded by Diogo Almeida, who spent time at OpenAI working on the instruction-following research that became part of ChatGPT's foundation. According to MindStudio's writeup of the launch, TypeSafe emerged from two years of stealth work with roughly $40 million in seed funding behind it, led by DCVC.

That pedigree matters for one reason: this isn't a hobby project or a fine-tuned wrapper around an existing model. TypeSafe built a new architecture, a new "parallel sampler," and a new training method from scratch, specifically because they decided the chat-model paradigm was structurally wrong for automation. Almeida's framing, straight from the announcement, is worth sitting with: language models have been "superhuman at chat for years," so why hasn't that translated into anywhere near as much real automation? His answer is that generating text one token at a time, meant to be read by a human, is the wrong shape for a decision meant to be consumed by code.

How Jev actually works under the hood

Here's where it gets genuinely interesting for anyone who builds software.

The training method: RLCD

Most chat models today are trained with RLHF (Reinforcement Learning from Human Feedback) or RLVR (Reinforcement Learning with Verifiable Rewards) — both of which optimize for outputs that a human rater or a verifier would approve of. Jev is trained with something TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), which optimizes for something different entirely: probabilities that are epistemically honest. A model that's 90% confident should be right roughly 90% of the time it says that — not overconfident, not randomly inconsistent between similar inputs.

That distinction sounds academic until you realize what it fixes. Ask a normal LLM to rate its own confidence and, per TypeSafe's own comparison table, it "tends to be overconfident and inconsistent" — which means if a model can actually do a task correctly 95% of the time but never signals when it's in the remaining 5%, your code can't safely automate around it. You'd be trusting a coin that doesn't know when it's about to land wrong.

Three primitives: Noul, Choice, Score

Every question you send Jev is one of three types, a breakdown Flavio Copes' guide lays out clearly:

• Noul — a yes/no question. Returns a single probability from 0 to 1 that the answer is "yes."
• Choice — pick one option from a fixed list you define. Returns the selected option, a full probability distribution across every option, and a confidence score.
• Score — a position on an ordered scale you describe (say, three levels of bug severity). Returns a probability-weighted score across the levels, plus the full distribution.

A request looks roughly like this (paraphrased from the public docs, not copied verbatim):

{
  "model": "jev-latest",
  "state": { "ticket": "Export button crashes the settings page in Safari. Works fine in Chrome." },
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "What kind of ticket is `ticket`?",
      "criteria": {
        "bug_report": "Something is broken or behaving wrong",
        "feature_request": "Asks for something that does not exist yet",
        "billing": "Charges, invoices, refunds"
      }
    },
    "severity": {
      "type": "score",
      "instructions": "How severe is the issue?",
      "criteria": [
        "Cosmetic, no impact on functionality",
        "Broken feature, workaround exists",
        "Blocking issue, no workaround"
      ]
    }
  }
}

And back comes a fully typed answer for both questions — plus, according to TypeSafe's own numbers, in around 70 to 500 milliseconds, against 3 to 329 seconds for a typical frontier LLM doing comparable work, and at $0.042 per million input tokens with output tokens free (because there's barely any output to generate in the first place). That pricing framing — "$42 per billion tokens" — is TypeSafe's own way of putting it on their homepage.

The practical limits worth knowing before you design around it

A few concrete numbers matter once you're actually sketching a request rather than just reading about the concept. The state and every question together share a combined budget in the tens of thousands of tokens, and the state plus your single longest question needs to fit inside roughly 32,000 tokens — call it somewhere around 150,000 characters of plain English if you're mentally budgeting. A Choice question can offer up to 255 distinct options, and a Score can have anywhere from 2 to 10 ordered levels. None of these are limits you'll bump into for a typical support-ticket or lead-scoring question, but they matter the moment you try to feed Jev an entire document, a full conversation history, or a genuinely long list of candidate categories.

It's also worth knowing that Jev currently reads text only — plain strings, JSON objects, or arrays of text. No images, audio, or video yet, which rules out a chunk of the "classify this upload" use cases people will inevitably try first.

Why parallel sampling is the actual unlock

A normal LLM generates one token at a time, each conditioned on the last — that's why a longer answer takes proportionally longer. Jev's architecture evaluates every question against the same state independently and in parallel, so adding a fourth or fifth question barely moves the response time. This is the detail that makes the whole "ask everything at once" workflow pattern make sense, which we'll come back to.

Three usage patterns worth stealing before you write your first Jev question

Before getting into the DIY architecture sketch, it's worth covering the practical patterns that early adopters — and TypeSafe's own documentation, per Flavio Copes' extensive write-up — keep converging on. These matter regardless of whether you ever touch Jev directly, because they're really patterns about how to think about cheap, parallel decisions in general.

1. Ask everything at once ("speculative fan-out"). Because every question in a request runs in parallel against the same state, and each additional question only costs its own extra tokens rather than a whole new round trip, the right instinct with Jev is the opposite of how you'd design an LLM workflow. Instead of asking one question, waiting, then deciding what to ask next, you front-load every independent question you might conceivably need — including ones whose answer will only matter for some inputs — and let your code decide afterward which answers to actually use. One published cookbook example batched thirteen questions into a single call and came out roughly 12x cheaper and 10x faster than asking them one at a time, mostly because the shared context only had to be sent once instead of thirteen times.

2. Compose decisions in code, don't ask one giant question. If a real-world judgment depends on several independent factors — say, ticket priority depending on severity, customer frustration, and how much detail the report includes — the temptation is to ask Jev one big "how urgent is this?" question. The pattern that works better is asking three separate, narrow Score questions and then combining them yourself with weights you control:

const score =
  0.6 * normalized(answers.severity) +
  0.3 * normalized(answers.frustration) +
  0.1 * normalized(answers.report_quality)

The advantage isn't just accuracy — it's that when the resulting ranking doesn't match what your team would actually decide, you adjust a coefficient and rerun, instead of rewriting a prompt and hoping the new phrasing doesn't quietly break something else.

3. Gate actions on confidence, not just the answer. A Choice or Score response always comes back with a confidence value alongside the actual answer — computed from how concentrated or spread-out the underlying probability distribution is. The practical pattern is a three-tier gate: act automatically above a high threshold, ask for human confirmation in a middle band, and route to a person entirely below a low threshold. Where exactly those thresholds sit is genuinely domain-specific — TypeSafe's own docs use 0.5 as an example "needs review" floor and 0.9 before letting a destructive action proceed unconfirmed, but those are illustrative starting points, not universal defaults. You're meant to run Jev against your own labeled data first and tune from there.

What if you wanted to build something like this yourself?

You obviously can't rebuild TypeSafe's proprietary architecture over a weekend — RLCD and their parallel sampler are genuinely novel research. But the shape of what they built is something any decent engineer can reason about, and honestly, sketching it out is the fastest way to actually understand why it's fast.

Picture a much dumber, DIY version:

1. Fix your answer space in advance. Instead of asking an LLM "what should happen here?" and parsing free text back, you predefine every possible answer as an enum, before the model ever sees the input. This alone removes an entire category of failure — the model literally cannot return something outside your schema, because you're not asking it to generate a string, you're asking it to choose or score.
2. Batch every independent question into one call. If you're already paying for one model invocation with the full context loaded, asking five unrelated questions about that same context is nearly free compared to five separate round trips. This is the same intuition behind function-calling batches, just pushed further because there's no sequential text generation cost per extra question.
3. Turn every output into a probability, not a label. Instead of returning "category": "billing", return a distribution across every category you defined. This is genuinely the biggest mental shift — a naive classifier gives you an answer; a calibrated one gives you an answer and how much to trust it.
4. Train (or at least evaluate) against calibration, not just accuracy. A model that's right 90% of the time but never tells you which 10% it's guessing on is far less useful in production than one that's right 85% of the time but honestly flags its own uncertainty. This is the part that actually requires real ML research to do well — you can fake steps 1 through 3 with a system prompt and a JSON schema on top of any existing LLM today, but getting genuinely calibrated confidence out of it is a much harder, much more interesting problem, and it's the part TypeSafe spent two years in stealth actually solving.

If you want to feel this difference yourself without waiting on Jev access, the closest thing available right now is forcing structured outputs on an existing model — the Vercel AI SDK's evaluation function actually supports this exact comparison, letting you run the same typed questions through GPT or Claude via an adapter alongside TypeSafe's own model, so you can see the gap in latency, cost, and self-reported confidence directly.

Cool alternative example: someone already shipped a real tool with it

Within days of launch, a developer named Tamara Tran published fast-jev-compaction — a genuinely clever open-source Claude Code plugin, and one of the clearest "this is what Jev is actually for" examples floating around right now.

The problem it solves: when a long coding-agent session runs out of context, most tools compact it by asking an LLM to summarize the old messages. Summaries are lossy — a specific file path, an exact error string, or a constraint mentioned twelve turns ago can quietly vanish, and you don't find out until the agent breaks something it "forgot" about.

Tran's plugin does something different. Instead of summarizing, it asks Jev two simple yes/no questions about every old tool call in the transcript: should this call stay, given everything else in the conversation, and separately, should its result stay verbatim. Anything that should stay, stays exactly as written — never rewritten, never paraphrased. Anything Jev is confident is no longer needed gets dropped or truncated. Nothing is ever hallucinated back into existence, because nothing is being regenerated — only kept or removed.

The technical details are worth appreciating: the tool sends Jev the entire conversation state on every batch, splits questions across multiple parallel requests to stay under Jev's context window, and lets you tune a keepThreshold for how conservative the pruning should be. Since its launch it's already picked up over 3,000 GitHub stars and more than 170 forks — a strong early signal that "delete precisely, never summarize lossily" is a real pain point Jev happens to be unusually well-suited for.

It's a small tool, but it's a genuinely good illustration of the core idea: nobody needed Jev to write anything here. They needed a fast, cheap, trustworthy yes/no on a few hundred old tool calls, over and over, every time a session got long. That's the whole category.

What people are actually building with it right now

It's been less than a week since launch, so none of this is "production case study" territory yet — but the range of early experiments says a lot about where developers instinctively reach for this kind of model.

Games and real-time loops. TypeSafe's own launch demos included a Doom bot making roughly ten decisions a second purely from structured game state (at an estimated $7/hour), and a Wikiracing bot navigating Wikipedia's link graph by choosing among hundreds of options per step without ever picking a link that didn't exist. MindStudio's coverage also describes a Subway Surfers-style dodge/jump/duck demo and a simulated drone navigating an obstacle course from structured position and distance data — the common thread being tasks that need split-second reactions, not conversation.

Routing and triage. The most commonly proposed production use so far is intent routing — put Jev in front of a support inbox, an agent pipeline, or a helpdesk, and let it decide which handler, model, or human a request should go to, before anything expensive gets involved. LangChain shipped a native integration for exactly this within days of launch, exposing Jev through a TypeSafeClassifier that plugs into existing chains alongside every other model provider LangChain already supports.

Data labeling at a scale that used to be uneconomical. DataCamp's writeup cites an early benchmark where Jev classified over a thousand research papers across two dozen topics for a fraction of a dollar, at roughly a quarter-second per paper — the kind of bulk classification job that was technically possible with a full LLM before, just rarely worth the bill.

Verification, not just generation. A quieter but arguably more interesting pattern is using Jev to check work an LLM already did, rather than to do the original task. One proposed workflow starts with an existing pipeline that generates episode summaries with a full LLM, then runs each individual claim in that summary back through Jev against the original transcript, asking a simple "does the transcript actually support this claim" Noul for every sentence. The generative model still does the writing; Jev becomes the cheap, fast fact-check layer sitting after it, flagging anything with low confidence for a human to look at before it ships. The same shape works for code review — running a handful of Score and Noul questions per changed file in a pull request (security risk, complexity, whether the commit message actually describes the change) and combining them into a risk score in code, rather than asking a full LLM to "review this PR" and parsing prose back out.

Turning free text into features for ordinary machine learning. This one's less flashy but genuinely practical: instead of using Jev's output directly as a decision, you use a batch of Jev questions to turn unstructured text into a set of numeric columns — then feed those columns into a classical model like a gradient-boosted tree. One published example started with eighteen questions and, across a few rounds of refinement, grew to nearly forty, producing dozens of usable numeric features from raw text without hand-engineering any of them.

There's also a real thread of people documenting their own builds on X as they get early access. Roman, who posts regularly about building SaaS products in public, walked through wiring Jev into a working project within his first day of access — the kind of build-log thread that's genuinely more useful than a launch demo, because it shows the rough edges too. Moritz Kremb shared his own hands-on look at getting a real use case running with it, and Sydney Runkle — an engineer at Pydantic, a company whose entire job is structured, type-safe data — weighed in on the launch with the kind of plain-language framing that made the rounds precisely because it cut through the "revolutionary" marketing language and explained, simply, what problem this actually solves for people already fighting with structured output from regular LLMs.

Jev versus the tools you're already using

It genuinely doesn't compete with ChatGPT, Cursor, or Claude Code — it's built to sit inside them, not replace them.

Tool	What you give it	What comes back	Its job
ChatGPT	A prompt or conversation	Generated text	General assistant
Cursor / Claude Code	A coding goal + repo access	File edits, commands, results	Coding agent
Jev	State + typed questions	Choices, scores, probabilities	A decision primitive

A coding agent could call Jev before running a risky shell command, to classify it as read-only, reversible, or destructive — and only proceed automatically above a confidence threshold you set. A support platform could use Jev to decide whether a ticket needs a database lookup, a full LLM response, or a human, before spending money on the expensive path. The generative model still writes; Jev just decides which path gets taken, extremely fast, and (crucially) tells your code exactly how sure it is.

The cost and speed numbers, and why the gap matters more than it looks

The headline numbers — 40x to 200x faster, and dramatically cheaper per call — are easy to read as marketing hyperbole, and TypeSafe itself is upfront that their published multiples sit at the high end of what you'd see in the real world. But the underlying mechanism behind the gap is real, not just clever pricing.

A frontier LLM generating a structured JSON response still has to generate every output token sequentially, and it's priced against both input and output tokens — output tokens typically running several times more expensive than input. Jev skips text generation almost entirely, which is exactly why TypeSafe can offer output tokens for free: there's barely anything to meter. That's not a discount decision, it's a structural consequence of the architecture.

Here's the arithmetic worked out simply, since the raw multiples don't mean much without it. A typical support-ticket triage question, state plus a handful of typed questions, runs around 300 tokens in TypeSafe's own published examples. At $0.042 per million input tokens, that's roughly $0.0000126 per call — call it $1.26 to triage 100,000 tickets of similar size. Run that same volume through a general-purpose frontier LLM at typical structured-output pricing and you're looking at a bill that's easily 20-50x higher, before you even account for the extra latency of waiting on sequential token generation for each one.

Where this actually shows up isn't in one flashy demo — it's in workflows that make the same kind of decision thousands or millions of times. A company running a classification step over every row of a large dataset, or a routing check on every single support message, is the exact shape of workload where shaving 40x off cost and latency compounds into something that changes what's economically viable to automate at all — rather than a one-off call where the difference barely registers.

Where Jev genuinely breaks

No credible writeup of this launch skips the limitations, and TypeSafe itself publishes a running list of what the current model handles badly. The honest version, worth knowing before you reach for it:

• It cannot do arithmetic reliably. Counting characters, comparing numeric values, or reasoning about dates as text are all weak spots — that logic belongs in your code, not in a Jev question.
• It reads the question you wrote, not the one you meant. Precision in your criteria matters enormously; vague instructions produce vague, low-confidence answers.
• It cannot write anything. No summaries, no explanations, no generated replies — if the task needs prose, you still need a real LLM alongside it.
• A Score is not a precise measurement. It's a probability-weighted position on a scale you defined, useful for thresholds and ranking, not for reconstructing an exact numeric magnitude — a 1.4 doesn't mean "40% of the way from level 1 to level 2" in any rigorous sense.
• Indirection tanks accuracy. Double negatives, a property nested inside a property, anything that needs the model to hop through several logical steps to reach the actual answer, all perform noticeably worse than a question that points straight at the relevant part of the state.
• A typed answer isn't automatically a correct one. A Choice will always return one of the options you allowed it to — that's the whole guarantee — but it can still confidently pick the wrong one. Schema correctness and semantic correctness are genuinely two separate problems, and treating "it returned valid JSON" as "it got the right answer" is the single most common early mistake people report.

If you need to count how many items in a list match some fuzzy condition — "how many of these five reviews are actually positive" — the fix isn't to ask Jev to count. It's to ask one Noul per item ("is this specific review positive?") and sum the results yourself in code. The counting stays in code; the judgment stays with the model.

None of that undercuts the core idea — it just draws the actual boundary of where a "decision model" is the right tool versus where you still need a model that can reason and write.

Why this actually matters if you're building B2B or SaaS products

For anyone running the kind of AI-agent stack we've written about before — scoring leads, triaging inbound messages, or deciding what a scraped signal is actually worth before spending an LLM call on it — Jev's whole pitch is directly relevant. A huge share of what people currently pay full LLM prices for isn't generation at all; it's classification wearing a chat model's clothing. Is this lead worth a follow-up? Which of our five categories does this ticket belong to? Is this shell command safe to run unattended? None of those questions need a paragraph back — they need a fast, cheap, trustworthy answer with a confidence score attached, which is exactly the gap that a guardrail layer like the kind covered in our piece on the fight over AI agent sandboxing keeps running into: agents need a cheap way to check their own actions before they take them, not just after.

If even a third of what your agent stack currently spends on full LLM calls is secretly a classification task, this is worth thirty minutes in the playground to find out.

There's a simple back-of-envelope way to check before you spend that thirty minutes: pull last month's AI provider invoice, and go line by line asking "did this call return a piece of writing someone read, or did it return a label, a route, a yes/no, or a score that code then acted on." Anything in the second bucket is a candidate. Most teams running AI-heavy products for more than a few months are surprised by how large that second bucket actually is — inbox triage, lead scoring, moderation flags, and routing decisions all tend to hide inside a chat-completion API call long after nobody's reading the "chat" part of the response anymore.

It's also worth being honest about what doesn't change. Jev doesn't reduce how much you spend on the actual generative work — the emails your product writes, the code your agent produces, the summaries your dashboard shows. It only touches the decisions sitting around that generative work, deciding whether it should run at all, and on what. For a product that's mostly generation with very little routing or classification in between, the realistic saving is small no matter how good the per-call multiple looks on a slide.

Two ways to close this out

If you build things: this is worth an actual afternoon, not a bookmark. Sign up for early access, don't touch the example prompts, and instead paste in one real, boring, recurring decision your own code already hardcodes badly — a support-routing rule, a spam filter, a "is this command safe" check. Run it beside your existing logic for a week before you let it touch anything. The unglamorous decisions are exactly where this model is built to live.

If you're skeptical (reasonably): the fair critique isn't that Jev doesn't work — early, independent writeups from Flavio Copes, DataCamp, and LangChain all corroborate the basic mechanics. The fair critique is that "40x-200x faster" only matters for the slice of your AI spend that's actually classification dressed up as chat completion. For a lot of products, that slice is smaller than the headline number wants you to assume. Measure your own workload before you believe either extreme.

Either way, System One models are a genuinely new shape of tool, not a rebrand of something that already existed — and the fact that a real open-source project shipped useful, non-trivial code on top of it within days of a waitlist-gated early access period is a better signal than any launch benchmark could be.