Decision Models Explained: Jev, Clef, Laya and the Alternatives

October 2, 2026 / Arvid Andersson

A decision model answers your code's question with a probability for each possible answer. Jev made the idea popular in September 2026. Within three weeks there were open-weight alternatives (Laya, Kev), a Cloudflare model with open weights (Clef), EU hosting (System1 Models) and a preview from OpenAI. They are fast and cheap enough to sit inside a loop. They are not a replacement for an LLM.

What a decision model is

Most of what an application asks an LLM is not a request for prose. Is this ticket about billing? Should the agent call the search tool or the database tool? Is this message urgent? The answer is one of a few options. An LLM still produces it the way it produces everything else: token by token, as text your code then has to parse and trust.

A decision model skips the text. You send it a state (a message, a document, some JSON) and a set of typed questions. It returns an answer per question, with a probability for every allowed option:

• Choice: pick one option from a list you define.
• Score: rate something on levels you define.
• Yes/no: the probability that the answer is yes. TypeSafe calls this a "noul".

Because nothing is generated, all questions are answered in one pass. Pricing reflects that: Jev charges for input tokens only; output is free.

What it looks like in practice

In a test on 2 October 2026, Jev received a customer message ("I was charged twice for my October invoice and need the duplicate refunded before Friday") with three questions in one request: which team should handle it, whether it needs a reply within 48 hours and how frustrated the customer is on a four-level scale.

It answered billing with probability 1.0, urgent at 0.73 and frustration at 1.19 out of 3 (most weight on "mildly annoyed"). Eight requests took 0.22 to 0.28 seconds each from Sweden, network included. The request used 429 input tokens, which at Jev's listed $0.042 per million comes to about $0.00002.

At that price and speed you can ask on every incoming message or agent step.

The options, as of October 2026

Prices and specs checked against each provider's own pages, 2 October 2026. See all Jev alternatives in the directory.

What the table doesn't show:

• Laya works best fine-tuned. Its own benchmark shows accuracy going from 0.362 zero-shot to 0.766 after fine-tuning on the task. The English checkpoint reads 512 tokens; the multilingual one handles 100+ languages and up to 8,192 tokens if you raise the limit.
• Kev and Clef speak Jev's API. You can point TypeSafe's SDK at them, which makes switching cheap. Kev's README reports its own benchmark scores against Jev; Cloudflare reports its own for Clef. Both are self-reported; test on your own data before relying on them.
• OpenAI's version is a different design. Its Decisions API, in limited preview since DevDay (29 September 2026), uses Luna, a general-purpose model, to choose from predefined answers. OpenAI has not published pricing or said whether its probabilities are calibrated, which is the property the purpose-built models are trained for.
• EU options exist. System1 Models runs an EU-only tier on contracted EU operators with a DPA. Berget AI hosts Laya in Sweden. See the European AI providers list for more.

What people build with them

A community list of open-source Jev projects (awesome-jev-projects) keeps showing one pattern: the decision model sits inside a loop and makes the small calls a bigger model would be slow and expensive for.

• Routing: decide which model, team or handler gets a request. See AI gateways explained for the gateway side of this.
• Context pruning: score old tool output and drop what no longer matters before the next agent turn.
• Guards: check input and output for policy problems before they reach a user. The guardrails comparison covers the dedicated tools.
• Agent referees: judge whether an agent's "done" is backed by test output, before anyone trusts it.
• Re-ranking and filtering: score retrieved passages or dataset rows, then let code decide what to keep.

When not to use one

• You need text. Decision models choose; they don't write. Pair one with an LLM rather than replacing it.
• You have labelled data and one fixed task. A small model fine-tuned for that task can beat a general decision model. It also runs anywhere. indecis (MIT, Go) is one library for training tiny ones that run on a CPU.
• Your input is long. Context limits range from 512 tokens to about 65K. Check the model card for how accuracy holds up at your document length.
• Structured output from your current LLM is good enough. If you already call an LLM with a JSON schema and the latency and cost are fine, adding another model is extra moving parts. If that is where you are, there is no reason to switch yet.

FAQ