Jev, Laya, and the emerging role of decision models

Two recent releases have put a familiar machine-learning task back in focus: making a bounded decision from messy information. Jev and Laya offer different ways to do it, and their differences are as useful as the idea they share.

TypeSafe AI introduced Jev on September 15 as the first of its "System One Models." Within 24 hours of its arrival on Vercel's AI Gateway, nearly 13% of paid teams had used it, making it the gateway's fastest-adopted model launch. That figure measures early interest rather than lasting demand, but it is still unusual attention for a model that cannot write a response to a user.

Within days, Convai Innovations released Laya, an open-weight decision model that accepts similar questions and can run on a developer's own hardware. The two models arrive at a useful moment for AI applications. Agents and other automated workflows repeatedly need to classify an input, assess a result or make decisions based on available data. Developers have often assigned those jobs to a large language model (LLM) because an LLM can understand context and follow instructions. The application may then discard nearly everything the LLM generated except a label or number.

Jev and Laya are purpose-built to make those decisions.

What a decision model does

Suppose a customer writes, "I've been charged twice, and I can't get anyone to respond." A support system might need to decide which team receives the ticket, how urgent it is and whether the customer appears likely to request a refund.

An LLM can answer those questions, perhaps returning a JSON-structured answer which an application can read. A decision model takes a different route: the application supplies the customer's message as state and defines the possible answers in advance. The model returns choices, scores and probabilities that the application can use directly. It does not generate a paragraph that must then be interpreted or reduced to a label.

The demo below applies that same scenario type to all three of Jev's question types at once, an LLM's single generated guess against Jev's returned distributions. Try moving the sliders.

{
  "team": "billing",
  "urgency": "medium",
  "refundLikely": false
}

Both Jev and Laya support three question types:

• A choice selects from defined options, such as billing, technical support or sales.
• A score places the input on an ordered scale, such as levels of urgency.
• A noul estimates the probability that a yes-or-no statement is true.

Several questions can be submitted together against the same state. TypeSafe's API documents these primitives, while Laya exposes a closely related interface through its Python package and a Jev-compatible, self-hosted HTTP server.

Defining those questions is part of the work. In Every's account of a personal inbox filter, editor Jack Cheng asked Jev whether an email came from a person, whether someone he knew was waiting for him, and whether ignoring it would cost him something. The first version surfaced newsletters he did not consider urgent, so he revised the criteria against messages he had already judged. The filter improved when its questions more closely matched what "needs my attention" meant to him.

That interface makes the models particularly relevant to agent systems. An agent may need to select a tool, decide whether a result satisfies the user's request, route a task to a more capable model or flag an action for review. LangChain has demonstrated Jev for model routing and tool-risk checks, and added it as a judge in LangSmith Evals. These are bounded questions embedded in larger workflows, rather than requests for new prose.

"System One" is TypeSafe's name for this approach, borrowed from the idea of fast, intuitive judgment. It is a useful description of the intended role, though decision model is the broader term. Image and audio are modalities in the usual sense; a decision is a kind of output and a job within an application.

The idea has a longer history than the label

Models have classified text without generating it for decades. BERT helped make bidirectional encoders a standard tool for language understanding and classification. Research on zero-shot text classification showed that a model could evaluate labels described in language, allowing some classifications without training a new model for each set of labels. Reward models, moderation classifiers and model routers have since made other kinds of judgments from text.

LLMs became attractive for this work because they are flexible. A developer can describe a new task in a prompt instead of collecting examples and training a dedicated classifier. Strict structured outputs also address the problem of malformed JSON or unexpected fields. But the model still generates its answer token by token, even when the only useful result is one of three known options.

Jev's contribution is to package flexible, natural-language-defined questions as a dedicated decision service. TypeSafe says it uses a parallel sampler and a training method it calls Reinforcement Learning for Calibrated Decisions, or RLCD. It has not published enough architectural detail to independently assess all of its claims about the underlying model, but what developers can examine today is the interface, the observed behavior and its performance on their own tasks.

Laya makes a different part of the picture inspectable. Convai publishes its weights and code under the permissive Apache 2.0 license. Its English checkpoint uses ModernBERT-large with a decision head, while a separate checkpoint uses mmBERT for multilingual inputs. Developers can run the models locally, examine the implementation and fine-tune a checkpoint for their own decisions. Laya also offers a specialized checkpoint trained for four synthetic workflow types.

An application can frame its questions in much the same way for either model, while the choice of model changes who operates it, how it can be adapted and which limitations the developer must manage.

What the early results tell us

TypeSafe reports response times of roughly 70 to 500 milliseconds for Jev. Its most dramatic speed comparisons come from selected workflows. TypeSafe acknowledges that those examples use short, dense inputs that favor Jev and represent the high end of the gains it expects developers to see.

Convai reports local inference times of 39.5 milliseconds for one question on Laya's English checkpoint and 32.8 milliseconds on its multilingual checkpoint, measured on a Tesla T4 GPU. Ten questions in a batch took 158.6 and 72.3 milliseconds respectively. Those numbers describe warm local model inference on specified hardware. Comparing them directly with a hosted Jev request, which includes service and network time, would overstate what they tell us about the models themselves.

Accuracy is more revealing than either headline speed. On a synthetic benchmark covering customer service, invoices, security incidents and agent traces, Laya's specialized checkpoint reports 76.6% accuracy across 2,000 decisions. Its general English checkpoint scored 36.2% on the same test, below the benchmark's 46.1% majority-class baseline. The specialized checkpoint was fine-tuned on that benchmark's training split, so its result shows the value of adaptation to those workflows. It does not establish that the general Laya model can handle an unfamiliar decision equally well.

The models have different practical limits. Jev's API accepts up to 255 options for a choice question. Laya's options share a fixed input budget, and its documentation advises care above roughly 20 options at default settings. Its English checkpoint also defaults to a 512-token context, with 1,024 for the multilingual and specialized checkpoints. Those limits may be unimportant for a short support ticket and a few routes, but they could determine the design for a long document or dozens of closely related categories.

Laya's multilingual model is another useful option, but language coverage needs testing rather than assuming every supported language performs equally. Convai's own evaluation found that the English checkpoint could remain highly confident while failing on some non-English inputs. Its router attempts to select the appropriate checkpoint before inference. The model cards also warn that shipped probabilities can be overconfident and recommend calibration on held-out data before using them to control consequential actions.

A valid answer can still be wrong

Both projects describe a benefit of constrained output: the model cannot add an invented fourth option to a three-option question or fabricate a citation in a free-text explanation. TypeSafe markets this as Jev being unable to hallucinate, and Runware staff engineer Félix Sanz has examined what that claim actually covers: restricted to distributing probability across a fixed set of answers, Jev cannot invent an option or a fact outside that space. What it removes is the hallucination that comes with free-form generation, not errors in judgment. A confidently wrong choice from the options it was given is still wrong, and that class of error remains.

If a ticket belongs with billing and the model confidently routes it to sales, the response is perfectly valid at the API level and wrong at the business level. A probability is useful only when its relationship to actual outcomes has been checked on the kind of input the application receives. Laya's published calibration caveats make this especially explicit, while TypeSafe advises setting thresholds according to the consequences of each decision.

Sanz also found a practical example of how much the question itself matters. On a synthetic phishing-email dataset, Jev reached 62.6% accuracy when asked directly whether a recipient should click a link, compared with 81.3% for Claude Haiku 4.5. When the task was split into five specific signals and ordinary code combined them, Jev reached 95% on held-out data. Simple domain-based rules already reached 91.8% on that dataset. The signals were designed with knowledge of the synthetic data, so this is an engineering example rather than proof of production phishing performance. It shows why testing the whole decision process matters more than timing an isolated model call.

Code should still enforce exact requirements such as permissions, price ceilings and account balances. A decision model is useful where the input requires interpretation but the possible outcomes are known. A generative model remains useful when the application needs to create an explanation, draft a response or reason through an open-ended problem.

Where Jev and Laya fit

Jev offers a managed way to try decision models without operating a checkpoint. Its broad option support and natural-language-defined questions make it a reasonable candidate for routing, scoring and evaluation tasks that change frequently. Laya offers control over deployment and training. It is especially interesting when data must stay within an organization's environment or when a team has examples it can use to specialize a model for a repeated task. Its open weights also make the implementation available for inspection and further work.

Neither choice removes the need for an application-level evaluation. A useful test set should contain real inputs, expected outcomes, ambiguous cases and examples where the right answer is to escalate. Measure decision quality, calibration and total request latency. Compare the result with a small LLM using structured output and with ordinary rules. For some workloads, one of those simpler options will win.

Runware has added both Jev and Laya to give developers that choice.

What's new in Jev 1.14

TypeSafe released Jev 1.14 on October 14, describing it as small improvements across the board, with the largest gain expected in multilingual support. TypeSafe shares its own benchmark estimates alongside the release, but advises developers to favor their own experiments and evals, which is the same advice this post gives above.

On Runware, Jev 1.14 is available as typesafe:jev@1.14, with a 262,144-token context window. That is enough to put long logs, documents, or conversation histories into a single decision, though TypeSafe still strongly recommends limiting context length. The price is unchanged from Jev 1.13: $0.042 per 1M input tokens, and output is free.

Jev 1.13 stays available as typesafe:jev@1, and TypeSafe says it intends to give 60 days' notice before deprecating it. Before moving a workflow to 1.14, rerun its test set and check its thresholds again. A new version can shift the probabilities that a threshold was tuned against, even when it makes better decisions overall.

The release also opens what TypeSafe calls a "danger zone" of experimental features, each switched on with a request header. Images can now appear in a request's state, instructions, or criteria, and a new box question type returns a single bounding box. TypeSafe says these features still have too much "jaggedness" for production use, and that all models, Jev included, perform worse on images than on pure text. For now, they are something to explore rather than build automation on.

Implementing Jev and Laya with Runware's API

Jev and Laya run on Runware's /v1/decisions endpoint, which takes TypeSafe's decisions format. Send your Runware API key in the Authorization: Bearer header, and reference each model by its AIR:

A request pairs a state, the material being judged, with one or more questions. Each question uses one of the three primitives described above: a choice, a score, or a noul. Because the application defines the possible answers in advance, the response returns probabilities and confidence values that code can act on directly, with no generated text to parse.

TypeSafe's Python and TypeScript SDKs work with Runware when you point their base URL at https://api.runware.ai and pass your Runware API key. Set model on every request, because the SDKs' default isn't a Runware model ID.

curl -X POST https://api.runware.ai/v1/decisions \
  -H "Authorization: Bearer $RUNWARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe:jev@1.14",
    "state": "I was charged twice. Please fix this ASAP.",
    "questions": {
      "category": {
        "type": "choice",
        "instructions": "What is this ticket about?",
        "criteria": {"billing": null, "technical": null, "other": null}
      }
    }
  }'

The support ticket from earlier needs three decisions: which team should take it, how urgent it is, and whether the customer is likely to ask for a refund. One request can ask all three against the same state:

curl -X POST https://api.runware.ai/v1/decisions \
  -H "Authorization: Bearer $RUNWARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe:jev@1.14",
    "state": "I was charged twice, and nobody will respond to me.",
    "questions": {
      "team": {
        "type": "choice",
        "instructions": "Which team should handle this ticket?",
        "criteria": {"billing": null, "technical": null, "sales": null}
      },
      "urgency": {
        "type": "score",
        "instructions": "How urgent is this ticket?",
        "criteria": [
          "Can wait",
          "Needs attention this week",
          "Needs attention today"
        ]
      },
      "refund": {
        "type": "noul",
        "instructions": "Is the customer likely to ask for a refund?"
      }
    }
  }'

Each answer comes back under answers, keyed by its question's name. team returns the selected choice, a probabilities map covering all three options, and a confidence. urgency returns a score with a legend of its levels, plus probabilities and confidence. refund returns noul, the probability that the answer is yes. Runware's Compatible APIs docs list the models on the endpoint, and TypeSafe's API reference covers every field.

Pricing

Prices are in USD per 1M tokens.

None of the three charges for output tokens.

Decision model concepts glossary

Decision models give developers a new kind of model output to work with: a bounded judgment that software can act on. That brings a vocabulary of its own. A developer supplies the state, defines the question and its possible answers, then decides how much uncertainty the application can tolerate. The concepts below follow that path from input to decision.