Using Jev for Model Routing

What is Jev?

Choosing a model is itself an AI problem. A router needs to understand what a user is asking, estimate how demanding the work will be, and decide which model can handle it at an acceptable cost. Asking a large generative model to make that decision can introduce a surprising amount of overhead before the real work even starts.

Jev is a structured decision model built by TypeSafe, the first in its System One model family. You send application state and a set of narrowly defined questions. Jev returns typed answers and probabilities that software can use directly. Routing is one application; classification, verification, and ranking are others. TypeSafe’s System One documentation explains the model family.

How Jev differs from a traditional LLM

A generative LLM produces text, code, or other content. Even when you ask it to classify a request, it typically generates an answer that you then interpret. Structured output can constrain that answer to a schema, but the interaction still uses a generative model.

Jev understands natural-language input but returns decisions from an answer space you define. It does not write the final response, generate code, or provide a reasoning trace. Its job is to help your application decide what should happen next. A separate model still handles the user’s actual task.

TypeSafe describes Jev as trained for calibrated decisions: across groups of predictions, probabilities should reflect observed outcomes. That is useful for setting escalation thresholds, but a high probability does not guarantee that an individual classification is correct. Jev’s predictable output format makes integration easier; it does not make the judgment infallible.

Three decision formats

Jev supports three primitives. Choose the one that matches the decision your routing policy needs to make. Several independent questions can share the same state in one request, but they cannot inspect each other’s answers. OpenRouter’s tutorial documents the request and response fields.

How classification helps model routing

Classification turns a varied stream of requests into signals a routing policy can act on. A short prompt can be a difficult mathematics problem; a long prompt can be a straightforward extraction task. Task type, ambiguity, and required capabilities often tell you more than prompt length alone.

A useful flow is: request → classification → policy → eligible model → response. Jev supplies the classification. Your policy maps the result to models that you have already evaluated for that kind of work.

For example, routine extraction might go to a low-cost model, ordinary coding to a mid-tier model, and difficult debugging to a stronger reasoning model. If the decision is uncertain, use a conservative default. These mappings are application choices, not guarantees supplied by Jev.

Apply hard constraints before selecting a route. A classification must not override your requirements for tools, structured output, context length, data handling, or approved providers. Once a model is selected, provider routing can separately choose the endpoint that serves it. See our guide to model routing strategies for the broader picture.

Classify a request through OpenRouter

OpenRouter exposes Jev through its Decisions API using an OpenRouter API key. The example below asks for a task category. It makes a classification call only; your application must then apply a routing policy and send a separate generation request.

Keep the API key server-side. This example pins typesafe/jev-1.13; OpenRouter also provides ~typesafe/jev-latest, which follows the newest release. Pinning a version helps keep a routing policy stable while you evaluate future model updates.

curl https://openrouter.ai/api/alpha/decisions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "state": {
      "request": "Find the cause of this intermittent database deadlock."
    },
    "questions": {
      "task": {
        "type": "choice",
        "instructions": "Which category best describes the request?",
        "criteria": {
          "extraction": "Extract or reformat information already provided.",
          "coding": "Write, modify, or debug software.",
          "analysis": "Compare evidence or solve a reasoning problem."
        }
      }
    }
  }'

Turn decisions into a routing policy

Read answers.task.choice, answers.task.probabilities, and answers.task.confidence from the classification response. Confidence describes how concentrated the alternatives are; it is not a measured probability that the downstream model will complete the task successfully.

Define the categories carefully. The coding category in the example is broad enough to include both a trivial edit and a difficult deadlock investigation. Add an independent difficulty question or use narrower categories if your routing policy needs to distinguish those cases.

Choose thresholds using labeled examples from your own traffic. An incorrect cheap-model assignment can cost more than the tokens it saves if it causes extra turns, failed tool calls, or manual rework. Low-confidence decisions should take a route that you have validated as an acceptable fallback.

Account for the whole request path. Direct Jev calls are billed for input tokens, with output tokens free under the documented pricing model. Sending large histories still costs money and takes time. Include classification, generation, retries, and cache effects when comparing against a fixed-model baseline.

OpenRouter’s Jev implementation

There are two ways to use Jev on OpenRouter. Direct decision calls give you typed judgments for your own policy, through the Decisions API or the TypeSafe SDK configured for OpenRouter. Jev Router is a packaged routing endpoint, typesafe/jev-router, that uses Jev to choose the model and reasoning effort for a request and returns the downstream model’s response.

OpenRouter lists Jev Router’s release date as September 25, 2026. Its model page describes selection across quality, speed, and cost, adaptation as the conversation evolves, and use of ecosystem token and spending shares. That makes it a convenient starting point for experimenting with automatic selection. OpenRouter’s Jev Router page is the reference for the current offering.

The distinction matters: calling Jev directly does not produce a chat answer, while calling Jev Router delegates selection and generation. The decision model’s context limit and supported inputs also should not be assumed to describe the packaged router’s downstream model capabilities.

OpenRouter’s existing custom classifiers serve another purpose: tagging usage for reporting after a request. A classifier used before generation participates in the routing decision. Adding Jev therefore expands what developers can build beyond post-request analytics.

Evaluate Jev routing on your workload

Start with a fixed model that already meets your quality requirements. Compare a Jev-based policy and the packaged Jev Router against that baseline using representative requests, including ambiguous inputs, tool calls, long conversations, and cases where switching models could break useful cache affinity.

Record classification accuracy, selected model, reasoning effort where available, end-to-end latency, total cost, retries, and task completion. Break results down by task category so aggregate savings cannot hide quality regressions on difficult work.

Jev is most interesting when traffic varies enough for model selection to matter and the classification step is inexpensive relative to the work it directs. A workload already well served by one inexpensive model may have little to gain. Start with a narrow policy, measure the outcome, and expand when the evidence supports it.