Product
Jev on Vatan: a typed answer, not a paragraph
Your router should not have to read prose.
By Ehsan Gazar, 19 September 2026
A support ticket arrives and your code has to decide where it goes. So you ask a chat model, and it answers in a sentence. Now you are maintaining a parser for that sentence.
The parser is the weak point, not the model.
The paragraph you throw away
You asked for one word and got "This looks like a billing issue." Next week the same model adds a preamble, or hedges between two teams. Your string match fails quietly and the ticket lands in the wrong queue.
You also paid for every word of that answer and kept one. And a sentence carries no confidence you can act on, so there is nothing to set a threshold against.
A decision should come back as a value, not as prose about a value.
A model that only answers questions
Jev is a decisions model from TypeSafe, served by the Vatan gateway at POST /v1/decisions. It does not chat. You send the thing being judged as state, plus named questions, each of one of three types.
noul is a yes or no, answered as the probability that the answer is yes.choice picks one of the options you name, with a probability for each.score places the input on an ordered scale you define, with a probability for every rung.
The answers come back under the names you gave the questions. Your code reads answers.team.choice and branches. There is nothing to parse, because there is no text.
It sits behind the same key as every other model on Vatan. Its budget, rate limit and allowlist apply before the model is called. Every call writes a usage row, a refused one included, so a broken integration shows up as failures rather than silence. Output tokens are free on Jev, and input is billed like any other model on your key.
When to reach for it
Use it where your code needs a value to branch on, and a probability you can threshold.
- Routing a request to the right model or the right team.
- Classifying tickets or messages into a fixed set.
- Yes or no gates: is this spam, does this need a human.
- Scoring urgency or quality on a scale you define.
Leave it out of anything whose output is text: a reply, a summary, written-out reasoning. It also reads at most 32,000 tokens, and it never streams.
Calling it
One ticket, two questions: which team, and is it urgent.
curl https://gateway.vatan.one/v1/decisions \
-H "authorization: Bearer $VATAN_API_KEY" \
-H "content-type: application/json" \
-d '{
"model": "typesafe/jev-1.13",
"state": "I was charged twice for my March invoice and I need the second payment refunded today.",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this ticket?",
"criteria": {
"billing": "Payments, invoices, refunds",
"technical": "Bugs, errors, outages",
"account": "Sign-in, access, settings"
}
},
"urgent": {
"type": "noul",
"instructions": "Does this need a reply today?"
}
}
}'
The gateway's reply to that exact request, on 18 September 2026:
{
"id": "req_mu7kkqvsh8vrgipgbd",
"object": "decision",
"model": "openrouter/typesafe/jev-1.13",
"answers": {
"team": {
"type": "choice",
"choice": "billing",
"probabilities": { "technical": 0, "billing": 1, "account": 0 },
"confidence": 1
},
"urgent": { "type": "noul", "noul": 0.89 }
},
"usage": { "input_tokens": 365, "output_tokens": 55 }
}
It read 365 input tokens and spent 535 milliseconds inside the gateway. A score question answers in the same shape, with the chosen rung, a legend and a probability for each rung.
If your code is going to branch on an answer, the answer should not arrive as a sentence.