Jev by TypeSafe: A Model That Returns Typed Decisions Instead of Text

One new model from TypeSafe skips text generation entirely. What it returns is a typed decision with a probability attached, and that changes which parts of your code an AI model is allowed to occupy.

The model is called Jev, and it's the first of what the company labels System One Models. The name borrows from the Kahneman split between fast, automatic thinking and slow, deliberate thinking. Jev takes the fast half, and the deliberate half stays with large language models.

Its announcement post on typesafe.ai climbed Hacker News to nearly a thousand points, drew more than 300 comments, and about half of those argued over the title. It reads like yet another small, fast, cheap model launch, and it isn't one. Jev doesn't write at all, since there is no text output. So it doesn't really compete with the chat models you already use. It competes with an if statement.

The if statement everyone keeps apologizing for

Nearly every pipeline has one rotten spot. Somewhere in the middle, a judgment call has to be made. Should this ticket jump the queue? Does this reply sound rude? Is this row worth keeping?

For years that spot was filled with rules: keyword lists, regexes, a threshold tuned on some Tuesday and never revisited. Those break the first time a customer writes politely while furious.

So teams put an LLM there instead. It works, and it also wrecks the pipeline. A single judgment can cost around eight seconds, and the JSON parse fails on row four hundred. You can't run it per item across a large dataset or inside a loop, and you certainly can't run it in something a user is waiting on.

Intelligence was never the problem

The real pain is placement, and it has little to do with models being too dumb for the work. The smartest models sit at the edges of the software, while the inner loop is still packed with regexes.

What TypeSafe shipped

The founder sums it up in one line: a frontier-intelligence function call that takes unstructured state in and returns typed, probabilistic decisions.

You give it a state, which might be a support ticket, a document or a game frame serialized as text, plus a dictionary of questions. It sends back typed answers. There are only three question types, and that's the whole surface:

• Choice picks one option from a set. It returns the selection, a probability for each option and a confidence value.
• Score rates something against ordered, described levels, and returns the same set of values.
• Noul is a yes/no question, answered as the probability that the answer is yes.

All questions in a call are evaluated in parallel, each in isolation, against the same state in one pass. That's why TypeSafe says extra questions hardly move the response time. The cost is per call, and not per question.

The quoted latency runs from 70 ms to 500 ms end to end, and pricing is $42 per billion input tokens with output free. Whether that figure means what it seems to mean comes up again further down.

The whole API

The quickstart begins with a single import:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

Then a support ticket goes in and three judgments come back:

client = TypeSafeClient()ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP."response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

There's no prompt engineering, no "respond only with valid JSON" instruction and no retry wrapper. Three judgments arrive in one round trip. Python and JavaScript SDKs sit on top of one POST endpoint.

The part that changes how you write code

An LLM answer shows up with the same flat certainty whether the model knows or is guessing. Jev returns a distribution instead.

The training method is RLCD, short for Reinforcement Learning for Calibrated Decisions, and its aim is for those probabilities to track how often the model is actually right. That means you can branch on doubt:

• Above 0.9, route the item automatically.
• Between 0.6 and 0.9, escalate to a bigger model.
• Below that, put it in front of a person.

That's a branch many teams have wanted for years. Until now they've faked it with an LLM's self-reported confidence, which has about as much predictive power as astrology.

What testers did on day one

Early users ran a series of experiments, and one of them shows the shape of the product better than any benchmark table. A writer at a media company gave Jev all 27 of his published articles plus 10 fakes deliberately written in an AI style. He asked 21 concurrent questions about common signs of machine writing. In total that came to 777 judgments over 37 documents. They all came back in less than 0.7 seconds, at a cost near a quarter of one cent.

The company's CEO followed up with four checks across 12 passages, run head to head against a frontier LLM. Jev needed a median of 0.35 seconds per passage and the LLM needed 8.83. That's about 25 times faster, and by their count roughly 580 times cheaper.

The Doom demo

One demo is what made it click for the Hacker News crowd. TypeSafe hooked Jev up to play Doom. It wasn't reading pixels. It received the game state serialized as structured text, at about ten queries a second. The engineer who built it reportedly worried about that query rate, which works out to around $7 an hour.

An AI sitting inside a game loop is the whole pitch, made literal.

Where it falls down

The homepage promises "Zero Hallucinations," and that's the claim most worth pushing back on. What's guaranteed is that the output matches your schema, so a Choice always lands on one of your options. That isn't the same as being right. Jev can return a valid, confidently wrong answer, and the Hacker News thread said as much at length.

The writer's experiment backs that up. Seven defects had been planted in the test set. Jev found six and overlooked one, a paragraph on a shared calendar that parents and staff "teach together." The comparison LLM spotted that one. His own verdict was candid: more careful accuracy testing should come first if it's headed for production.

The hard limits are real as well:

• The context window is 32k tokens, which rules out whole-repository work.
• A Choice tops out at 255 options.
• There's no image input yet.
• The architecture is kept close to the chest. There's no paper and no independent evaluation of RLCD, only early testimonials.

The price isn't the swap you think it is

$42 per billion input tokens looks absurdly low next to a frontier model, but the unit is different. What you buy is judgments, and you'll make far more of those than you ever made LLM calls. The low per-token rate is what allows ten calls a second. It isn't a simple subtraction from your current bill.

It's also early access with a waitlist, so you may read about it before you can try it.

Is it worth your attention?

Yes, though not because of the speed multipliers. Jev stands out because it's honestly scoped. It doesn't chat, doesn't reason out loud, doesn't explain itself and doesn't pretend otherwise.

Its single job is converting untidy input into a typed decision that your compiler can check, and doing it quickly enough to sit inside a loop. Maybe your product has a chat model stuck into a spot that really needs a judgment. For that situation Jev offers a genuinely different fix. Expect to build around the confidence value more than around the latency.

Run it on your own data before it gets near anything important, which is the advice early testers keep repeating. Many people already doubt that one do-everything text model is the right tool for narrow tasks, and this is the first serious attempt at something different.