Product Insights #2: Jev and the Case for Decision Models

Which team should handle this ticket? Which tool should an agent run next? Is there enough information to proceed?

A lot of AI application work comes down to small decisions like these. What caught my attention about Jev from TypeSafe AI is that it makes those decisions the product: give it context and defined questions, and get structured answers that code can act on.

After Hebbia, I wanted to look at another company changing how software uses AI. This time, the interesting interface is an API.

The idea: A decision engine inside your application

TypeSafe cofounder Diogo Almeida contributed to InstructGPT and RLHF, part of the research behind ChatGPT. The company calls Jev a System One model, borrowing from the distinction between fast judgments and slower, deliberate reasoning. Jev handles focused decisions; a larger model or a person can handle deeper investigation. TypeSafe’s overview explains the framing.

Think about support triage. Before drafting a response, software must identify the issue, check urgency, and route the ticket. Those steps happen on every request. Their latency and mistakes add up.

Jev separates interpreting language from generating text. The mental model I like is a semantic switch: an ordinary switch branches on an exact value; this one interprets messy input before selecting from branches you define.

Context + allowed choices → decision + uncertainty.

What the API actually returns

A request contains a state, such as a customer email, and typed questions. Jev offers three primitives:

These distinctions matter. Noul is a probability, not just a Boolean. Score can fall between rubric levels: with levels 0, 1, and 2, probabilities of 0.1, 0.6, and 0.3 produce a score of 1.2. TypeSafe defines it as the probability-weighted average of the levels.

Here is a support example using the Python SDK. The client reads TYPESAFE_API_KEY from the environment:

from typesafe_sdk import Choice, Noul, TypeSafeClient

ticket = "Charged twice. Please cancel my account."
with TypeSafeClient() as client:
    response = client.system_one(
        state=ticket,
        questions={
            "route": Choice(
                instructions="Which team should help?",
                criteria={
                    "billing": "Charges and refunds",
                    "technical": "Broken product features",
                    "review": "Unclear or other requests",
                },
            ),
            "cancel": Noul(
                instructions="Is cancellation requested?"
            ),
        },
    )

route = response.answers["route"]
cancel_probability = response.answers["cancel"].noul

The route and cancellation signal answer different questions. A ticket can belong to billing and still need a retention workflow. Application code combines those answers. Including review also gives ambiguous requests somewhere to go.

Two changes in how you build

Ask independent questions together

Category, urgency, and cancellation intent can all be evaluated from the same email. Asking them sequentially adds round trips without adding information.

Jev evaluates questions independently and in parallel. TypeSafe’s fan-out pattern recommends including potentially relevant questions upfront, then letting code ignore irrelevant answers. Check bug severity alongside category; use it only if the ticket is a bug report. TypeSafe says additional questions typically add little latency, though they still add input tokens.

Questions that depend on newly retrieved information need a later call. The design change is to separate those dependencies from checks you can already make.

Make uncertainty change the workflow

TypeSafe trains Jev with Reinforcement Learning for Calibrated Decisions (RLCD). The objective is to return decisions and calibrated probabilities. Across many predictions, events assigned a probability of 0.8 should occur about 80% of the time. That is a calibration target, not a guarantee for any individual answer. TypeSafe’s primer describes the training approach.

There is an important distinction: Choice and Score also return confidence, a statistic describing how concentrated their probability distribution is. A confidence of 0.9 does not mean 90% accuracy. The full distribution remains available; Noul has no separate confidence field. The confidence documentation explains this.

That still gives code a useful control. Continuing the example, with application-defined functions and a threshold chosen from evaluation:

if route.confidence < min_confidence:
    send_to_review(ticket)
elif route.choice == "review":
    send_to_review(ticket)
else:
    route_ticket(ticket, route.choice)

For a PM, the metric is automation coverage at an acceptable error rate: how many tickets can move without review while keeping misroutes below the team’s target? Thresholds should come from that evaluation. A valid choice can still be wrong.

Why not use an LLM with structured outputs?

You can. Modern LLM APIs can enforce schemas and enumerated choices, so reliable JSON alone is not Jev’s advantage. OpenAI’s Structured Outputs is one example.

I would compare three things:

• Generation overhead. An autoregressive model produces output tokens sequentially, even for a small JSON object. Jev avoids that text-generation loop. TypeSafe reports 70 to 500 milliseconds end to end, with its tests generally run near the service on the West Coast.
• Useful uncertainty. Prompting a model to write "confidence": 0.95 does not establish calibration. Jev makes probability estimates part of its training and interface; their usefulness still needs testing on your data.
• Cost per completed decision. Count input, output, retries, and escalation. Jev still needs clear instructions and context. Compare it with a well-configured small model, not an unnecessarily long prompt.

Where I would use it

Support triage is the clearest starting point. A message like “You charged us twice, and we are considering leaving” contains both a billing issue and cancellation risk. Separate checks preserve both signals.

Personalization is another fit: choose an onboarding tour, help prompt, or standard view from recent session context. A default experience and a timeout keep the decision from holding up the page.

Browser agents can supply the current page’s text or accessibility tree and a list of available actions. Jev selects the next click, scroll, or form interaction. A separate question can flag a proposed action as modifying or destructive, but permissions still belong in application code.

Games and simulations make the speed requirement obvious. Given health, nearby enemies, and equipment, choose attack, retreat, cover, or heal. TypeSafe’s Doom demonstration uses structured game state. The appeal is changing behavior through instructions without manually specifying every situation in a behavior tree.

Trying it on this blog

I tested jev-ultrafast against Codex’s built-in browser. Both started from the loaded blog listing, opened this article, and moved through it to the final paragraph and footer.

Jev made 12 model decisions per run, including deciding it was done. The prepared Codex sequence needed no new model decision between steps. That explains why both fast approaches could finish in similar time, even though they worked differently.

These timings exclude setup and the later visual review. The faster results are the middle times from three runs each; the step-by-step result is one run. This is a small experiment on one familiar, mostly static page.

Both reached the correct endpoint. Jev’s navigation loop did not assess appearance. Codex’s separate visual review found cramped table spacing and code that needed sideways scrolling on a narrow phone screen.

My takeaway: Jev looks useful for repeated action selection. Predictable steps can already be fast, and checking visual quality remains a separate job.

The infrastructure angle: Less time generating text

A typical autoregressive LLM has two inference phases. Prefill processes the input in parallel. Decode generates the response one token at a time.

During decode, the GPU repeatedly reads model weights and cached attention data. With only a few requests being processed together, moving that data can take more time than the arithmetic. This is why memory bandwidth matters. A KV cache saves earlier attention calculations; the model does not recompute the whole conversation for every token. NVIDIA’s inference guide explains the tradeoffs.

Jev removes free-form text generation, avoiding that repeated output loop. My inference is that this creates room to spend more work evaluating the input and less moving data to emit a tiny answer. It does not prove that Jev eliminates memory bottlenecks or always uses the GPU fully.

For an infrastructure buyer, the interesting question is how many useful decisions each server can deliver within the latency target. Specializing the output could improve the economics when the application only needs a choice.

Pricing and the business bet

As of September 19, 2026, TypeSafe lists input pricing at $0.042 per million tokens, with free outputs. At 1,000 total input tokens per call, one million calls would cost $42 in model usage, before retries, infrastructure, and review.

That makes experimentation inexpensive. It also means TypeSafe needs substantial volume, larger workloads, or enterprise contracts to build a large business.

The name comes from Jevons: making something cheaper can increase how much people use it. The bet is that developers will add semantic checks in places where AI was previously too slow or expensive.

What would make this defensible?

The API is easy to understand. The harder advantage is reliable decisions on messy production data, useful uncertainty estimates, and consistent latency. Smaller LLMs, specialized classifiers, and ordinary rules will keep competing for the same work.

I am cautiously bullish. Jev gives developers a focused way to put language understanding inside application logic. The proof I would look for is more workflows completed correctly with less review, measured by their total cost. That is what turns a fast decision engine into a durable product.