A model that does not write

A model that generates no text came out recently, and I think it is the most disruptive thing I have seen in months, more than the latest frontier models. It is called Jev, it was built by TypeSafe, and they present it as the first of a new class they call System One. This post is about what it is and about the first place I put it to work.

The short answer is that Jev does not chat. You give it your application’s state and a question with a typed answer, and it returns a number.

What Jev is

An ordinary language model takes text and produces text. If you want it to decide something, you ask it to write “yes” or “no”, or a JSON, and then you parse what it wrote hoping it came in the format you asked for.

Jev starts from the other end. It takes a state, which is a JSON with whatever you want (a chat, a ticket, a log line), and one or more typed questions. There are three kinds: a claim, for which it returns the probability that it is true; a choice among options you supply; and a score on a scale you define. It writes nothing. It answers with the number and stops.

That changes two things. The first is that there is no format to parse or validate: the answer is already a number. The second is that doubt has somewhere to live. A boolean cannot say “sort of”, and a 0.44 can.

And it runs on a different scale: it answers in half a second, and the output is not billed.

The first case: was anything left open?

The store’s bot has a simple remarketing step. When an agent spoke last and the customer has not written back in four hours, within the same day and during business hours, a fixed message goes out: “Hi, did you get a chance to see what I sent you earlier?”.

For a few weeks now no model writes that text. The model decides only one thing: was anything left open in that chat, or has the customer already closed it? That is about twenty decisions a day.

That decision was made by a text agent with a prompt of about 350 words. Two lists, when to send and when not to, and a closing line in capitals: WHEN IN DOUBT, DO NOT SEND. It had to answer with a JSON holding a boolean.

What I measured in production over 238 decisions, from September 8 to today:

• It was slow. Half the calls took over 2 seconds, one in ten over 8.7 seconds, and the worst one 6 minutes.
• It reasoned to emit one bit. About 1,500 input tokens and 93 output tokens on average: prose to arrive at a true or a false.
• It almost always sent. 200 times it sent, 37 it stayed quiet. With a prompt whose declared bias is not to send when in doubt, it sent 5 times out of 6. Doubt, in a boolean, has nowhere to live.
• It wrapped the JSON in a code block one time in five. It parsed anyway, but that is fragility for free.
• When it failed, it lost. When the model did not answer, the job ended without saving anything and was not rescheduled. The customer, by definition, does not write again. That chat never got a follow-up.

The same thing with Jev

With Jev the question is a claim: “the agent spoke last and the customer did not come back: something was left open”. The criteria for true and for false are the two lists from the old prompt, rewritten in the positive and enumerated, because Jev reads literally and gets lost with negations and implied conditions. The rule is one line: send if the probability is above 0.8.

What changed, measured this week:

• Half a second. Five calls in a row, between 0.50 and 0.59 seconds. Four times less at the median, seventeen times less at the 90th percentile, and no tail of minutes.
• One US cent per 700 decisions. The input is about 300 tokens of state, and the output is not billed.
• Stable. The same chat five times: 0.44, 0.43, 0.45, 0.48, 0.44. Noise of three hundredths, with no seed.
• It separates. Over 17 real production chats, the ones that should be sent scored between 0.89 and 0.96, and the ones that should stay quiet between 0.17 and 0.42. A gap of almost half a point against noise of three hundredths. The threshold is not on the edge of anything.

And it understands Rioplatense Spanish. A reconstructed example:

Agent: I’ll let you know tomorrow or the day after if the 15 in black comes in.

Customer: Sure, thanks.

Nothing is left open on the customer’s side there: the ball is in the store’s court. Jev gave 0.24. A customer who asked to be put on the waiting list, 0.17.

The “when in doubt, do not send” stopped being a sentence in a prompt and became a number. And a number moves with data: if the follow-ups that went out at 0.7 get answered as well as the ones at 0.9, it goes down; if not, it goes up.

The agent did not leave

Jev is the first of a chain of two. If it does not answer, because the service is down or the key is missing, the decision falls to the old agent. But a “no” from Jev is an answer, not a failure, and the agent does not review it. If the backup could review the primary’s “no”, we would be asking until someone said yes, exactly the opposite of the feature’s bias.

Every silence is recorded with who decided it. That is what will let me compare one judge against the other once there is data.

What I tried and dropped

Before this I tried using Jev for two of the guards I described in the previous post, with real traces.

The first was the internal-vocabulary leak: 700 replies, one cent. Jev caught more than the regex, but the extra catches were intermediate steps the pipeline never sends to the customer. The regex had a single real miss in 700. A list of forbidden words is a regex problem.

The second was stock claimed without a search: 800 turns. The regex fired five times and four were legitimate recaps of a search from a minute earlier. Jev added two real cases, roughly one a day. That did not justify the classifier or a new rule.

The lesson: Jev pays off when the rule is semantic and the output is a bit with doubt. It does not replace a lexical rule or a numeric check, which is its documented blind spot.

What I cannot say yet

Three things, so the story does not sound better than it is.

Accuracy did not improve. The agent scored 21 out of 21 on its corpus when it was merged, and Jev scores 17 out of 17 on its own. What changed is latency, cost, stability, and that doubt is measurable.

How it behaves over time remains to be seen. What is above is what I measured in the lab and over past chats. The interesting number is what happens to that 84% of “send” once doubt becomes a threshold, and then what reply rate each judge’s follow-ups get.

The 0.8 is arbitrary. I chose it high on purpose to start, and I will calibrate it against real replies.

Why I find it disruptive

Frontier models compete on writing better. Jev competes on something else: answering a small question, fast, cheap, with a number that says how much it doubts. Almost every decision a system like Chatty makes is that size: was it left open? Is this a complaint? Should a person take over? Today each of those goes through a model that writes a paragraph to say yes or no.

With Jev, for the first time a model’s judgment is a knob and not a paragraph.