Jev and the System One Model: A Model That Can Only Answer Typed Questions

Anyone who has wired a language model into a pipeline knows the shape of the tax. You ask for JSON, you get JSON most of the time, and the rest of your week goes into schema validation, retry loops, a parser that strips code fences, and a fallback path for the day the model decides to apologize instead of answering. Structured output modes made this better. They did not make it go away, because the model is still generating a string and you are still hoping the string is what you asked for.

TypeSafe AI’s announcement on September 15 takes a different swing at that problem. Their first model, Jev, does not generate text at all. You send it state and a set of typed questions, and it returns typed values with probabilities attached. The company calls this class a System One model, after Kahneman’s fast, intuitive System 1, and the model is named for William Stanley Jevons, whose paradox says that making a resource cheaper tends to increase total consumption rather than reduce it. Founder Diogo Almeida, who worked on the instruction-following research behind ChatGPT at OpenAI, frames the whole thing around a question worth sitting with: models have been superhuman at chat for years, so where is all the automation?

What the API actually looks like

The request is state plus questions, and there are only three question types. A Choice picks one option from a set you define. A Score rates against ordered levels you describe. A Noul evaluates a statement and returns the probability that it is true. Every question is evaluated against the state in parallel and in isolation, which is why the docs say adding questions barely moves the response time.

{
  "state": "I've been trying to connect my Stripe account for 3 days and the integration keeps failing.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

What comes back for the Choice is the selected option, a probability for every option, and a separate confidence number. That last distinction is the part I find most interesting. Probability is how the model spread its belief across your options. Confidence is how peaked that distribution is, so a three-way near-tie reports low confidence even though one option technically won. Your code gets both, and the obvious pattern falls out of it: act automatically above a threshold, send everything below it to a human or to a slower model.

That is a real change in how you write the surrounding code. The usual complaint about putting a language model inside a workflow is not that it is wrong sometimes, it is that it is wrong silently. A model that can do a task 95 percent of the time but cannot tell you when it is in the other 5 percent has not automated anything, it has just moved the review work somewhere less visible. Asking an LLM to self-report confidence in its own output produces a number that sounds like a probability and behaves like a vibe.

The no-hallucination claim needs unpacking

TypeSafe says Jev cannot hallucinate and reports a 0 percent hallucination rate. To their credit, they say plainly in the same post that this number is not empirical: schema matching is guaranteed by construction, so they add the zero to the chart by definition. Type safety is not accuracy.

Worth being precise about what you get. The model cannot return an option you did not define, cannot invent a field, and cannot return a malformed value, so your code path after the call is deterministic and every branch is reachable by construction. What it can do is pick the wrong option from your list. It just does so in a way that your type system already covers, which means the failure shows up as a bad routing decision you can measure rather than an exception at three in the morning. For a system buried several layers down a dependency chain, that difference is worth a lot. It is not the same as being right.

The speed and price claims are more checkable. Jev 1.13 is priced at $0.042 per million input tokens with output tokens free, the response time is quoted at 70 to 500 milliseconds, and the headline comparison of 193.6 times faster and 444.6 times cheaper comes from their own workflow evaluations. Read the methodology on that one before you quote it. The reference answer is the average of GPT-6 Astra and Fable 5.1 rather than ground truth, so the eval measures agreement with two frontier models, and the workflows were written by TypeSafe’s own model capabilities team. They disclose both of these, which is more than most launch posts manage, and it still means the number is a comparison against other models’ opinions rather than against reality.

The limits are documented, which is the good news

The model page is specific in a way that makes capacity planning possible. Text only, no images or audio, so anything else has to be turned into text or structured fields first. A 64k token budget covers the state plus all questions combined, with 32k for the state plus the single longest question. Rate limits currently sit at 250,000 tokens per second and 1,200 requests per minute, with an explicit warning that these move without notice while the company is scaling.

Better still, there is a page cataloguing the model’s jagged edges, last reviewed six days before I write this. It says Jev reads instructions literally, answering the question you wrote rather than the one you meant. It says the model does not count reliably, should not be trusted with arithmetic or date comparison, and degrades when the state is large and mostly irrelevant to the question. The advice throughout is to keep the math in code, filter the state before sending it, and split ambiguous questions into two literal ones you combine yourself.

I would rather have that page than another benchmark chart. It also tells you exactly where the boundary sits: this is a model for semantic judgment, not computation. Ask it whether a message sounds urgent, not how many days have passed since the invoice date.

Where I would actually reach for it

The honest use case is the layer of decisions currently written as brittle if-statements or as an expensive model call doing a job far below its weight. Routing a ticket to a queue. Scoring retrieved passages before they reach the answering model. Deciding whether a piece of user content needs review. Checking whether a quoted citation is supported by the source document. Screening every message into and out of an LLM app, which at these prices you can afford to do on every request rather than sampling.

The pattern that makes those worth the integration is fanning out. Because questions are evaluated in parallel against one state, asking twelve questions costs roughly what asking one costs in latency, so you can ask speculative questions you might not need and let your code decide afterwards what was relevant. That inverts the usual instinct to minimize calls, and it is the sort of thing that only becomes reasonable when output tokens are free.

What I would not do yet is make it load-bearing in a system with no fallback. It is early access, the rate limits are explicitly unstable, and the whole value proposition rests on calibration holding up on data that is not theirs. That is a measurement you can run yourself, and it is the one I would run first: take a few thousand decisions you already have labels for, ask Jev the same questions, and check whether the confidence numbers mean what they say. If the 0.9-confidence bucket is right 90 percent of the time on your data, the rest of the architecture follows. If it is not, none of the speed matters.

The framing that will stick with me regardless of how this particular company does is the inversion at the center of it. Every structured output approach I have used works by generating text and then constraining or validating it afterwards. Deciding the shape of the answer before the model runs, and getting a probability distribution over your own enum rather than a sentence you have to parse, is a genuinely different contract between software and a model. That idea seems likely to outlast whichever vendor gets there first.