Laya 421M: the open decision model behind the jev-fast lane

Laya is a 421-million-parameter decision model from convaiinnovations, published under Apache 2.0. It carries open weights, a ModernBERT encoder under the hood, and one job. That job is answering fixed-shape questions with a typed decision and a calibrated probability. It is the open-weight answer to Jev, the typed-decision model TypeSafe AI released with closed weights on 15 September 2026. It leads the clone wave that followed. On this platform it has a planned lane, jev-fast, the speed tier of a three-lane decision family. The lane is written, with its row sitting behind the public list. Nothing answers under the alias today. The rate is set, and no date is promised. What this page carries is the capability record and the working contract, so the integration can be written before the switch flips.

Last verified: 2026-09-25

What it is

The identity facts, each with the owner of the number named:

Non-autoregressive, in plain language: the model reads the whole input and answers in one pass. It does not write token by token. That is why a question costs milliseconds and a sub-gigabyte footprint, and why it never produces free-form text. That last part is the design, not a limitation to work around: the output is a decision.

Calibrated also deserves its plain definition. A calibrated probability is one the model has been trained to mean. When it says 0.8, it is right about eight times in ten. Laya gets this from its training objective, a proper scoring rule, which scores a model best when its probabilities are honest. For any use that thresholds or combines probabilities, calibration matters. It is the difference between a number and an answer.

A decision model, not an LLM

The category Laya belongs to borrows its name from decision science. The psychologist Daniel Kahneman described thinking as two systems. System 1 is fast and automatic, the snap judgment. System 2 is slow and deliberate, the reasoned argument. A decision model is a System 1 for software. You pass a state, some context, and a fixed-shape question. It returns a typed answer with a calibrated probability, in milliseconds. There is no generation step at all. A large language model is the System 2 tool. It writes, reasons at length, and spends a full generation pass on every call.

The rule of thumb follows the split. When the question is "which of these options", asked thousands of times an hour, a decision model is the tool. It answers for a fraction of the latency and work of an LLM pass. When the question is open-ended, or the answer must be prose, use a chat model. The two are complements. Avoid burning System 2 work on System 1 questions.

Which Laya this page is about

Search the name and you will meet other Layas: retail stores, a movement brand, and other consumer properties that share it, none of them AI companies. This page is about one Laya. That Laya is the open-weight decision model published under the convaiinnovations organization on Hugging Face. It is the one the Jev clone wave is about. The model card and the publisher's site are the anchor points. A page that discusses a Laya and links to neither is probably about a different one.

The platform posture, stated once and plainly. The jev-fast lane is planned as the fast tier of a decision family on the platform's classifier program. Its row sits in the platform's model data behind the public list. Nothing answers under the alias. The rate is set, and no date is attached to the listing. When the row joins the public list, the models index carries the catalog state, and the contract on this page is the one that goes live.

Use cases

The fast-tier profile: one fixed-set judgment per item, at volume, where a full generation pass is the wrong shape of work.

• Query and intent routing in agent stacks. Picking between tools and handlers per turn is a typed decision between named options. That is exactly the benchmark shape the head-to-head below used. At tens of milliseconds per decision, routing stops being the slow part of an assistant.
• Triage and sorting. Support tickets, moderation queues, feed labeling: any stream where each item needs one judgment from a fixed set, and needs it before the next item arrives.
• Multilingual queues. The router covers 100+ languages through one model, so a mixed-language queue needs no per-language deployment and no routing table of language packs.
• Backfill and batch classification. The batched question cost, 7.2 ms on T4-class hardware in the publisher's numbers, turns a million-item backfill into a scheduling problem rather than a modeling one.
• Jev-trained pipelines that want open weights. The wire contract Jev defined is public, and this lane's compatibility layer is built to speak it. An existing decision client gets a migration path that does not start with a rewrite. The compatibility story is in the API section below.

Where not to use it, from the same record: wide option sets out of the box, which the three-checkpoint router covers less well and which belong to the causal fallback lane. Open-ended questions are chat-model work by definition.

The three-lane family

The platform's decision program is planned as three lanes over one wire contract, split by shape rather than by price.

All three are coming soon, each with its own page, and none is on the public list yet. The classification category page carries the wider classifier family. The content-taxonomy and extraction models are planned alongside these lanes.

Self-host or a metered lane

Apache 2.0 makes the self-host road fully open, and for this model it is a real road. You get about 0.9 GB of weights from the model card. The official repository carries serving code and a PyPI package. Publisher-published numbers on T4-class hardware serve as the footprint guide. One mid-range GPU serves it comfortably. CPU serving is viable at lower throughput for modest queues.

The usual decision rule applies. Self-host when the machine is already there, when fine-tuning in-domain is the plan, or when data cannot leave your boundary. The model rewards domain tuning, and community testing of the wave puts its strongest results in-domain. Use a metered lane when you would rather not own the surrounding work. That work is pinning releases, re-checking calibration after each update, and running the serving, routing, and metering. That work is what the lane sells, against a prepaid wallet whose balance is the spend boundary.

API usage

The lane is planned to ride the platform's OpenAI-compatible chat route: POST /v1/chat/completions on https://api.ironstratum.com/v1. It takes a bearer key from the console and the model id jev-fast. This is the adapter pattern the platform already uses for models with their own contracts. The route keeps the standard chat shape. An adapter underneath owns the model's own contract. For this lane the contract is the System One wire shape Jev defined. A state and a fixed-shape question go in. A typed answer with a calibrated probability comes out. It is carried through the contract's three answer primitives, choice, noul, and score, in the contract's own terms. A choice supplies options and gets the pick back with a calibrated confidence. A noul is the binary door, a statement and a probability of yes. A score returns an expected level on a scale you define. The API reference documents the chat route's full parameter set.

Why the wire contract matters needs one piece of category history. Jev's native API is not OpenAI-shaped: it takes typed decision requests. The guides written since its release all route readers through adapter layers. The contract itself is public and standardized, and third parties already serve Jev-class lookalikes behind it. That proves a compatible lane can take those clients as they stand. Whether the lane also exposes the System One primitives directly at their own paths, beside the chat face, is a row-landing decision. This page does not predict it.

Three things the tabs below deliberately do not show:

1. No price in the tabs. The starting rate is set and this page's search listing carries it, but the tabs stay contract-only: the catalog surfaces publish the rate, rendered from the same source, when the row joins the public list.
2. No availability claim. The examples are the shape of the contract, not an open service. Nothing on this page is a launch date.
3. No invented field surface. The exact request and response fields beyond the standard chat shape, and the native primitive paths if the lane exposes them, publish with the row. The tabs stick to fields every party already agrees on.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-fast",
    "messages": [
      {
        "role": "user",
        "content": "Route this support ticket to exactly one of: billing, technical, legal, other.\n\nTicket: my card was charged twice for the march invoice"
      }
    ]
  }'

The decision request rides the message text. That text holds the options, the instruction, and the state to judge. The answer you read back is a typed decision with a calibrated probability, not free-form text.

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "jev-fast",
        "messages": [
            {
                "role": "user",
                "content": (
                    "Route this support ticket to exactly one of: "
                    "billing, technical, legal, other.\n\n"
                    "Ticket: my card was charged twice for the march invoice"
                ),
            }
        ],
    },
    timeout=30,
)
resp.raise_for_status()

body = resp.json()
print(body["choices"][0]["message"]["content"])
print("usage:", body["usage"])

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="jev-fast",
    messages=[
        {
            "role": "user",
            "content": (
                "Route this support ticket to exactly one of: "
                "billing, technical, legal, other.\n\n"
                "Ticket: my card was charged twice for the march invoice"
            ),
        }
    ],
)

print(response.choices[0].message.content)
print("usage:", response.usage)

An integration written against the OpenAI SDK needs two changes to point here: the base URL and the model id. That is the whole migration. That is the point of serving a typed-decision contract behind the standard chat shape.

What answers today is the honest state: with the row still behind the public list, the route refuses the jev-fast model id with a not-found error. That error is the signal to watch. The row joining the public list is the event that flips it.

Benchmarks

Two layers of evidence follow, dated and attributed, and a third that does not exist yet.

The published head-to-head. An independent benchmark, published in the clone-wave coverage (September 2026, read from our records the same month), ran Laya against Jev 1.13. It covered 2,000 typed routing decisions. It is published at jev001.org and carried by the wave's coverage sites, flowtivity.ai among them:

Read that with its labels on, because the sharpest caveat sits inside the table's own numbers. The 0.766 belongs to a checkpoint fine-tuned on the benchmark's own training split. Zero-shot on the same benchmark, the encoder scored 0.362 against Jev 1.13's 0.727, below the majority baseline of 0.461. It is one benchmark. It covers one decision shape (routing), run by one independent party. The calibration figures live in the source's own tables. The coverage that carried it added the boundary worth keeping. Community testing found Laya wins in-domain or fine-tuned. It found Jev wins out of the box on wide option sets. One benchmark review's summary called Laya a credible open-source candidate. It stopped short of calling it a proven universal replacement. That framing, not a single number, is the honest state of the comparison.

The publisher's own numbers. From the official repository: 33 ms per question single, 7.2 ms per question batched, on one T4. The router runs over three checkpoints. These are the publisher's measurements of its own model, dated September 2026. They set the expectation for the lane's class of hardware rather than for any specific host.

This platform's numbers. None exist yet: no lane serves the model, so there is nothing to measure. What is written down instead is the listing gate the lane must pass. The gate is a pass on a standardized decision benchmark. The model must be pinned to a release checksum, with a calibration spot-check against the published figures. All of that comes before the row goes live. The lane's design target is a sub-50-millisecond median for a single decision server-side. The target publishes as a claim only if it is measured and held.

Getting started

1. Evaluate the model today. The model card, the publisher's site, and the official repository are the three primary sources, and the repository's PyPI package is the self-host path if you have the hardware.
2. Join the console's invite flow. The platform runs as an invite-only beta in this phase; the console signup opens the wallet, the keys, and the spend history.
3. Watch the catalog, not this page, for the landing. The models index carries the catalog state. The row joining the public list is the event that turns the alias on; no date is promised here.
4. Write the integration now. The tabs above are the contract: a key, the alias, and a decision in the message text. A client written against them today changes nothing the day the row lands.

For the sibling lanes, see jev-causal and jev-batch. The classification category page maps the platform's classifier family.

Last verified: 2026-09-25