What is Jev? TypeSafe's System One model in plain English

Jev gives up the ability to write a sentence. That is the trade, and it is deliberate. What is Jev? It is TypeSafe AI's first System One model: you send it some text plus a set of questions you defined in advance, and it sends back typed answers with probabilities attached. No prose. No JSON to pull out of a paragraph. No retry when the shape comes back wrong.

This is the plain-English version. By the end you will know what System One means, the three kinds of question Jev can answer, what you are allowed to put in, and the fairly long list of things it will not do at all. If you are already weighing it against a language model for one specific job, our earlier piece on when a decision model beats an LLM covers that comparison. This one stays on the model.

What is Jev? A model that answers, but never writes

Jev is a hosted AI model from TypeSafe AI, released on 15 September 2026 and described by the company as its flagship model and the first System One model. You call it over HTTP. One request carries two things.

• The state. The content you want judged. A support message, a resume, a log line, a record from your database. TypeSafe calls this field state.
• The questions. A map of questions you wrote, each with an ID you chose. Each question says what to judge and what the possible answers are.

The response has one answer per question, under the same IDs. That is the whole interface. The API reference lists three required fields in the request body — state, model and questions — and returns model, answers and usage.

Here is the smallest possible request, taken from TypeSafe's own reference:

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?"
    }
  }
}

And the answer:

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.95 }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

Read that response as a developer rather than as a reader. 0.95 is a number. Your code can compare it to a threshold on the next line. Nothing had to be parsed out of a sentence, and no sentence was written.

What does System One mean?

The name is borrowed. TypeSafe's docs say it comes from the idea Daniel Kahneman popularised in Thinking, Fast and Slow: System 1 thinking is fast and intuitive, System 2 is slow and deliberate. A System One model is built for the fast half.

In practice that means a rule about what to ask. TypeSafe's guidance is to ask for a judgment "a knowledgeable person makes in a second given the right context". "Does this message convey urgency?" is a fair question. "Analyse this message and determine the best course of action" is not — the docs name that one explicitly as the wrong shape, and say to break it into small questions and combine the answers in your own code.

The second half of System One is calibration. TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions, so that the probabilities it returns line up with how often it is right. The docs are careful about what that buys you: calibration is measured across groups of predictions, and does not guarantee that any individual answer is correct. That distinction matters when you write the threshold.

The three question types you can ask

Every question is one of three types. The primitives documentation lays them out like this.

Type	What it answers	Returns
Choice	Which of these options?	choice, probabilities, confidence
Score	Which level?	score, legend, probabilities, confidence
Noul	Is this true?	noul (0 to 1)

Choice picks one of your options

You supply a map of options with a short description of each. Jev returns the winning option, a probability for every option that sums to 1, and a confidence value derived from how peaked that spread is. A Choice question accepts up to 255 options, so the docs advise giving the full list of teams or categories rather than a shortlist.

Score places the state on a scale you wrote

You supply an ordered list of level descriptions — the low end first. Jev returns a position along them, which can land between two levels, plus the probability of each level and a legend mapping level numbers back to your words. The API accepts up to 10 levels.

Noul returns the probability that something is true

A Noul is a yes/no question and the answer is one number between 0 and 1. Near 1 is a strong yes, near 0 a strong no, near 0.5 means the model splits evenly. Noul is the only type with no separate confidence field, because a two-outcome distribution is already fully described by the single value.

All three can be mixed in one request. Every question sees the same state, is evaluated independently, and comes back under the ID you chose. TypeSafe says adding questions barely changes response time, which is why its docs push you to ask everything you might need in one call rather than making several.

What Jev accepts: text only, and a budget you can hit

Jev is text-only. The state documentation says the state must be a string, a JSON object, or an array of text values, and that images, audio and video are not supported. If you want a decision about a scanned invoice, you extract the text first.

The context budget has two numbers, and this is where the popular summary of Jev as "a 32K model" loses something. TypeSafe's models page gives Jev 1.13 a 64k token budget for the whole request, with a separate 32k limit for the state plus the single longest question. So the state and one long question share 32k, while all your other questions draw on the wider 64k. As of September 2026 the same page lists rate limits of 250,000 tokens per second and 1,200 requests per minute, with a warning that those limits are moving while demand settles.

One more constraint that is easy to miss: English is Jev's primary training language. Other languages, including CJK scripts, are accepted but the docs say accuracy is currently lower, and advise testing on your own content first. In the systems we build for clients across India and the UAE, that is not a footnote — it decides whether a model can sit on the hot path at all.

What Jev cannot do at all

This is the part most introductions skip, and it is the part that decides whether Jev belongs in your architecture.

• It will not write anything. No replies, no summaries, no code, and — per TypeSafe — no explanation of its own reasoning.
• It will not answer an open-ended question. If you cannot list the possible answers before you send the request, there is no question to ask. Jev's answers are constrained to the options you supplied.
• It will not reason in steps. Multi-factor judgments are meant to be split into separate questions and recombined by your code, with the weights living in your code where you can change them.
• It will not read an image. Text in, text-derived structure in, nothing else.
• It will not carry state between calls. Each request evaluates one state, and questions in the same request cannot see each other's answers. If a later judgment depends on an earlier one, that is a second request you make yourself — a constraint that will feel familiar if you have dealt with what does not carry over between agent turns.
• It will not be fine-tuned on your data. The models page states Jev is not fine-tuned or LoRA-adapted with customer data and that the same weights serve every account. You shape answers through the state and the wording of your criteria, not through custom weights.

Is Jev an LLM, and who made it?

No, not in the sense the term normally carries, though it takes natural language in the same way. TypeSafe's framing is that a System One model "understands natural-language input" but "returns typed decisions and probabilities rather than generated text". The company was founded by Diogo Almeida, who writes in the launch post that he worked at OpenAI on the methods behind ChatGPT, and that TypeSafe spent two years in stealth building a separate architecture, sampler and training method.

TypeSafe's own numbers deserve the same treatment you would give any vendor benchmark. It claims 193.6x faster and 444.6x cheaper than language models on the workflow evaluations it published, end-to-end response times of 70ms to 500ms against 3 to 329 seconds for frontier models, and that Jev "can't hallucinate" because the output schema is fixed. The company itself flags that the evals were built by its own model capabilities team and that the gains are "on the higher end of real world gains". Treat them as a hypothesis to test against your own data, which is the same advice we would give about any custom model that claims to beat an API.

The pricing is easier to check because it is published: $0.042 per million input tokens, $42 per billion, and output tokens free.

Where a model like this fits in software you already run

Look for the places where your application already calls a big model and then throws away everything except a label. Ticket routing. Spam and abuse checks. Deciding whether a document needs a human. Ranking candidates before a slower stage. Scoring another model's output, which is a job with its own well-documented biases worth correcting for. Each of those is a fixed set of answers dressed up as a text generation problem.

The honest counter-argument is that a language model already does all of this, badly but adequately, with one integration you have already built. Swapping it out buys speed and cost, and it costs you a second vendor, a second failure mode, and the work of choosing thresholds for every decision — because a probability of 0.61 is not a decision until you say what happens at 0.61. That work does not disappear. It moves into your code, where you can see it.

If your app has no such decision — if every model call ends in text a person reads — Jev has nothing to offer you, and the right answer is to stop reading here. If it has a dozen, the next thing to work out is which of them you can define precisely enough to ask. Our AI engineering team does that as a mapping exercise before anyone writes an integration, because the questions you cannot phrase are the ones that were never going to automate cleanly anyway.