Jev by TypeSafe: The AI Model That Writes No Text – and How It Differs from an LLM

For years, language models have been better at chat than most people – and yet hardly any process in most companies runs fully automated on AI. That observation opens TypeSafe AI’s introduction of Jev, a model that takes an unusual route: it does not write a single sentence. Jev is not a large language model (LLM) in the usual sense but a classifier with the language understanding of a frontier model.

This article explains what Jev is, why giving up text is not a shortcoming but the design idea, how the model differs from an LLM – and where the limits of the vendor’s claims lie. It is based on TypeSafe AI’s announcement post of 15 September 2026 and the public documentation. As of 21 September 2026.

What is Jev?

Jev is the first so-called System One model from TypeSafe AI. Founder Diogo Almeida says he helped build the methods at OpenAI that made language models follow instructions. TypeSafe worked in stealth for two years and opened Jev for early access on 15 September 2026.

The vendor’s short formula: a function call with frontier intelligence – unstructured state in, typed probabilistic decisions out. The name “System One” goes back to Daniel Kahneman’s Thinking, Fast and Slow: System 1 is the fast, intuitive judgment, System 2 the slow, deliberate reasoning. Reasoning models are System 2. Jev is meant to be System 1. The model is named after the economist William Stanley Jevons, whose paradox says that using a resource more efficiently does not lower demand but raises it.

A classifier, not a text generator

A call to Jev has two parts: a state – the text or JSON to be judged – and one or more questions. There are exactly three question types:

An example from the documentation: a support message arrives, and the model should decide which team is responsible and whether the matter is urgent (shortened).

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "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 is not a sentence but a structure: "choice": "technical" with the probabilities technical: 0.85, billing: 0.15, sales: 0.0, a confidence of 0.78, and for urgency "noul": 1.0.

That is exactly what a classifier is: a model that assigns an input to one of several given classes and outputs a probability distribution for it. The principle is not new; the combination is. A classic classifier – a fine-tuned BERT model, for example – is trained for fixed classes and needs labelled data. With Jev, the classes are defined in natural language at call time. According to TypeSafe the model is not fine-tuned on customer data; the same weights serve every customer, and the domain logic lives in instructions and criteria.

Why Jev generates no text

Giving up strings is not a limitation TypeSafe puts up with; it is the lever from which all other properties follow. TypeSafe puts it this way: giving up strings gives the model “superpowers”. Four consequences can be traced.

First: parallel instead of sequential output. An LLM produces token after token, each conditioned on the last. That takes time, and output is the expensive part. Jev reads the state once and answers all questions in parallel in a single pass. That is why output tokens are free with Jev; only input is billed.

Second: type safety by construction. If only values from a predefined answer space are possible, the answer cannot violate the schema. There is nothing to parse, nothing to validate, no retry loop because of broken JSON. TypeSafe states 0% type errors – not as a measurement but as a mathematical guarantee.

Third: no hallucination in the narrow sense. A model that can only choose among three options cannot invent a fourth. What it can do is choose the wrong one of the three. More on that below.

Fourth: probabilities that code can work with. From a piece of text, uncertainty can only be inferred. From a distribution it can be read – and written into an if.

Jev and LLMs compared

The table follows TypeSafe’s own comparison. The right way to read it: Jev is not a better LLM but a different tool. An LLM can also classify – Jev can do nothing else.

RLCD: trained to be honest about its own uncertainty

TypeSafe frames its method as a third path of post-training. RLHF (reinforcement learning from human feedback) turned pretrained models into chatbots by rewarding responses people prefer. RLVR (reinforcement learning with verifiable rewards) produced reasoning models that are strong at mathematics and code, but slow and expensive. RLCD – reinforcement learning for calibrated decisions – rewards something else: that the stated probability matches the actual hit rate.

Calibrated means: of all statements the model gives 80%, around 80% turn out true. TypeSafe justifies the move away from RLHF by arguing that preference optimisation can reward sycophancy and confident-sounding hallucinations. What convinces a person is not automatically reliable enough for unattended automation.

The sentence from the announcement that captures the problem best: if a model can do a task 95% of the time but does not say when it is in the other 5%, that task cannot be automated.

“Cannot hallucinate” does not mean “cannot be wrong”

This distinction deserves its own section because it gets lost quickly in coverage. Jev cannot invent a value outside the schema. But Jev can choose the wrong class, rate something one level too high, or consider a statement true that is false. The documentation says so openly: calibration is measured across groups of predictions and does not guarantee that an individual answer is correct.

The way out is confidence. TypeSafe recommends three ranges: at high confidence the system acts automatically, at medium confidence it asks for confirmation or flags the case for review, at low confidence it does not act and escalates to a person or another system. The thresholds depend on the risk – a destructive action needs a higher threshold than a read-only one. “I don’t know” thus becomes a usable signal instead of a failure case.

What the numbers say – and what they do not

TypeSafe cites impressive figures and delivers the caveats along with them. That is unusual and commendable, but it does not change the fact that these are vendor claims.

• Price: USD 0.042 per million input tokens, output tokens free (model Jev 1.13, per the documentation). TypeSafe says itself that it cannot prove the price is not subsidised.
• Speed: 70 to 500 milliseconds per call. According to TypeSafe the published measurements are run from laptops on the US West Coast, where the service is also hosted. From Europe, network latency comes on top.
• Workflow evals: the claims “193.6x faster” and “444.6x cheaper” come from the company’s own evaluation. The reference is the average of two frontier models, the workflows were built by its own team, and TypeSafe itself expects the values to be at the higher end of real-world gains.
• LLM hallucination rates: the comparison figures come from OpenRouter; TypeSafe points out a likely bias.

Independent benchmarks are not yet available a few days after launch. Anyone who wants to assess Jev should measure it on their own decisions with known ground truth.

What Jev is good for

TypeSafe speaks of “smart if-statements”: decision rules that are too fuzzy for hand-written logic and too narrow for a language model with a free hand. Four patterns emerge from the documentation.

Intent routing in front of the LLM. Incoming requests are classified first and then routed to the right handler: deterministic code, a specialist LLM, or a person. The expensive model only runs when it is needed.

Composite scoring. Instead of “rate this lead”, you ask ten narrow questions and weight the answers in code. When priorities shift, you change weights, not a prompt.

Verifying and guarding. Outputs, reasoning traces and prompts of other models can be scored, for instance for jailbreak attempts or policy violations – fast enough to run in the request path.

Map-reduce over large datasets. At this price, millions of documents can be turned into structured features on which classic models or analyses then build.

The building instructions behind it are clear: control flow stays in code, deterministic rules stay code, and the model only appears where programmable common sense is needed. TypeSafe explicitly distinguishes this from agents that choose their own next step.

Where the limits are

Jev does not replace an LLM. It does not write the reply to the customer, summarises nothing, produces no code and does not explain its decision. For anything that needs slow thinking, TypeSafe itself recommends breaking the task into small questions – or escalating to a reasoning model.

There are also tangible restrictions as of the current documentation: text input only, no images, no audio. English is the primary training language; other languages are handled, but not equally well – for German content that means: test it yourself and take confidence seriously. The context budget is 64,000 tokens per request. A Choice question holds up to 255 options. Access runs through early access with a waitlist, and according to TypeSafe rate limits are currently adjusting dynamically.

Technically important: Jev does not speak a chat completions interface but its own endpoint (POST /v1/systemone). It is therefore not a model you can put behind an existing LLM integration by swapping the model ID. The integration is a building block of its own in the workflow.

For companies in the EU, data protection comes on top. According to the vendor the service runs on the US West Coast, and the documentation does not mention an EU region. TypeSafe provides a data processing agreement that includes the EU standard contractual clauses for third-country transfers, states that it does not train on customer data, and offers zero data retention for enterprise customers. Personal data does not belong in the state before these points have been assessed.

Where it fits: fast judgment as a building block of its own

Jev is interesting less as a product than as a signal. In recent years the industry has optimised in one direction: bigger models, longer thinking, more autonomy. TypeSafe sets the counterpoint: smaller tasks, immediate answers, no autonomy. The two are not mutually exclusive.

In our article on the AI harness we described that an agent consists of more than a model: loop, tools, context, memory, permissions, verification, orchestration. System One models fit exactly those building blocks where a generative model is out of place – permissions and verification. Whether an action is risky, whether an output meets the requirements, whether a request belongs with a person: these are classification questions, and they should be answered quickly, cheaply and with honest uncertainty.

The architectural pattern behind it holds regardless of the vendor: a fast model decides and routes, a generative model drafts, a person takes over when confidence is not sufficient. Anyone automating processes today with n8n or in CompanyGPT has so far built these branches with LLM calls and structured outputs – that works, but it is slower and more expensive than necessary. Which coding agents and orchestrators exist for the generative side is shown in our overview of AI harnesses.

Conclusion

Jev is a classifier that can be addressed like a language model. It generates no text because text is the wrong output format for automation: slow to produce, laborious to check, and without a usable statement about its own certainty. What Jev delivers instead – typed values, probabilities, confidence, response times in the millisecond range – is what code needs in order to take a decision or hand it off.

Whether the vendor’s figures hold up in practice remains to be seen; the model is a few days old, it is operated in the US, and evidence for German content is missing. The idea behind it, however, holds independently of this one vendor: not every AI decision needs a model that could also write poetry.

We are watching System One models for our client projects and help break processes down so that code, fast decision models, generative models and people each do what they do best. Get in touch if you have a process that has so far failed on the reliability of AI decisions.