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 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
Cruq 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.
What is next
The guardrail is the first use because it was the highest value one sitting in front of us. Three more are in progress, and all of them are the same call with a different question type.
A decision router node: a choice question over the branch names in the graph, with a minimum confidence below which the run takes a default branch or asks a person. Today routing is a chat model reading a prompt and emitting a label, which is the slow, unparsable version of the same thing.
A decision scorer for evals: a score question against a rubric, giving a calibrated level per case instead of a judge model's paragraph. Cheap enough to run on every case in every experiment.
A decide tool agents can call themselves: "is this ticket urgent", "which of these three suppliers matches the invoice", answered as numbers the agent can act on rather than text it has to re-read.
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 are next, and none of them needs a new prompt.
