Your triage does not need a chat model

Count the model calls your product makes in a week and sort them by what they were for. In most products the long tail is not the impressive part — it is not the reply the customer reads or the summary of the thread. It is decisions: which queue this goes to, whether this is a refund request, how urgent it is, whether this message needs a person, whether this listing breaks a rule.

That work has three properties that make a chat model an odd choice for it: the answer belongs to a set you already know, the volume is high, and being wrong is expensive in a boring way.

What you are paying for today§

A chat model answers a classification with a sentence. So you pay for the output tokens, and then you pay again in engineering: a prompt that begs for JSON, a parser, a normaliser for "Billing." versus billing, a retry for the times it apologises instead of answering, and a "confidence" the model wrote in prose because nothing in its training tied that number to how often it is right.

Then you pay a third time, in the decisions themselves: with no honest measure of uncertainty, you either send everything to a person (and get no automation) or you automate everything (and absorb the errors).

What a System One model costs instead§

TypeSafe's Jev, the first model of this class, does not generate text. It takes a state and typed questions and returns typed answers with calibrated probabilities in a single parallel pass. The figures TypeSafe publishes are 70–500 ms end to end — 40–200× faster than frontier models on comparable tasks — at $0.042 per million input tokens, with output free.

Our own measurement, through the engine against jev-1.13.0, is about the shape of the call rather than the price: asking eight questions in one block instead of eight separate calls was 7.6× faster and used 4.9× fewer input tokens, and latency stayed flat — roughly 0.8 s whether the block had one question or forty. The state is read once, the questions are answered against it in parallel.

Put those together for a support inbox at 50,000 tickets a month, each ticket a few hundred tokens with six questions asked about it in one block, and the model line on that workload lands in single-digit dollars a month. The point is not the exact figure — your tickets are longer or shorter than my assumption — it is that the cost of the decision stops being a reason to not automate it, and the constraint moves back to where it belongs: how sure you need to be before a machine acts.

The number that unlocks the automation§

This is the real change, and it is not about price. Every answer comes with a calibrated probability and, for choices and scales, a confidence — how concentrated the distribution is:

when v.team.available and v.team.choice != nothing and confidence of v.team >= 0.9
    route(v.team.choice)
otherwise
    approve "Route to " + text(v.team.choice) + "?"

That single line is the business control you could not write before. Above the line the machine acts; below it a person sees it. You can move the threshold with data — measure what proportion of the 0.9s were right — instead of arguing about whether the model "seemed confident".

Two details we measured that protect the same line. First, a choice must pick something: a question about opening hours, offered only billing and technical, answered technical at 0.69 — straight through a 0.5 gate. Adding an explicit escape option ("none of these fits") turned that into none at 1.00 and cost nothing on the clear cases. Second, when the provider is unavailable the answer comes back with confidence 0 and no value at all, never an invented number, so an outage routes the queue to humans by itself instead of silently deciding wrong at full speed.

What stays with the chat model§

The reply the customer reads. The summary of a long thread. The explanation of why something was refused. Anything whose output is prose for a person. The two run side by side — the judge decides, the language model writes — and on the Synsema Platform they are two separate configurations, two budgets and two permissions, so a service can be allowed to classify without being allowed to generate.

Where to start§

Pick the single highest-volume decision in your product — for most teams that is inbox routing or first-line tagging. Ask it as one block with an escape option, log the answer next to what the human eventually did, and after a week compare. You will have the threshold, and the argument, in data.

The operational side — keys, budgets, the preflight, what happens during an outage — is in Putting a System One model in production. The code is in How to use Jev from Synsema, and it runs against a deterministic mock provider with no account at all.