System 1 Models: Why JEV and Laya Are Suddenly Everywhere

The most interesting model released this month can't write you a sentence.

TypeSafe AI came out of stealth on September 15 with a model called Jev. It doesn't generate text. It won't write your code, summarize your docs, or hold a conversation. You hand it some state and a question with the answers enumerated in advance, and it hands back one of those answers with a probability attached. That's the entire product.

The Hacker News launch thread hit 1,978 points and 513 comments. Nine days later the community tracker madewithjev.com was counting 275 repos built against it, and at least five open-weights clones existed. One of them, Laya, is the number one trending model on Hugging Face as I write this, ahead of Qwen's latest image model.

That's a lot of movement for a category that didn't have a name three weeks ago. So here is what these things actually are, which claims hold up, and which ones fall apart when you check them.

What a System 1 model actually is

The name borrows from Kahneman: System 1 is fast and automatic, System 2 is slow and deliberate. Simon Willison prefers "decision models" and so do I, because it describes the thing rather than gesturing at a pop-psychology book. System 1 is the name that stuck anyway.

The architecture is the part worth understanding. An autoregressive model emits a token, conditions on it, emits the next, and repeats. When you want structured output from one, you ask nicely for JSON, parse the string it gives back, validate it, and then handle the case where it gave you something else.

A System 1 model doesn't generate tokens at all. One forward pass, and the answers get read off dedicated output heads.

The difference isn't speed for its own sake. It's that the output space is fixed before inference starts.

Because the options are enumerated up front, a type error isn't unlikely. It's unavailable. No string to parse, no retry logic, no regex salvage operation at 2am.

Three answer shapes cover nearly everything: Choice picks one of up to 255 options, Score places the input on an ordered scale, and Noul returns a yes/no probability. Every answer arrives with a full probability distribution rather than just a winner.

Why this is landing now

Agent loops are where this bites. Loop engineering means every turn runs the same handful of small decisions: is this task done, does this need a human, which tool comes next, is this output safe to ship. None of those are reasoning problems. They're classification problems that got handed to a reasoning model because a reasoning model was the only thing on the shelf.

That's fine at ten decisions a day. It's ruinous at ten million. Look at what TypeSafe published:

Vendor-reported figures from TypeSafe's own evals, which is worth remembering when you read them.

Read the x axis, not the y axis. Jev scores 67.8% where GPT-5.6 Terra scores 67.9%, and it loses outright to GPT-5.6 Sol at 74.1% and Claude Opus 5 at 73.1%. Jev is not the smartest model on that chart. It's the cheapest by roughly two orders of magnitude, and it answers in 0.4 seconds instead of 37.

That's a genuinely good pitch. It just isn't the pitch the launch led with.

The genuinely new part is calibration

Most frontier models are tuned on human preference. Jev was trained with what TypeSafe calls Reinforcement Learning for Calibrated Decisions, using strictly proper scoring rules such as log loss and Brier score as the reward signal.

Strictly proper scoring rules have a property that makes them the right tool here: they're maximized only when the model reports its true belief. You can't win by being confidently wrong, and you can't win by hedging everything to 0.5. Train against that objective and honest probabilities stop being a nice-to-have and start being the optimal strategy.

Accuracy tells you how often a model is right. Calibration tells you whether to believe it when it says it's sure.

This matters more than the latency does. A model that's accurate but can't tell you when it's unsure is not automatable, because every answer needs a human to check it. A slightly less accurate model with honest probabilities is automatable, because you can set a threshold, act on everything above it, and route the rest somewhere slower.

"Can't hallucinate" is doing a lot of work

The launch oversold this part and the thread caught it within the hour.

TypeSafe put 0% on a hallucination chart. What that number actually measures is that the output always matches the schema. Those are two different claims. As jacobgold put it: "Sure, it can't emit an invalid type, but it can still emit a completely wrong valid value." WhitneyLand was blunter: "Type safety is not factual correctness."

TypeSafe's CEO replied in-thread with what I think is the more honest framing: "I don't think it's fair to say a random forest 'hallucinates' in the way LLMs do." Fair enough. You'd just say it was wrong. But a wrong answer that validates cleanly is still wrong, and inside an automation path it's arguably more dangerous, because nothing downstream is going to flag it.

Willison's objection is the one I'd weigh hardest. "Put in all the text you want, the only thing you're going to get back is a floating point number." No rationale, no citation, nothing to audit. He specifically warns against reaching for these to rank job applicants, where "that floating point number could conceal all manner of unseen bias." He's right. Constrained output is a safety property for your parser, not for the people your software acts on.

Calibration doesn't travel

The sharpest technical critique of the week came from Alex Molas in "Jev Can't Be Calibrated". His argument: calibration is not purely a property of a model, it's a property of a model evaluated on a distribution. Jev returns the same probability no matter what your base rates look like. Calibrated on TypeSafe's synthetic training data, quite possibly miscalibrated on your support queue.

He also points at a circulating example of Jev assigning a fair coin a 0.92 probability of landing heads, with the fairness stated explicitly in the prompt. That's not distribution shift. That's just wrong.

The fix is old, cheap, and well understood: pull a few hundred labeled examples from your own data and fit Platt scaling on top of the raw scores. Until you've done that, treat the output as a ranking signal rather than a probability.

The open-weights scramble, and the Laya paradox

The cloning was fast. Jared Palmer trained Kev on Qwen3.5 and published Apache-2.0 weights for about $95 of H100 time. Together AI shipped Tev1. CLM, reflex-s1 and others followed within days. Arcturus Labs said the quiet part: "Architecture-wise, I don't think there's much of a moat."

Which brings me to Laya, the 421M-parameter model built on ModernBERT-large that currently sits at number one on Hugging Face trending. Its model card claims 0.766 accuracy against Jev's 0.727.

Then you check an independent harness.

Same model, same week, two numbers that point in opposite directions.

JevBench scores 77 systems across intelligence, calibration, speed and cost, using 534 public decisions plus 308 sealed ones and a penalty for overfitting the public set. Jev ranks first at 63.3. Laya ranks 36th at 30.3.

Both things are true at once. Laya is the most-liked model on Hugging Face right now, and it's 36th on the only independent leaderboard the category has. Trending rank measures how many people find an idea interesting, and that's a real signal, just not about quality. The appetite is the story. A 421M decision model outranking image generators tells you how badly developers want this to work.

That gap between self-reported and measured is one I run into constantly in my own work. What a vendor publishes about itself and what an independent harness finds are different species of number, and the distance between them is usually the most informative thing on the page.

The use case I keep coming back to

One of the projects I run is AXRank, and the tagline is the whole idea: agent experience, graded. Every company with an API now has a second audience it didn't design for. Not the developer reading your docs, but the agent trying to complete a task against your product at 3am with no human to ask. Almost nobody measures how that goes, so AXRank does.

It works by pointing frontier agents at the real product and watching what happens. Each service gets a score out of 100 across several dimensions, whatever went wrong gets sorted into a failure-mode taxonomy, and the whole evaluation re-runs every 30 days so the number tracks the product instead of freezing on launch day. Stripe currently sits at 58: clear API semantics and unusually machine-readable docs, undercut by a self-registration path that agents cannot get through on their own.

The interesting problem isn't running the agents. It's grading them. Every task an agent attempts produces a trace, and something has to decide three things about it: did this succeed, which failure mode was it, and how bad was it. Those are precisely Noul, Choice and Score. I have been writing that grader as an LLM judge, which is the obvious first move and also the expensive one.

The cost argument for swapping in a decision model is easy and slightly boring. Grading is the highest-volume, lowest-glamour step in the pipeline, it runs on every trace of every task on a 30-day loop, and paying frontier prices per judgment is the single clearest waste in the system.

The argument I actually care about is that I think it produces a better measurement, not just a cheaper one.

An LLM judge hands back a label. "Discoverability: poor." That label is a single point with no error bars, and it was produced by a process that will quietly give you a different answer next Tuesday. A calibrated decision model hands back a distribution: 0.42 on discoverability, with probability spread across the failure taxonomy. That extra shape is the part I'm chasing. If the mass sits cleanly on one failure mode, the surface has one clear problem. If it splits three ways, the agent got lost in three different places and the score is hiding that.

It also makes the numbers differenceable. When a re-eval moves a service from 58 to 61, I need that to be a real movement rather than judge variance. Calibrated probabilities can be compared across services and across months because they're claims about frequency. Labels can't, because they're claims about nothing in particular. And at a low enough cost per decision, I can re-grade the entire history whenever the rubric changes, which is not something I would ever justify against a frontier judge.

The limit is the same one Willison raised. A leaderboard nobody can interrogate is worthless, and "0.42" is not an explanation anyone can act on. So the split I'm testing is measurement from the decision model and narrative from the LLM: the fast model produces the scores and the distributions, the slow model writes the findings a human will read, and the two run over the same trace.

That's where the research actually sits today. It's a hypothesis I'm testing, not a result I've shipped. The open question is the one Molas raised, and it's a real risk here: agent traces look nothing like the synthetic workflow data these models were trained on, so I'm assuming calibration will not transfer and budgeting for a few hundred hand-labeled traces to re-fit it. If that works, the grader gets cheaper and sharper at the same time. If it doesn't, I've got an expensive ranking function and I go back to the judge.

How I'd actually use one

In front of the expensive model, not instead of it.

Put the decision model in front of your LLM rather than in place of it. Most traffic is boring and a 30ms typed answer handles it. The hard tail escalates, and now it escalates with a number attached instead of a vibe.

A few things I'd hold to:

• Keep each question narrow and independent, then fan them out in one call against shared state.
• Re-fit the probabilities on your own labels before you trust any threshold.
• Don't use one where you owe somebody an explanation, because you won't have one.
• Start with open weights if latency is the point. Local inference at ~33ms beats a 300ms network round trip no matter whose model is on the other end.

What I actually think

The architecture here isn't new, and one of the more grounded HN comments said so directly: it's BERT with a task head, more data, and a better training objective. The packaging is new. Enumerated outputs, a clean API, calibrated probabilities, and pricing that makes per-turn decisions free enough to stop thinking about. That combination is genuinely useful, and the ecosystem response tells you the demand was sitting there all along waiting for someone to name it.

The marketing overreached, the independent numbers already disagree with the model cards, and calibration won't survive contact with your data without a few hundred labels and an afternoon. None of that makes the category fake. It makes it a tool, with edges, which is all it needed to be.

If you're already thinking about the shape of your agent loops, this slots into the same conversation as why prose API docs break AI agents: the machines calling your software want values, not paragraphs.

If you found this useful, subscribe at quintonwall.com, and come find me on YouTube at @seeqcode where I build with this stuff hands-on.