A Model Called Jev Just Launched to Do What I Had Running in April

On 15 September 2026, TypeSafe AI came out of about two years of stealth with a model called Jev and a $40 million seed round. Their founder worked on InstructGPT and ChatGPT before this. The pitch: a model that does not generate text at all.

I came to it through a writeup by Sydney Runkle on building a harness with it, which is worth reading for the integration patterns even if you take nothing else from this post.

They call it a System One model, after Kahneman's fast intuitive judgment, as opposed to the slow deliberate reasoning that the big models do. You hand it a piece of state and a typed question, and it returns a calibrated probability over a fixed set of answers. Yes or no with a number attached. Pick one of these options. Rate this on an ordered scale. Nothing to parse, and no invalid answer can come back, because the answer space is declared up front.

It is trained with a method they call reinforcement learning for calibrated decisions, which optimises specifically for the probabilities being honest: something reported at 70% confidence should be right about 70% of the time. That is a different target from the usual preference optimisation, and their argument for it is that preference training rewards sounding confident rather than being calibrated. They also evaluate every question about a state in parallel rather than one at a time.

My reaction on reading the launch was not "what a clever idea." It was "I have had that in production since April."

Most of that holds up. Some of it does not, and the part that does not is the interesting part.

What I actually built

My orchestration platform takes instructions in a chat window and turns them into work: run this pipeline, schedule that job, tell me why the overnight run failed.

The conventional way to do that is intent parsing. Keywords, regular expressions, a switch statement that grows a new branch every time a user phrases something in a way you did not anticipate. Everyone who has maintained one of those knows the failure mode. It is never wrong in an interesting way. It is wrong because somebody wrote "kick off" instead of "run," and now there is a new case in the switch, and the file is eight hundred lines long and nobody will delete any of it.

I had something most people did not have at the time: an HTTP endpoint in front of a real coding agent, which meant cost efficiency gains from a web service harness over a subscription model rather than per-token billing, so a judgment call was cheap enough to put somewhere metering would have discouraged one.

So I stopped writing the parser. The chat router asks the agent what the user meant, gets a typed answer back, and branches on it. First commit on that is 4 April 2026, and it was working before it was committed.

Same move Jev's launch describes. Stop enumerating the cases and hoping reality complies. Ask something that can read, and get back a value your code can switch on.

What I am not going to claim

I did not invent this. Getting ahead of the correction rather than waiting for it:

Using a language model as a classifier is not novel and was not novel in April. It has been ordinary practice since function calling and structured outputs shipped, and the underlying idea of training a model to emit a calibrated label over a fixed set sits in a research lineage that goes back well before any of this. Arriving somewhere on your own is not arriving first, and anyone who blurs the two in public gets corrected.

Jev is also not the same category of thing as what I built. I implemented a pattern with a general-purpose agent. They trained a model whose entire job is that pattern. That is harder, and it is not what I did, largely because they raised $40 million to do it and I had an idea and a weekend.

Two things their approach has that mine does not:

• Calibrated probabilities instead of a label. I get "deploy." They get 0.999 plus a confidence value. That matters the moment you want to route on uncertainty rather than on the answer, and it is not something I can bolt on afterwards.
• Sub-second latency. Mine lands in the low seconds on a primed session. For the job it does, behind a deterministic tier that already absorbs the easy traffic, that is fine. If I were putting a classifier in the hot path of every keystroke it would not be.

Their published multiples are self-run and not independently reproduced, so I would not repeat them as fact. The architectural point does not depend on them.

The thing mine has that theirs does not

This is the part I underrated until I tried to write the comparison down.

Jev is stateless by design. You hand it a state and some questions, it answers, it forgets. That is the correct shape for a calibrated classifier and it is why it can be fast. But it means every call starts from nothing, and the actual work still gets handed to a frontier model afterwards.

My sessions stay resident. They hold context across calls, accumulate what they have seen, compact it, and get better at this particular business over time. The classifier is not answering from a cold start against a generic prior. It is answering with months of accumulated context about these workflows, these users, and how this operator phrases things.

That buys two things a stateless classifier cannot give you:

• It gets better without retraining. Not because the weights change, but because the context it reasons over is specific and keeps growing.
• It is not restricted to the answer set. When someone asks a general question rather than issuing an instruction, the same call handles it. A classifier that can only return one of your declared options has to hand that off to something else.

Neither design dominates. Theirs is faster and calibrated. Mine is contextual and cumulative. Which one you want depends on whether your classifier's job is to be quick or to be informed, and for routing a natural language interface onto a fixed set of purpose-built workflows, informed has been worth more than quick.

What I will claim

The part I would defend has nothing to do with who was first.

Both of the integration patterns in the launch writeup lead with the model. Route every request through the classifier to pick a model. Send every tool call through the classifier to check whether it is dangerous. The classifier is the front door.

Mine has three tiers, and the classifier is the middle one. The field in my code is literally:

source: "mechanical" | "classifier" | "fallback"

Mechanical runs first. Deterministic patterns settle the unambiguous cases with no model call at all. A large share of real traffic is not ambiguous. Someone typing the exact name of a pipeline does not need a judgment call, they need a lookup.

The classifier handles the residue. Everything the deterministic tier could not settle, which is where the interesting language lives. The answer space here is small and known: the workflows are purpose-built per business, so the question is never "what could this possibly mean," it is "which of these does this map onto." That is a much easier question than it sounds, and it is why a couple of seconds is an acceptable price.

A dumb fallback sits underneath. When the classifier is unavailable or returns something unusable, the system degrades to something predictable rather than failing.

This is not about elegance. The cheapest call is the one you do not make, and the second cheapest is the one whose answer you can predict without asking. Lead with the model and you pay for judgment on inputs that needed none, plus classifier latency on requests a hash lookup would have settled.

None of that depends on which model sits in the middle. It survives Jev, and it is the piece I would keep if I swapped out everything else.

The tiering bought a second thing I did not plan for: attribution. When routing goes wrong, "the classifier decided this" and "a pattern matched this" are different bugs with different fixes. One tier gives you one undifferentiated failure and a long afternoon.

Where I would actually use it

The middle tier is the right slot. Their four question shapes map cleanly onto what I already ask: what did the user intend, what kind of failure was that, did this run satisfy what was asked for, how urgent is this.

Keep the mechanical tier in front, swap the middle, pick up confidence scores I do not currently have.

Check this before adopting, not after: a metered classifier puts per-call billing back into a system built around a subscription. Probably nothing at my volume. Probably is doing some work in that sentence.

The general version

The lesson is not that I was early. It is that a fragile parser is a design smell and the fix has been sitting there for a while. If you are maintaining a switch statement that grows a branch every time a user surprises you, that code is telling you something. It is not a parsing problem. It is a judgment problem wearing a parsing costume, and judgment is a thing you can call now.

The genuinely new thing in the Jev launch is not the idea of asking a model for a typed answer. It is that the classifier finally has purpose-built machinery behind it instead of borrowing a general-purpose model for a narrow job. That is a real contribution. It is also a different claim from inventing the pattern, and worth keeping the two separate.

What I would push back on is the integration shape. Do not put it at the front. Put a deterministic tier in front of it, a fallback behind it, and record which one answered. That was the right architecture in April and a faster classifier does not change it.