# Your triage does not need a chat model

> Routing, tagging, eligibility and moderation are the highest-volume AI work most products do, and the cheapest to get wrong. A System One model answers them with a calibrated probability — and the economics are not close.

2026-09-20 · https://synsema.com/blog/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:

```synsema
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](/blog/put-a-system-one-model-in-production). The code is in [How to use Jev from Synsema](https://synsema.org/blog/how-to-use-jev-the-judge-block), and it runs against a deterministic mock provider with no account at all.