Artificial Intelligence
What Jev Is (and Isn't): A Model for Decisions
Introduction
On September 15, 2026, TypeSafe announced Jev , the first of what they call System One models. The launch came with a very low price, a lot of speed claims, and the promise that it “can’t hallucinate”. The obvious first question is whether this is just another Large Language Model (LLM) with a smaller bill.
It isn’t, and the reason is more interesting than the price. In this article, we’ll look at what Jev actually is, what it isn’t, and why that difference matters when you decide where AI belongs in your software.
A quick note on where this comes from: Jev launched in early access. This post is based on a careful reading of TypeSafe’s announcement and documentation, and I’ll point out the places where the marketing and the docs don’t quite agree.
What Jev Is
TypeSafe’s own one-line description is the best place to start: “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.”
In practice you send Jev two things. The first is the state, the text you want it to judge, like a support ticket, an email, or a JSON record. The second is a set of questions, and each one has a type. A Choice picks one option from a list you define. A Score rates the state against levels you describe, like a rubric. A Noul gives you the probability that a statement is true. There is no free text in the response, only answers shaped like the questions you asked.
Choice and Score answers also include the probability of every option and a confidence value between 0 and 1. That confidence is calculated from how the probabilities are spread: most of the weight on one option means Jev is sure, an even split means it isn’t. TypeSafe says those probabilities are calibrated, meaning they are trained against real outcomes, so answers given with a probability of 0.8 should turn out right about 80% of the time.
There is no official Ruby SDK yet (TypeSafe ships Python and JavaScript ones), but the API is plain JSON over HTTP, so the standard library is enough. Here is an illustrative request that routes a message from a contact form, following the request format in TypeSafe’s quick start :
require "json"
require "net/http"
uri = URI("https://api.typesafe.ai/v1/systemone")
request = Net::HTTP::Post.new(uri, "Content-Type" => "application/json",
"Authorization" => "Bearer #{ENV["TYPESAFE_API_KEY"]}")
request.body = {
model: "jev-latest",
state: {message: "Our Rails 4.2 app needs to get to Rails 7. How long would that take?"},
questions: {
department: {
type: "choice",
instructions: "Which team should handle `message`?",
criteria: {
rails_upgrade: "Upgrading or maintaining a Ruby on Rails application",
ai_consulting: "Building or adopting AI features",
spam: "Unsolicited marketing or scams"
}
}
}
}.to_json
response = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(request) }
answer = JSON.parse(response.body).dig("answers", "department")
answer["choice"] # => one of "rails_upgrade", "ai_consulting", or "spam"
The response has an answers hash keyed by the names you gave your questions, so the answer to department lives under answers.department. The answer comes back in this shape:
{
"type": "choice",
"choice": "rails_upgrade",
"confidence": 0.9,
"probabilities": { "rails_upgrade": 0.93, "ai_consulting": 0.05, "spam": 0.02 }
}
The choice field holds the option Jev picked, and it is always one of the keys you sent in criteria, with probabilities giving a value for every one of them. There is no free text to dig through. Instead of asking a model to “please return JSON” and hoping it does, you get a value your code can compare and branch on right away.
What Jev Isn’t
The boundaries are where Jev gets interesting, and TypeSafe is refreshingly clear about them.
It isn’t a chat model, and it can’t power your coding agent. The docs have a page for exactly this confusion: Jev doesn’t write text, doesn’t write code, and doesn’t hold a conversation, so there is no setting that turns Claude Code or Cursor into a Jev-powered tool. It also doesn’t explain its answers. You get probabilities, never a “because”. If you need a reply drafted, a document summarized, or a reason you can show an auditor, that is still a job for an LLM or a person.
It isn’t a calculator or a calendar either. The known failure modes page for jev-1.13, the current version as of September 2026, is blunt about it: Jev doesn’t count reliably, and it reads dates as text, so asking which of two dates comes first is unreliable. The advice there is consistent and, honestly, good for any AI feature: let code do the math and the date logic, and save the model for the part that really is a judgment call.
A few more limits are worth knowing before you plan around it. Jev isn’t fine-tuned on customer data, so every account shares the same model and you steer it through how you word your questions. It reads text only, so images or audio need to become text first. It works best in English. And its context limit is smaller than the headline number suggests: a request can total 64k tokens across the state and all of its questions, but the state plus your longest single question must fit in 32k, so 32k is the budget to size your input against. Both limits are listed on the models page .
Reading “Can’t Hallucinate” Carefully
The announcement says Jev “can’t hallucinate”, and the home page goes further with “Zero Hallucinations”. There is a narrow sense in which that holds: a Choice can only return one of the options you listed, so Jev can’t make up a department you don’t have or a value outside your schema.
That is a different promise from always being right, and TypeSafe’s own docs are careful to say so. Their System One page notes that calibration “does not guarantee that an individual answer is correct”, because it is measured over many predictions. The failure modes page lists nine known weak spots, among them reading instructions too literally, getting distracted by irrelevant detail in a large state, and being steered by text written to manipulate it. That last one is prompt injection, and it matters whenever the text you are judging was written by someone you don’t know.
None of this is a scandal. Every model has failure modes, and TypeSafe deserves credit for publishing theirs. It does mean “can’t hallucinate” is best read as “can’t answer outside your options”, which is useful, but it is not the same as “can’t be wrong”. That gap is exactly what to ask a vendor about, and we wrote more on that in The Guardrail Question to Ask Any AI Vendor .
Why the Difference Matters
The most useful page in TypeSafe’s docs is the one on how to build with it . The idea is to keep the control flow in code, the way traditional software works, and call the model only where a decision needs judgment over messy text, instead of letting an LLM agent pick its own next steps. Their manifesto puts it more broadly: today’s models are already smart enough, they are just hard to build on.
In practice, you trade one broad question for several narrow ones. TypeSafe’s primitives page sets the bar for each one: “a judgment a knowledgeable person makes in a second given the right context.” Instead of asking “Is this email spam?”, you ask whether it asks for a password, whether it promises an unexpected reward, and whether the sender’s name matches their domain, then combine those answers in code.
Each of those questions is a Noul, so each answer is a single probability that the statement is true: a value near 1 is a clear yes, a value near 0 is a clear no, and a value near 0.5 means Jev can’t tell, which is the case to send to a person. When you ask a Choice instead, its confidence value plays the same role: act when it is high, ask someone to confirm when it is in the middle, and hand it to a person when it is low, with a higher bar for riskier actions.
In my experience this is the right way to put AI into software, with or without Jev. It is the same pattern Rishi described in Case for AI powered Data Pipelines : AI proposes, deterministic code validates. What Jev changes is the price. At about 100 ms and a fraction of a cent per judgment, asking ten small questions instead of one big one is cheap, and anything that needs a written reply can still go to an LLM.
The Numbers and Their Fine Print
As of September 2026, Jev costs $0.042 per million input tokens, output is free, and the docs say most queries finish in about 100 ms. The home page claims it is 193.6x faster and 444.6x cheaper than LLMs, and the announcement adds its own fine print: TypeSafe expects those figures to be “on the higher end of real world gains”, measured on workflows their own team built (they also argue the reference answers tilt the comparison against Jev). Either way, measure your own workload before building a budget on them, the same point we made in Do LLM Benchmarks Predict Good Agents? . Jev also launched in early access with rate limits that may change without notice, so a low-risk use case is the right place to start.
Conclusion
My take is that the idea is promising, with caveats. Keeping code in charge and asking a model narrow, cheap questions is a sound way to build, and confidence gives you a natural point to bring a person in. The caveats are that Jev is brand new, the headline numbers come from the vendor, and calibration describes many answers, not the one in front of you. If you try it, pin a specific model version instead of jev-latest, log the probability or confidence of every answer, and check your thresholds against real outcomes. Our posts Why do LLM Applications Need Tracing? and Traces to Insights: Evaluating LLM Apps are a good place to start.
Wondering where a decision model like Jev fits in your stack? Send us a message and let’s talk! .