Diogo Almeida, who worked on the methods behind ChatGPT at OpenAI, spent two years in stealth on a question he says the field skipped: models have been superhuman at chat for years, so where is all the automation?

His answer is an interface problem. Chat models emit strings, and strings are maximally flexible — chat replies, code, refusals, or hallucinated nonsense. Software needs typed values, so every call sits behind a parser, a validator, and usually a human. TypeSafe’s first “System One Model,” Jev, gives up string generation entirely: unstructured state in (text or JSON), typed probabilistic decisions out — choices, scores, and yes/no answers, each with a calibrated confidence.

The claims from the launch:

  • A new training method, Reinforcement Learning for Calibrated Decisions (RLCD), plus a new architecture and a “parallel sampler” that produces all outputs in one pass instead of one token at a time.
  • End-to-end latency of 70–500ms, against 3–329 seconds for frontier models (benchmark figures from llm-benchmarks). Input tokens at $0.042 per million; output tokens free. The homepage headline is 193.6x faster and 444.6x cheaper on the workflows they published.
  • No type errors, which the post describes as mathematically impossible rather than merely unlikely — the possible outputs are fixed in advance and the model never returns something off-schema.
  • Named use cases: “smart if-statements” (classify, route, score, extract), map-reducing over large datasets, real-time features, and using a fast judge to verify or guardrail other models’ prompts, reasoning traces and outputs.
  • The name is deliberate. Jevons, after the coal-efficiency paradox: every order-of-magnitude drop in the cost of intelligence should unlock more uses for it.

What stands out is how much of the post is spent arguing against itself. The evals run from laptops on the West Coast, where the service currently lives. Pricing may be subsidized and the author says he can’t prove it isn’t. The workflows weren’t chosen to flatter the model, but they were built by TypeSafe’s own capabilities team, so “some bias could exist.” The reference answers in the evals are an average of two frontier models, which he says likely understates Jev. And the headline demo used a deliberately short input that “paints our model in an advantageous light.”

The 459-comment thread on Hacker News is where the useful version of the skepticism lives — including several commenters asking what genuinely separates this from techniques that already existed.

What the thread adds

  • jacobgold — the sharpest correction. A more accurate title would be “Jev: Trading general purpose generation for fast typed inference,” and “can’t hallucinate” is the wrong claim: the model can’t emit an invalid type, but it can emit “a completely wrong valid value.” Structured output from an ordinary LLM with “an appropriate harness” already gets you much of this.
  • ramon156 — the comparisons are apples-to-oranges unless the LLM baseline is doing comparable work: “If Jev is skipping generation entirely for a narrow structured task, of course it’s faster.” They also note RLCD and parallel sampling have, so far, only marketing terms behind them. why_only_15 answers with the wikiracing evals — comparable hops at roughly a tenth of the time and cost — which they call a reasonable comparison once you accept chain-of-thought as the baseline.
  • bregmandiv — the recurring skeptical frame: encoder models already gave you “unstructured state in, probabilistic decisions out” with fast inference and no hallucinations for free. What looks new here may be specifying the output shape without fine-tuning. brainless lands in the same place (“this looks a lot like GLiNER with a fitting harness”) and techn00 asks how it differs from a fine-tuned encoder.
  • brooksy — a more careful version of the hallucination point. A model that doesn’t produce text “does not hallucinate statements” is “kind of trivially satisfied and they make this sound more extraordinary than it is.” Their caveat: on out-of-distribution input it can still return miscalibrated probabilities.
  • lubujackson — corroboration from production rather than theory: “After much fumbling around with prompts and evals, this is exactly how I am using LLMs in production, to narrowly make choices and return structured data.” Their bet is that structured I/O plus confidence scores becomes the standard shape for agentic systems.
  • vintermann — a concrete case where a fast scorer is the whole problem: matching people across genealogy trees, where an LLM per pair would be better than human judgment but impossible across 100,000-squared pairs. The replies supply the practitioner detail — camdenclark argues you need blocking first, since this is entity resolution and the search space is what kills you, and RobinL points out a pairwise judge also can’t see how unusual a name is in the context of the whole dataset.
  • maltalex, with big_toast and 18al — the launch post is the weakest link in its own story. “None of this is explained in the announcement, but the documentation is pretty good”: state in, then a Choice, a Score or a Noul (short for Bernoulli) out, with probabilities attached. 18al pastes the SDK example, which does more than the blog’s comparison table to show the shape of the thing.

The question the thread kept asking

Across 459 comments, the same question arrives from four directions: what is new here beyond constrained decoding plus an encoder model? jacobgold gets to it through harnesses, bregmandiv through existing encoders, brainless through GLiNER, techn00 through fine-tuned encoders. The thread’s own best answer is that the difference may be a matter of degree rather than kind — a model trained for calibration instead of preference, fast enough and cheap enough to sit inside a control flow rather than next to a human — which is exactly what the author’s own “smart if-statements” framing claims. Nobody in the thread demonstrated otherwise; nobody demonstrated the author right either, since early access means almost no one could test the model.

Two smaller threads worth noting: cfowles says the value only clicked after seeing a home automation demo, which draws VladVladikoff’s objection that they don’t want their home automation commands going to the cloud — a case for open weights, and nullbio expects a small open-weight model (Qwen or similar) to fit this task well. And mushufasa wants this on OpenRouter or Bedrock so it can be adopted without a vendor review; varenc explains why that’s awkward — a structured-decision API doesn’t fit the OpenAI-style request/response format every hub is built around.

A note on reading comments as evidence: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering here is HN’s own ranking, not a vote. This is a slice of a very large thread, and the skeptical readings are quoted as arguments, not as findings.