How to Use Jev in 2026

Most agent loops spend tokens explaining themselves before they do anything. The model reads a ticket, writes three paragraphs justifying a decision, emits it as JSON, and then a parser tries to recover the one value the application actually needed. Jev, the decision model from TypeSafe AI, is built around removing that round trip. You hand it state plus a bounded question, it hands back typed probabilities, and your code does the acting.

That is the whole idea, and the rest of this post is how to actually get TypeSafe’s Jev working in your code without wasting a month discovering the failure modes the hard way.

What Jev actually is in 2026

TypeSafe ships one live model today: jev-1.13.0, reachable through the alias jev-latest. Everything goes to a single endpoint, POST https://api.typesafe.ai/v1/systemone, and the request’s model field picks the engine. Send jev-preview and you get the newest release whether or not it is an official one. Right now both aliases resolve to the same build.

The current numbers, from the models page:

Property	Value
Price	0.042 USD per million input tokens (42 USD per billion)
Output tokens	Free
Rate limits	100K tokens/sec, 80 requests/sec
Context	64k tokens per request
State budget	32k for state plus the longest single question
Input	Text only, no image, audio, or video

Two of those lines deserve more attention than they get. Output tokens are free, so you are billed purely for what you read, not what the model emits. And the context split is unusual: state plus all questions must fit in 64k, but state plus any one question must fit in 32k. If you pack a hundred speculative questions into one call, each one still gets evaluated against a budget that only counts the largest of them. That is what makes the fan-out pattern below work.

TypeSafe also says the rate limits can change without notice while upcoming GPU deals land, so pin jev-1.13.0 if you have tuned thresholds against a specific version and log the model field the response returns. Aliases move under you.

The thing to get right first: it is not a chat model

TypeSafe dedicates a docs page to this, and the reason is that a lot of people arrive looking for a coding-agent backend and leave disappointed. Jev does not generate text, does not write code, does not hold a conversation, and there is no model: "jev-latest" setting anywhere in Claude Code, Cursor, or opencode that swaps the LLM underneath.

What it does return, per question:

• choice plus a probabilities array across every option, and a confidence figure
• score with a legend mapping level numbers back to your labels, probabilities, and confidence
• noul, a single float where 0.5 means genuinely undecided

The schema mismatch rate is zero by construction, which is a real engineering win. Your parser stops being a source of outages. But a well-formed answer can still be the wrong answer, and that is the failure mode worth spending your energy on.

The three primitives

Noul is a yes/no question where the probability itself is the signal. Useless for measuring a spectrum, and this trips people up: asking “is this candidate strong in Python?” and getting 0.62 does not mean moderately strong. It means the model is 62% sure the answer is yes, and the real problem is that you never defined strong.

Score is for when you can name the points on the scale. Bug severity, customer frustration, skill level. The model returns a position along your levels plus the distribution across them, and the score can land between two named levels, which is often where the useful signal is.

Choice picks one option from a set you enumerated, with a probability per option. This is the workhorse for routing.

Pick based on what your code does with the answer. A Choice of refund | rebook | information maps to three code paths. A Score maps to a threshold. A Noul maps to an if. When two types both seem plausible, take the one your code can act on directly.

Sending many questions at once

The single biggest cost lever is that Jev ingests state once and evaluates every question against it in parallel. Three questions about one ticket cost roughly one ticket’s worth of tokens, not three.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # reads TYPESAFE_API_KEY, calls jev-latest

result = client.system_one(
    {"ticket": {"text": body, "plan": plan, "tenure_months": tenure}},
    {
        "refund_requested": Noul(
            instructions="Does the customer explicitly ask for their money back?"
        ),
        "route": Choice(
            instructions="Which queue should own this ticket?",
            criteria={
                "billing": "Payment, charges, invoices, failed payouts.",
                "technical": "Errors, outages, and broken behavior.",
                "account": "Access, login, permissions, and plan changes.",
            },
        ),
        "frustration": Score(
            instructions="How frustrated is the customer right now?",
            criteria=[
                "content",
                "mildly annoyed",
                "frustrated",
                "angry",
                "threatening to leave or escalate",
            ],
        ),
    },
)

client.system_one takes the state and a dict of questions you name. Answers come back under the same keys, so the key is your code’s handle and nothing else. TypeSafe is explicit that question IDs are never sent to the model, which means the meaning has to live in instructions. If you rely on a key name to carry meaning, you have built a bug.

This is also the mechanism behind speculative fan-out. Send every question your code might need, including ones you cannot yet say you will use, and let code discard the ones that do not apply. TypeSafe’s own example batches 13 questions into one call and reports that as 11.5x cheaper and 9.6x faster than making them separately. A second request is the exception, not the rule. If the question could have been asked against the original state, it should have been in the first call.

Confidence is the second axis

Every Choice and Score answer carries a confidence figure that is derived from its own probability distribution, not a separate confidence model. For a three-option Choice the formula is (3 × largest_probability − 1) / 2. All the probability on one option gives 1.0. An even spread gives 0.0. You can compute it yourself, which means you can debug any confidence value by hand.

Because it is derived from spread rather than from the underlying task, a low confidence is ambiguous by design. It might mean no option is clearly winning, or that your levels are overlapping, or that the state did not contain what the question needed. Those need different fixes.

TypeSafe’s suggested shape is three bands, and the part people skip is that the bands are per-action, not global:

action = route.choice
if route.confidence < 0.6:
    queue_for_human()                  # genuinely unsure, do not guess
elif action == "check_balance":
    execute(action)                    # low stakes, 0.6 is enough
elif action == "approve_transfer" and route.confidence > 0.85:
    execute(action)                    # high stakes but clear, act
else:
    confirm_with_user(action)          # everything else

Checking a balance at 0.6 confidence is fine. The worst outcome is the user hears the balance read out again. Approving a transfer at 0.6 is a different problem entirely. Your code encodes that risk tolerance, which is the whole point: the threshold is a product decision, not a model parameter.

For Noul there is no confidence field. If you want a comparable number, use abs(p − 0.5) × 2, which lands at 0 when p is 0.5 and 1 at either extreme.

Where it breaks

TypeSafe documents its own known failure modes, which is worth reading in full. The ones that will actually cost you an afternoon:

It is literal. Scoping words and negations are read at face value. It answers the question you wrote. When you find yourself explaining what you actually meant after a wrong answer, that explanation belongs in the instructions. TypeSafe’s fix is to split it into two literal questions and combine them in code.

It does not count. Characters in a word, occurrences of a term, items in a long list. It recognizes the shape of an answer instead of tallying, and the error grows with the size of the thing counted. So do not count. Iterate in code and ask one question per item, then sum the answers yourself.

No arithmetic. Keep every calculation in code. It is a semantic model, and it does better on meaning than on numbers.

No date comparison. Extract the components and compare in code.

Large state hurts. Accuracy shifts as state grows. Filter before you send. Sending everything because everything is potentially relevant is how you get a worse answer for a bigger bill.

Option order matters. Reorder your Choice options and check whether the answer is stable. If it flips, your criteria are overlapping rather than mutually exclusive, which is your bug to fix.

Adversarial content gets through. Write tight prompts and test your edge cases before deploying anything that reads untrusted input.

Where it fits

The pattern is not “replace the LLM.” It is “keep the LLM for the open-ended part and use Jev where you already knew the answer’s shape.”

That works out to: intent and domain routing, escalating a request to a heavier model when the cheap one is unsure, scoring candidate answers for reranking in a RAG pipeline, putting a cheap semantic guard in front of every LLM call, detecting prompt injection, and the boring one that pays off constantly, which is judging whether a long transcript of agent traces went off the rails.

TypeSafe’s own use-case map adds: screening papers against inclusion criteria for a systematic review, labeling interview transcripts against a codebook, checking that cited passages actually support claims, and routing job applications against explicit role criteria.

What it does not fit is anything open-ended. Writing, explaining, planning an unfamiliar sequence, or researching an unknown answer. If the candidate set is not bounded, there is nothing to score.

My read

The pricing is not the interesting part, even against frontier models that TypeSafe prices from 0.20 to 10 USD per million input tokens. The interesting part is that the failure mode moved from your parser broke to your question was vague.

Those are very different debugging sessions. The first one is infrastructure. The second one is thinking about what you actually want, which is work you were going to have to do anyway once the JSON parsed.

The confidence field is the part I would build around. Having a model hand back a calibrated second axis alongside its answer means escalation paths can be expressed in code instead of in prompt instructions. That is a design constraint you cannot retrofit onto a chat model, and it is the reason this class of model is worth the integration effort even before you account for latency.

Start with one Choice in your hottest routing path, log the distribution and confidence on every call for a week, then decide whether the threshold is worth having. That experiment will tell you more in an afternoon than any amount of reading.

FAQ

How do I use Jev in my codebase?

Call POST https://api.typesafe.ai/v1/systemone with your API key, a state field holding the content to evaluate, and a questions map of typed questions. Pick the type by what your code does next: Choice for branching onto named options, Score for a threshold, Noul for an if. Start with a single routing decision in a hot path, log the probability distribution and confidence on every call, and only then tune thresholds. The TypeSafe agent skill exists so a coding agent can write the integration for you.

Is Jev a replacement for the LLM in Claude Code or Cursor?

No. Jev does not generate text, write code, or stream tokens, so it cannot power a chat or code-completion interface. It sits inside software you build with a coding agent, replacing the prompt-and-parse steps where you already know the answer’s shape. Use the LLM for open-ended work and Jev for routing, classification, scoring, and verification.

How much does Jev cost?

0.042 USD per million input tokens (42 USD per billion), with output tokens free. You are billed only for the state and questions you send, which is why sending several questions in one call is dramatically cheaper than one call per question. Since state is the expensive part, filter it before sending rather than shipping everything that might be relevant.

How many questions can I send in one request?

As many as fit the context budget. All questions plus state together must fit 64k tokens, and state plus the single longest question must fit 32k. Because state is ingested once and every question is evaluated against it in parallel, extra speculative questions are nearly free. TypeSafe’s rule of thumb: a second request is the exception, and only when the second request’s questions could not have been asked against the original state.

What is the difference between probability and confidence?

Probability is the answer’s substance: for a Choice, the share on each option, and for a Noul, the chance the answer is yes. Confidence is derived from how peaked that distribution is, using a formula you can compute yourself. A Noul of 0.62 with a wide distribution is different from a sharply peaked one, which is exactly the case where you want a human rather than an automatic action.

Where do I start with TypeSafe AI?

One Choice in your hottest routing path, with the confidence and probability distribution logged on every call for a week. If the distribution is sharp enough to set a threshold, you have your integration. If it is not, no amount of prompt tuning will fix it, and you have learned that faster than by reading another guide.

When should I not use Jev?

When the answer set is not bounded. If the task is writing, explaining, researching something unknown, or planning a sequence of unfamiliar actions, use a generative model. Also keep arithmetic, counting, and date comparison in code: Jev is a semantic judgment model and is explicitly unreliable at all three.

References

• TypeSafe Models — current model, pricing, limits, aliases
• Primitives — Choice, Score, Noul, and asking several at once
• Confidence — derivation, formulas, three-band pattern
• Confidence-gated routing — worked banking example
• Speculative fan-out — packing many questions into one call
• Jev 1.13 jaggedness — the documented failure modes
• Jev with coding agents — what it is not
• Introducing System One Models & Jev — launch post