The most discussed launch on Hacker News this week was not another chat model. It was a model that cannot chat at all.
TypeSafe AI, a startup founded by Diogo Almeida, who previously worked on the instruction-following research behind ChatGPT at OpenAI, released Jev on September 15, the first of what they call System One Models. The post hit 1,655 points and 456 comments within a day, which for a closed-source model from a stealth-stage startup is remarkable. Half the thread is excitement. The other half is developers doing exactly what developers should do with a claim this bold: taking it apart.
After reading the full announcement, the official documentation, and most of those 456 comments, here is what Jev actually is, which claims survive scrutiny, and when this model class matters for the software you build.
The core trade: strings for speed
Every mainstream model you know, GPT, Claude, Gemini, Llama, is autoregressive. It writes its answer one token at a time, each token conditioned on the last. That is what makes it able to produce essays, code, and refusals. It is also why a frontier model takes 3 to 329 seconds end to end, and why output tokens cost around 5x more than input tokens.
Jev gives all of that up. It generates no strings, ever. You send it a state (text or a JSON object) plus a set of pre-defined questions, and it returns a full probability distribution over the options you listed, computed in a single parallel pass. No decoder, no token stream. Per the announcement:
- Input price: $0.042 per million tokens. Existing LLMs charge $0.20 to $10 for the same input.
- Output price: free. The outputs are probabilities and confidence scores, not generated text.
- Latency: 70 to 500 milliseconds end to end, versus 3 to 329 seconds for frontier LLMs. That is a claimed 40x to 200x on System One shaped queries.
- Headline numbers: the TypeSafe homepage claims 193.6x faster and 444.6x cheaper, measured on their own workflow evals. To their credit, the blog post itself says these are on the higher end of real world gains and that the eval workflows were built by their own capabilities team, so some bias could exist.
The name is a Kahneman reference. System 1 is fast, automatic judgment. System 2 is slow, deliberate reasoning. Jev is explicitly betting on the first one. Almeida's own summary: "Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."
What you can actually ask it
The API has exactly three question primitives, and that constraint is the whole design. The following examples are from docs.typesafe.ai.
- Choice. "Which of these options?" You provide the options, it returns a choice, probabilities for each, and a confidence score. Good for routing a ticket to a department or classifying a document type.
- Score. "Which level?" You define an ordered spectrum, such as bug severity from trivial to blocker, and it returns a position along it.
- Noul. "Is this true?" A yes/no judgment returned as a probability from 0 to 1. The name is short for Bernoulli, which tells you how literally they take the statistics.
A support-triage request from their docs looks like this:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
with TypeSafeClient() as client:
response = client.system_one(
state={"ticket_message": "I was charged twice. Please fix this ASAP."},
questions={
"billing": Noul(instructions="Is this ticket about billing?"),
"tone": Choice(
instructions="What is the customer's tone?",
criteria={"calm": None, "frustrated": None, "angry": None},
),
"urgency": Score(
instructions="How urgent is this ticket?",
criteria=["can wait", "this week", "today"],
),
},
)
Every question sees the same state, is evaluated independently, in parallel, in one request. Your code then composes the answers: threshold the probabilities, branch on the choice, escalate to a human when confidence is low. The docs are refreshingly opinionated about this. Keep deterministic rules in code. Ask narrow questions, not "analyze this ticket." Treat the model as a fuzzy if-statement, not an agent.
That last part is the real architectural statement. TypeSafe is not selling agents. Their docs describe the target as AI-powered software: code owns the control flow, the model handles common-sense judgment over unstructured data, and it appears only where you need it. One CEO reply in the HN thread confirmed the philosophy: constrained decoding, the JSON-mode feature every LLM provider ships, "make models dumber unfortunately," because masking logits on a model that wanted to emit something else means the model was already confused.
Why the "can't hallucinate" claim split the thread
The boldest line in the announcement is that Jev "can't hallucinate." The comment section did not let that slide, and the truth is more interesting than the marketing.
The narrow claim is true by construction. Hallucination in the LLM sense means generating fluent, confident text that is wrong. Jev produces no text. It can only return a valid value from the schema you defined, so it can never invent a field, a URL, a citation, or an API call that does not exist. As one commenter put it, "It just can't make up data." Type safety is guaranteed mathematically, and the company points out that a single counterexample would falsify it.
The broad claim is false, and to their credit the CEO said so in the thread himself. When a commenter noted that a model "can still emit a completely wrong valid value," Almeida agreed: "that is likely true of all ML! perhaps we could debate semantics, but I don't think it's fair to say a random forest 'hallucinates' in the way LLMs do." Another commenter gave the concrete failure: ask whether the user wants a human support agent, get "yes," when the real answer is "yes, but not right now." A human would attach that caveat. A constrained classifier cannot. A Jev-style model can route a billing query to the wrong department with perfect type safety and total confidence.
The honest translation is this: Jev cannot produce malformed output, and it attaches calibrated confidence to every answer so your code can decide when to act and when to escalate. It can absolutely be wrong. "Cannot hallucinate" and "cannot be wrong" are different claims, and only the first one holds.
The zero-shot classifier framing
The single most useful comment in the thread came from a developer who cut through all the branding: this is "basically a zero-shot classifier that can accept raw text (or structured text) as an input, and is able to classify that text as accurately (they claim) as a frontier-level LLM." The CEO's reply: "exactly right!"
That framing explains both the hype and the skepticism in one move.
- Why it is exciting: zero-shot means no training data, no fine-tuning, no per-task model. A fraud analyst, a support lead, and a game QA engineer all want the same primitive: frontier-quality judgment about text, at classifier latency and price. One commenter estimated it could replace 40 to 70 percent of LLM calls in a typical pipeline, which is where an order of magnitude of cost lives.
- Why it is familiar: other commenters immediately pointed at existing zero-shot classifiers like DeBERTa and GLiNER and asked what is fundamentally new. One claimed to have built something similar in two hours with open-weight models. The counterargument from the faster-is-better camp: Jev wins the benchmarks against LLMs on hops and cost in their published demos, and the calibrated confidence is the part a raw logits peek does not give you. The architecture stays "close to the chest," with a paper possibly coming.
The most concrete evidence is a Doom demo, of all things. Jev played the game at around 10 decisions per second off structured game state, at roughly $7 per hour of play. One commentator's skeptical note is worth keeping in mind: the model sees structured state as text, which is not how a human experiences the game, and a non-AI bot could play better. What the demo actually proves is narrower and more important: judgment at game speed, in a real-time loop, for pennies. That is the product.
Should you care? A decision checklist
Jev is in early access, closed source, with a 32k context window and no public benchmark scores. I have not used it, and neither has almost anyone outside the waitlist. So here is the checklist I would use, based on what the company itself documents:
- You route, classify, score, or filter text in production. Ticket triage, content moderation, lead scoring, document tagging. This is the bullseye. A 100x cost drop on that step changes what you can afford to build.
- You need decisions in a real-time loop. Under 500 milliseconds is the headline. If your feature currently waits seconds for an LLM, this model class is aimed directly at your bottleneck.
- Your pipeline is mostly chain-of-thought reasoning, coding, or writing. Jev cannot help. It generates nothing. Their own CEO said coding is untried because "state engineering" is the hard part.
- You need long context. 32k tokens is small. Several early users said code review ideas did not fit.
- You need on-prem or open weights. Not available, and commenters flagged it repeatedly. If your data cannot leave your VPC, wait.
The pragmatic play for most teams is not replacement. It is audit: find the LLM calls in your stack where you throw away 90 percent of the generated text and keep a yes/no or a category. That is the surface this model class attacks first, and per the buzz in the thread, someone will ship an open-weight version of the idea soon. The bet that cheaper judgment creates its own demand is the most interesting part of the whole launch, and it does not require Jev specifically to win for it to matter.
I write about AI engineering and backend development every week. Subscribe, it is free.
Have a workflow in your stack that this checklist flags? I am curious whether the classification-shaped share of your LLM bill is as big as the thread suggests. Tell me what your split looks like in the comments.
Top comments (0)