Most people meet a new model by opening a chat box and typing at it. Jev punishes that reflex. It’s TypeSafe AI’s System One model, and it doesn’t produce prose at all: you hand it program state plus a set of typed questions, and it hands back decisions with probabilities attached. That role change is the entire technique. Your language model keeps writing; Jev decides what happens next, and your code decides what to do with the decision.
This guide covers the architecture around the call, not the call itself. If you need the primer first, start with what Jev is, then read TypeSafe’s own launch post for the company’s framing.
What Jev is exceptional at
Three primitives cover everything Jev does. noul returns the probability that one statement about the state is true. choice picks one option from a criteria map (up to 255 options) and returns the pick, the full probability distribution, and a confidence value. score places the state on an ordered rubric of 2 to 10 levels and returns the level, a legend, probabilities, and confidence. The background on the company and the model family lives in our piece on TypeSafe AI.
Four properties matter for architecture. Every answer arrives in a type your program already understands. Every answer carries its own uncertainty, so “not sure” becomes a branch instead of a surprise. Many questions about one state resolve in a single pass. And at $0.042 per million input tokens with output tokens uncharged, you can afford to ask on every event rather than on a sample.
Run Jev as the judge, not the writer
Four roles, cleanly separated:
- The LLM generates. Code, an email draft, a summary, a plan.
- Jev decides. It classifies the request, scores the risk, picks the route, and checks the output against criteria you wrote down in advance.
- Your code controls. Thresholds and rules decide whether to act, retry, escalate, or stop.
- A human catches the edges. Low confidence plus high stakes goes to a person.
Here’s why the split works. A language model is flexible because it can emit anything, and that same freedom is what makes it awkward to bury inside a workflow you depend on. TypeSafe’s framing is that Jev “gives up string generation” and gains a narrow contract in return: the set of possible answers is fixed before the request leaves your server, every result fits the declared shape, and uncertainty is a number you can compare against a threshold.
The cost side follows from the same trade. TypeSafe reports end-to-end response times of 70ms to 500ms, and claims figures of 193.6x faster and 444.6x cheaper on the workflows it tested. Treat those as vendor numbers, not independent benchmarks. The structural point survives either way: the expensive model only runs when something genuinely has to be written, and the repeated judgments around it run somewhere cheap.
Designing questions Jev can answer
Every request carries one shared state and a set of independent questions. Jev reads the state once and answers all of them. A support triage call looks like this:
{
"model": "jev-latest",
"state": {
"message": "I've been trying to connect Stripe for three days. I'm losing sales and I need this fixed today.",
"plan": "Pro",
"account_age_months": 14,
"recent_technical_tickets": 3
},
"questions": {
"department": {
"type": "choice",
"instruction": "Which team should own this ticket?",
"criteria": {
"billing": "Payments, charges, invoices, subscription changes",
"technical": "Bugs, broken behavior, failing integrations",
"sales": "Pricing, plans, questions asked before purchase"
}
},
"frustration": {
"type": "score",
"instruction": "How frustrated is this customer?",
"criteria": [
"Calm and matter of fact",
"Frustrated but civil",
"Extremely frustrated or threatening to leave"
]
},
"urgent": {
"type": "noul",
"instruction": "The customer needs a resolution today."
}
}
}
Three habits separate questions that work from questions that wobble.
Stop writing prompts. Personas, worked examples, and long preambles steer a text generator. Jev isn’t generating text. It needs the state, one atomic question, and an exact description of what each answer means. Descriptive criteria beat bare labels: “Payments, charges, invoices, subscription changes” routes better than the word “billing” on its own. Don’t ask it to explain itself either, because the response contains a decision, probabilities, and confidence, and nothing else.
One question, one judgment. “Is this lead valuable, urgent, and likely to buy?” is three questions wearing a trench coat. Split them and combine the results in code, where you can see the weights and change them.
Keep arithmetic out of the model. Jev judges meaning. Your program does the math, applies the discount table, and checks the contract terms. That division is what makes the whole thing auditable.
TypeSafe also ships a drop-in skill that teaches coding agents these conventions, installable in Claude Code with claude plugin marketplace add typesafe-ai/skills or elsewhere with npx skills add typesafe-ai/skills. The agent skill page has the details.
Keep the state clean
Relevant state beats maximum state. Three sections usually cover it: the object being judged, the context needed to read that object, and the facts that would change the decision if they changed. Everything else is noise you’re paying to send.
Strip duplicated log lines, history that predates the current issue, and any sentence that states the conclusion you’re hoping the model reaches. The hard ceiling is 64k tokens per request, with 32k available for the state plus the longest question, but accuracy can shift well before you hit it. When routing gets mushy, shrinking the state is usually a faster fix than rewriting criteria.
Parallel questions and confidence gates
Because Jev reads the state once, the thirteenth question costs far less than a second round trip would. Send every independent judgment that could change an action: intent, risk, urgency, sentiment, relevance, required next step. Then cut any question whose answer never changes what your code does. An unused signal is a maintenance cost with no payoff.
Match the primitive to the shape of the judgment. Gradients like severity, quality, and fit belong in score, not in a forced yes/no. A single factual statement belongs in noul. A fixed set of destinations belongs in choice.
The gate is where the architecture actually lives. A typed answer can still be a wrong answer, so confidence decides what happens next. One workable starting pattern: act automatically above 0.85, hand 0.55 to 0.85 to a stronger model or a second pass, and queue anything below 0.55 for a person. Those exact numbers are illustrative. TypeSafe’s confidence routing pattern sets a separate threshold per action based on the cost of being wrong, and its confidence page tells you to “test with your own data, and adjust as you observe results.” Once your thresholds are tuned, pin the model: jev-latest follows the newest stable release, while jev-1.13.0 freezes the behavior you measured.
Test the decision layer in Apidog
A decision layer is only worth trusting if you can prove how it behaves. That means saved requests and assertions, not a terminal history of one-off curls. Apidog gives you both, and the assertions look different from normal API tests because you’re checking numbers and enum values instead of strings.
Store the key as an environment variable. Create an environment called TypeSafe, add TYPESAFE_API_KEY as a local value so it stays on your machine, and reference it as {{TYPESAFE_API_KEY}} in a Bearer token. Our guide to environments and secret variables covers the scope rules.
Send the real call. POST https://api.typesafe.ai/v1/systemone with the state-plus-questions body above.
Assert on the decision. Add post-processor assertions like answers.department.choice equals billing, answers.urgent.noul greater than 0.9, and answers.frustration.score greater than 1.5. Now a behavior change fails a test instead of quietly misrouting tickets.
Then build the scenario that matters. Save a small set of labelled states as a test scenario: a calm question, an angry cancellation threat, and one deliberately ambiguous message that a good router should hesitate on. Assert high confidence on the first two and assert that confidence drops below your gate on the third. That single scenario turns threshold tuning into evidence instead of guesswork, and it catches the failure that’s hardest to notice by hand: someone rewords a criteria description, every response still validates, and the routing quietly shifts. Run it in CI and the rewrite fails the build.
Mock the response shape so frontend work doesn’t burn tokens. Because the answers object is declared before the request, the mock and the live response can’t drift apart. Download Apidog to set this up; the free plan covers a team of four.
Five workflows where a decision layer pays for itself
- The universal verifier. Wrap every expensive LLM call. Check the incoming prompt for injection, the selected tool for obvious mismatches, the output for missing requirements, and the final answer for claims the source material doesn’t support. Cheap checks around an expensive brain.
- The support control tower. Classify the ticket, detect urgency, frustration, refund intent, and cancellation risk in one call, then route. The win is fewer tickets in the wrong queue and fewer valuable accounts left sitting.
- Lead qualification. Score company fit, technical maturity, stated pain, buying intent, and urgency as separate signals, then combine them with weights you own and can defend in a pipeline review.
- The model router. Decide per request whether deterministic code, a small model, a frontier model, or a human should handle it. This is usually where the cost savings show up first.
- Large dataset jobs. Run the same semantic judgments across support logs, reviews, listings, transcripts, or agent traces to extract structured features and rank the records worth a human look. Analysis that only becomes practical when each decision is fast and nearly free.
FAQ
Do I still need a language model? Yes. Jev can’t write the reply, the summary, or the code. It decides which system should, and it can grade the draft afterward against explicit criteria such as policy compliance or whether the answer contains a promise you don’t make.
How is this different from JSON mode or structured outputs? Structured outputs constrain a text model’s formatting; the model is still generating tokens and can still assert something false in a valid shape. Jev returns a probability distribution over a set of answers you defined, so the uncertainty is a first-class field. Our explainer on OpenAI structured outputs covers the other side of that comparison.
How do I get access? Jev is in early access with a waitlist, so this isn’t self-serve yet. TypeSafe brings developers off the list in batches, and you sign in at console.typesafe.ai once you’re through. It’s also available through Vercel AI Gateway as typesafe-ai/jev via experimental_evaluate in AI SDK 7, which is SDK-only and not exposed on the OpenAI-compatible endpoints. Our walkthrough on getting a Jev API key has the request and SDK details.
Can I run something like this locally? Several projects reproduce parts of the idea with constrained decoding over open weights. We compared them in OpenJev and the open-source Jev alternatives, including how faithful each one is to calibrated confidence.
Where this leaves you
Jev isn’t the model that replaces your other models. It’s the layer that decides when, where, and whether they run. Build it that way: one clean state, atomic questions with explicit criteria, parallel evaluation, and a confidence gate in front of every action. Then prove the gate works with a saved scenario in Apidog before it routes a single real ticket.
