Most AI you use writes. You ask a question, it produces a paragraph, and if your program needs a real answer out of that paragraph, you parse it, hope the JSON is valid, and add a retry for when it isn’t. The intelligence is great. The shape of the output is a hassle: it’s text, and text has to be turned back into something your code can use.

Jev, released by Typesafe in September 2026, is a different shape. You hand it your program’s state and a typed question, and it hands back a typed decision with a confidence score. No paragraph. No parsing. No “please respond only in JSON.” The answer is already the thing your code needed.

It’s worth knowing who’s behind it, because it sets the ambition: founder Diogo Almeida says he helped invent ChatGPT, then spent two years in stealth on a new training method and this new model. His launch framing was blunt, “20 to 200x faster, 40 to 400x cheaper, output tokens free,” and it landed: tens of millions of views in a day. Big claims deserve a close read, so let’s actually look at what it is.

A normal LLM
in: "I was charged twice, help ASAP"
out: "It sounds like you're dealing with a billing issue. I'd be happy to help..."
Now your code parses that back into fields, and handles the times it comes out malformed.
Jev
in: "I was charged twice, help ASAP"
out: billing: 0.98 · tone: angry · urgency: high
Typed values with confidence, ready to branch on. Nothing to parse, nothing to retry.
Same input. One returns prose you have to decode; the other returns the decision itself. Typesafe calls this a "System One" model: fast, structured decisions software can use directly.

System One, not System Two

The name is a nod to Kahneman: System 1 is fast, intuitive, automatic; System 2 is slow, deliberate reasoning. Today’s frontier LLMs are wonderful System 2 machines, they think out loud, at length, and that’s exactly what you want for writing code or an essay. But a huge amount of what we actually wire AI into isn’t essay-writing. It’s small, fast judgments: is this spam? which queue does this ticket go to? how risky is this transaction? does this text mention billing?

Those are System One tasks, and using a text-generating model for them is like hiring a novelist to answer yes/no questions. It works, but it’s slow, expensive, and it might write a paragraph when you needed a boolean. Jev is built for that fast lane instead.

How it actually works: one pass, not a token loop

This is the core idea, and it’s worth slowing down on. An LLM generates text one token at a time. To produce a 500-token answer it runs itself about 500 times in sequence, each run feeding the next. That sequential loop is why responses take seconds and why you pay per output token.

Jev doesn’t generate text at all. Because the set of possible answers is fixed before it runs (pick one of these options, a score on this scale, a yes/no probability), it can score every possible answer in a single forward pass.

LLM: one token at a time
Itsoundslikeabillingissue, so...
hundreds of sequential passes → seconds, billed per output token
Jev: all answers at once
billing 0.98tone: angryurgency: high
one pass over a fixed answer set → milliseconds, output not metered
The top row appears one token at a time, that's the LLM's decode loop, the real bottleneck. The bottom row lands all at once. When there's no token stream to generate, there's no per-token output cost, which is why Typesafe meters input only.

Two consequences fall straight out of this. First, it’s fast: Typesafe quotes 70 to 500 milliseconds end to end. Second, it structurally can’t hallucinate a field that doesn’t exist or emit malformed output, because strings were never the output format. If the only allowed answers are calm or angry, it cannot return slightly miffed or a broken bracket. That’s a 0% type-error rate, guaranteed by construction, not by hoping.

The three things you can ask it

You compose real logic out of three primitives. Choice and Score return their value plus a calibrated confidence; Noul returns a 0 to 1 probability that is itself the calibrated answer. You can bundle many into one call, and they all run in parallel and in isolation against the same state.

Choice
Pick one from a fixed list of options (up to 255).
tone → calm | angry
Score
Rate against a scale or rubric you define.
urgency → low | medium | high
Noul
A calibrated yes/no, returned as a probability from 0 to 1.
billing? → 0.98
Choice, Score, Noul. Typesafe's guidance: keep each question narrow and specific, then combine them in your own code, rather than asking one giant multi-part question.

In practice a call reads like a set of typed questions asked of one piece of state:

from typesafe_sdk import TypeSafeClient, Choice, Score, Noul

client = TypeSafeClient()
result = client.system_one(
    "I was charged twice. Please help ASAP.",
    {
        "billing": Noul(instructions="Is this about billing?"),
        "tone":    Choice(instructions="What is the tone?",
                          criteria={"calm": None, "angry": None}),
        "urgency": Score(instructions="How urgent is this?",
                         criteria=["low", "medium", "high"]),
    },
)

result.nouls["billing"].noul   # 0.98
result.choices["tone"].choice  # "angry"
result.scores["urgency"].score # "high"

Confidence you can actually branch on

Here’s the part that matters more than the speed. Jev is trained with a method Typesafe calls RLCD, Reinforcement Learning for Calibrated Decisions. Where ChatGPT-style RLHF rewards answers humans prefer (which quietly trains confident-sounding over honest), RLCD rewards the confidence numbers being right on average, using proper scoring rules like the Brier score.

Calibration means exactly what a good weather forecast means: on the days a forecaster says “70% chance of rain,” it should rain about 70% of the time. Applied to your code, that’s the useful bit, a confidence score you can set a threshold on.

when Jev says X% confident, it's right about X% of the time
says 95%act
says 80%act
says 55%escalate
High confidence, let the code act. Low confidence, route it to a human or a slower model. The score is a real dial, not decoration.
An overconfident model gives you a number you can't trust, so you can't threshold on it. A calibrated one turns "how sure are you?" into an if-statement.

I ran it, so here’s real data, not a claim

I got an API key and pointed Jev at 320 product reviews where I already knew the true sentiment, including 19 deliberately mixed ones. The whole run: 320 decisions in 7.8 seconds, 97.8% accurate, and it cost me under half a cent (Jev bills input only, and this run was about 92k input tokens). The same 320 decisions on a mid-tier LLM, made to emit a structured answer each time, works out to roughly 72x more expensive on token pricing alone.

But the number I actually care about is this one. When I split Jev’s confidence by whether a review was clear-cut or genuinely mixed, the confidence tracked the ambiguity on its own:

Jev's average confidence, split by how clear the review was (real run, n=320)
clear-cut reviews98%
genuinely mixed reviews64%
"Overpriced and underwhelming in every way." → negative, 0.99
"Loved the location, hated the noise."0.53, it's genuinely torn, and it says so
Nobody told Jev which reviews were ambiguous. It reported high confidence on the obvious ones and low confidence on the truly mixed ones, entirely on its own. That gap is the whole product: you can auto-act on the 98% ones and route the 53% ones to a human. Ask an LLM the same and it'll say "99%" to both.

This is the thing an LLM can’t hand you. Not the answer, LLMs classify sentiment fine, but a confidence number honest enough to branch on, produced fast and cheap enough to run over your whole dataset. That combination is what “System One” is for.

Try it yourself: I put a live version up at jev-live-demo-production.up.railway.app. It runs Jev and a real LLM side by side on the same review, at the same moment. Type a genuinely mixed one (“loved the location, hated the noise”) and watch both the speed gap and the confidence gap: Jev answers in ~150ms and honestly drops to around 50%, while the LLM takes over a second and still says 80%. That overconfidence, live and next to Jev, is the whole argument in one screen. There’s also a “run the benchmark” button for the clear-vs-ambiguous split.

Typesafe’s own headline numbers put the speed and cost side on one picture. Read them as vendor claims, not gospel (more on that below), but the shape matches what I measured:

Typesafe's published claims: a customer-support triage decision
LLM latency3 to 329 s
Jev latency70 to 500 ms
LLM cost / Mtok$0.20 to $10
Jev cost / Mtok$0.042 + free out
bars are relative, not to scale across the two pairs · 20 to 200x faster, and cheaper still, on decision-shaped tasks
The gap is roughly two orders of magnitude on both axes. That is the entire reason to care: not that Jev is smarter, but that for a small decision it is dramatically faster and cheaper than making an LLM write one.

The pitch, in one table

Frontier LLMJev (System One)
OutputText you parseA typed value, ready to use
How it runsToken by token, in sequenceAll answers in one pass
Latency (Typesafe's numbers)3 to 329 seconds70 to 500 ms
Cost$0.20 to $10 / Mtok in, output ~5x more$0.042 / Mtok in, output free
Malformed / invalid outputPossible, needs retriesImpossible by construction (0% type errors)
ConfidenceOften overconfident, hard to trustCalibrated, safe to threshold on
Best atOpen-ended writing, reasoning, codeFast structured decisions: classify, route, score, extract
Numbers are Typesafe's own published claims. They're not competing with LLMs at writing, they're competing at the small decisions you currently overpay an LLM to make.

Good places to reach for it: classification, routing, scoring, extraction, real-time loops (their demo plays Doom at ~10 decisions a second), map-reducing a judgment over a big dataset, and guardrailing an LLM’s output. Bad places: anything that needs to write, reason step by step, or hold a conversation. The thing that makes it fast is the thing that makes it narrow.

Where I’d be skeptical

I like this a lot, and I want to be honest about what isn’t proven yet, because it’s early and the marketing is loud.

The benchmarks aren’t independent. Typesafe evaluated Jev with “workflow evals” that compare its answers to the average of two frontier LLMs, not to verified ground truth. That measures agreement with other models, not correctness. If both reference models are wrong, Jev can “win” while being wrong too. On at least one chart they shared, its raw accuracy sat below a strong LLM even as it dominated the cost-and-speed frontier.

“Can’t hallucinate” is a precise, narrow claim. It means it can’t emit an invalid type, a value outside the allowed set. It can absolutely still be wrong: pick a valid option that’s the incorrect one. Typesafe says as much in a follow-up titled “Where Jev Actually Fails.” Type-safe is not the same as correct.

There’s no paper. As of now the architecture and the RLCD loss function are unpublished. The CEO has confirmed RLCD exists by name; the rest (“encoder-only? diffusion?”) is informed speculation. Treat the internals as a black box for now.

Free output “too cheap to meter” is a launch price, and the founder openly says they can’t yet prove it isn’t subsidized. Nice while it lasts; don’t architect around it being free forever.

The idea worth keeping

Even if you never use Jev, the framing is the takeaway: a lot of what we bolt LLMs onto isn’t a writing task, it’s a decision task wearing a writing task’s clothes. We’ve been paying for a paragraph and a JSON parser when we wanted a typed value and a confidence score. A model shaped like the decision, fast, bounded, calibrated, is a genuinely good idea. Whether Jev is the one that nails it is what the next year will tell.

Sources, all primary: Typesafe’s launch post, their docs, and the code example from the Python SDK docs. Written from scratch; nothing copied.

← Back to blog