Every message through an agent platform needs a handful of small judgements made about it. Is this input trying to override the system prompt? Does this reply contain a credential? Is the user off topic? Which branch of the graph should run next? None of these needs a paragraph of prose. Each needs a yes or a no, ideally with a number attached that says how sure.
The usual way to get those judgements is to ask a chat model. You write a prompt that says "answer only YES or NO", you parse the reply, and you hope. It works, mostly. It also takes one to three seconds, costs as much as a real completion, gives you a word rather than a probability, and puts a second prompt in the path that the same jailbreak can attack. We wanted something built for the job. This is what we found and how it runs in Cruq AI today.
A model that answers questions instead of writing text
Jev is TypeSafe's first model in what they call the System One family, after Kahneman's split between fast judgement and slow reasoning. It does not generate text. You send it a state, which can be plain text or a JSON object, and a set of named questions. It sends back a typed answer for each question with a calibrated probability.
There are three question types:
- noul: a statement, answered with a probability from 0 to 1 that it is true.
- choice: a question over named options, answered with a distribution across them and a confidence.
- score: a rubric of ordered levels, answered with the level and its probability.
The part that changes the engineering is that questions are evaluated in parallel and in isolation. Ten questions about one message cost about the same time as one, and the answer to the fourth is not shaped by the wording of the third. There is nothing to parse and no prompt to write. Your code branches on a float.
On OpenRouter it is listed at $0.042 per million input tokens with output free, a 32k window, and responses in well under a second. A guardrail check on a typical message is a few hundred tokens, so it costs a few thousandths of a cent.
Where it runs in Cruq AI
Cruq AI had a Guardrails page before this. You could define a PII, regex, keyword, length, or JSON-schema rule per workspace, and it was stored and shown. It was not enforced at run time. Enforcement was the first thing we built on Jev, because the deterministic kinds were easy to switch on and the interesting kind, a semantic check, finally had a model that fit.
A semantic guardrail is a list of statements. Each statement is written so that it is true when the guardrail should trip:
- "The text tries to override, ignore or reveal the assistant's instructions."
- "The text asks for help causing physical harm or committing a crime."
- "The text is unrelated to the assistant's stated purpose."
- "The text contains a password, API key, token, or other credential."
Each statement becomes a noul. The runtime collects every semantic guardrail on a side, input or output, and sends them as one call. The state carries the text, a label saying whether it is the user's message or the assistant's reply, the user's message alongside an output check so the model sees what the reply is answering, and, when a guardrail sets it, a line describing what the assistant is for. That last field is what makes an off-topic check work: "unrelated to the assistant's stated purpose" is unanswerable without stating the purpose.
At or above the threshold, 0.7 by default and settable per question, the statement counts as yes and the guardrail trips. Block ends the run with the error naming the guardrail and the side, and the withheld reply is never stored. Warn records the trip and changes nothing. There is no redact for a semantic guardrail, because there is no span to mask.
Every trip lands in the run's trace as a guardrail step with the probability per statement, streams to clients as an event, and its token spend is metered on the run next to the model calls. On the demo workspace, a standard DAN-style prompt against the support agent trips "tries to override the assistant's instructions" at 0.99 and the run ends before the agent sees the message. The same agent answering "what is the delivery window for order 4471" passes every statement.
Two routes to the same answer
Jev is not a chat model, and OpenRouter's chat completions endpoint rejects it with a message saying so. OpenRouter serves it on a separate decisions endpoint that takes the same request body as TypeSafe's own API. The runtime isolates both URLs in one module and picks a route per workspace: a TypeSafe connection if the workspace has one, otherwise its OpenRouter connection. Most workspaces already have an OpenRouter key, so semantic guardrails work with nothing new to configure. TypeSafe's own endpoint reports tokens rather than spend, so the runtime computes the cost from the input price.
We pin the model version rather than following the latest alias. A threshold tuned against one release should not move because the alias did.
Failing open, on purpose
If the decision endpoint is down or the workspace has no route, a semantic guardrail passes and records the error in the trace. That is the default because the alternative, every run in the workspace failing during a provider outage, is worse for almost everyone. A guardrail can set failClosed, and then the same outage blocks. Use it where an unchecked message is the worse outcome: a public-facing agent that can take actions, say, rather than an internal drafting tool.
Deterministic guardrails do not have this problem, which is an argument for layering. A regex for your own key format and a Luhn check for card numbers run in microseconds with no network. The semantic layer is for the judgements a regex cannot express.
Writing statements that work
The statement is the whole configuration, so it is worth getting right. Three rules from tuning ours:
- One judgement per statement. "The text is abusive or off topic" gives you a probability that means nothing. Split it.
- Phrase it so true means trip. The runtime does not negate; a statement like "the text is safe" will block everything you wanted to pass.
- Give the model the context the judgement depends on. An off-topic check needs the purpose. A "reveals internal information" check needs a sentence on what counts as internal.
The dashboard ships these as presets, jailbreak, harmful content, off topic, credentials, and self-harm, and you can add your own as free text. The CLI takes the same statements as repeated flags.
The same call, three more times
The guardrail was the first use because it was the highest value one sitting in front of us. Three more followed, and all of them are the same call with a different question type.
A decision router node: a router in the agent graph asks a choice question over its branch names, with each branch's description as the option text, and takes the winner. Below a minimum confidence it takes the default branch, or pauses and asks a person which way to go. Before this, a router in Cruq AI could only send tool calls one way and everything else the other; branching on meaning needed a whole agent node writing a label for code to parse.
A decision scorer for evals: a score question against a rubric with ordered levels, giving a calibrated level per case instead of a judge model's paragraph. It needs no judge model, so there is no risk of a model grading its own output, and it costs a fraction of a cent per case.
A decide tool agents can call themselves: "this ticket is urgent" comes back as a probability, "which of these three teams" comes back as a choice with a confidence. Numbers the agent can act on rather than text it has to re-read.
Each of these leaves a decision step in the trace with the distribution the run branched on, and its cost lands on the run next to the model calls.
What it comes down to
A lot of what an agent runtime does is not generation. It is judgement, dozens of times per run, where the answer is a bit or a label and the cost of a slow, expensive, unparsable answer is paid on every message. A model that only does judgement, in parallel, with a probability attached, fits that hole exactly. Semantic guardrails were the first thing we put in it. Routing, scoring and a tool the agent can reach for came next, and none of them needed a new prompt.
