What is a System One router?

An LLM router whose routing decision is made by a System One model: a model that answers fixed, typed questions in a single parallel pass with a calibrated confidence, rather than generating text. The router asks 'which of these models should answer this request' as a typed choice question and gets back an answer and a confidence in roughly a tenth of a second.

Why not just use a small LLM to route?

You can, and plenty of routers do. The cost is that a routing call becomes a generation call: you pay for autoregressive decoding, you wait for tokens, and you have to parse and validate an answer that can land outside your list of models. A typed single-pass decision removes the parsing, the retry loop and most of the latency.

Does llm11 depend on Jev?

No. The decision engine is a pluggable interface. Jev is the default backend when a TypeSafe AI key is configured, and llm11 falls back to its own heuristic backend when it is not. Every receipt names which backend made the decision, so a fallback is visible rather than silent.

Is routing latency added to every request?

Yes, and it is reported on every receipt as a separate figure alongside total latency, so you can see exactly what the decision cost you rather than taking our word for it.

A System One router decides in one pass.

Every router has to answer one question before it can do anything: which model should handle this request. What differs between routers is what answers it. A System One router hands that question to a model built for typed decisions rather than to another text generator, and that changes the arithmetic enough to make deciding per request worth doing at all.

Four ways a router can decide

What decides	On what	What it costs	Where it falls down
Hand-written heuristics	Prompt length, keywords, a regex on the task field.	Nothing, and no added latency.	It cannot tell a hard question from a long one. Every new task type is a new rule someone has to write and nobody maintains.
An embedding classifier	Nearest neighbours in embedding space against labelled traffic.	A fraction of a cent, tens of milliseconds.	It needs labelled traffic before it works at all, which is exactly what a new integration does not have.
A small LLM	A prompt asking it to name a model, parsed back out of prose or JSON.	A real generation call, typically 300ms to 1s.	It can answer with a model that is not on the list. The confidence number it gives you, if you ask for one, is not calibrated, so you cannot automate on it.
A System One model	A typed choice over the resolved pool, answered in one parallel pass.	A fraction of a cent, roughly 70ms to 500ms.	The category currently has one serious product in it, which is a genuine single-vendor risk and the reason the backend is pluggable.

llm11 runs the fourth row with the first as its fallback, which is why the receipt names the backend on every request.

Why the decision has to be nearly free

Routing only pays if the decision costs less than the difference between the models it is choosing between. Classify a support ticket on a cheap model and the whole call might cost a twentieth of a cent. Spend a third of a cent deciding and you have spent more on the decision than on the answer, and you have added a second of latency to find that out.

That is the entire case for a typed decision model here. Not that it is clever, but that it is cheap enough and fast enough to run in front of traffic where the answer itself is cheap.

What the router actually asks

The pool is resolved first, from the pack or explicit model list on the request, so the question is always a choice over models that exist and are priced right now. Jev answers it, along with the two other things the pipeline needs to know.

the shape of the triage call

{
  "state": "<the request, plus any context supplied with it>",
  "questions": [
    { "type": "choice", "options": ["<the resolved pool, cheapest first>"] },
    { "type": "choice", "options": ["low", "medium", "high"], "of": "criticality" },
    { "type": "score",  "range": [0, 1], "of": "how much checking this has earned" }
  ]
}

Jev is configured on this deployment. If it is unreachable the heuristic backend answers the same three questions and the receipt says so.

Common questions

What is a System One router?: An LLM router whose routing decision is made by a System One model: a model that answers fixed, typed questions in a single parallel pass with a calibrated confidence, rather than generating text. The router asks 'which of these models should answer this request' as a typed choice question and gets back an answer and a confidence in roughly a tenth of a second.
Why not just use a small LLM to route?: You can, and plenty of routers do. The cost is that a routing call becomes a generation call: you pay for autoregressive decoding, you wait for tokens, and you have to parse and validate an answer that can land outside your list of models. A typed single-pass decision removes the parsing, the retry loop and most of the latency.
Does llm11 depend on Jev?: No. The decision engine is a pluggable interface. Jev is the default backend when a TypeSafe AI key is configured, and llm11 falls back to its own heuristic backend when it is not. Every receipt names which backend made the decision, so a fallback is visible rather than silent.
Is routing latency added to every request?: Yes, and it is reported on every receipt as a separate figure alongside total latency, so you can see exactly what the decision cost you rather than taking our word for it.

Keep reading

What a System One model is, the model class itself, without the routing.
An LLM router with Jev, end to end, one request followed the whole way through.
Jev and TypeSafe AI, what is vendor claim and what we have measured ourselves.
System 1 thinking in AI, explained, where the “System One” name actually comes from.
What an LLM confidence score actually is, and why calibration is the property that matters.

Start free Quickstart