Laya arrives as an open source alternative to TypeSafe AI's Jev

ConvAI Innovations launched Laya, a family of open source models (Apache 2.0) designed to replace generative LLMs in classification and fast-triage tasks, what founder Nandakishor Mukkunnoth calls "System 1" decisions: routing a ticket, flagging an email as phishing, giving an urgency score. The motivation Mukkunnoth states in his technical post is direct: in September 2026, TypeSafe AI, founded by Diogo Almeida (one of the co-authors of ChatGPT at OpenAI), launched Jev, a non-autoregressive decision engine with a paid API at $0.042 per million input tokens and latency of ~150ms. Mukkunnoth claims to have published the same core idea a year earlier, in a March 2025 paper and in another from September 2025, with open weights on Hugging Face (sales-conversion-model-reinf-learning) and a public dataset (saas-sales-conversations). Laya is the answer: it takes the same architectural proposal but ships the package as a 100% open project.

The problem Laya tries to solve

The argument is that using an 8B, 70B, or frontier generative LLM to answer "is this ticket urgent?" is wasteful: it means 500ms to 2,000ms waiting for tokens, inference cost, JSON parsers to extract a free-text label, and, worst of all, fabricated confidence. When an LLM answers "confidence": 0.95, it's predicting tokens that sound confident, not actually computing a calibrated probability. Laya proposes to solve this with a bidirectional encoder that never generates text: it answers typed questions about a state (text, email, ticket, JSON) in a single forward pass, so there's no malformed JSON or format hallucination.

The three decision primitives

Laya's SDK works with three types of questions:

• choice: picks one option from a dictionary of criteria, returning the chosen key, the probability distribution over all options, and a calibrated confidence score.
• score: places the state on an ordinal rubric (0, 1, 2...), returning the expected level and the distribution over ranks.
• noul: a direct boolean question, which returns a calibrated P(true) between 0.0 and 1.0.

In practice, this means running several questions at once against a single payload, as shown in the example from the project's own repository:

from laya import Router

router = Router(preload=True)
ticket = {
 "ticket_id": "TCK-8821",
 "body": "Our production API has been failing since 6 AM..."
}
questions = {
 "queue": {"type": "choice", "criteria": {"infrastructure": "...", "billing": "..."}},
 "urgency": {"type": "score", "criteria": ["low", "medium", "high", "critical"]},
 "churn_risk": {"type": "noul", "instructions": "Cliente ameaça cancelar?"}
}
res = router.predict(ticket, questions)

The call returns the queue, urgency score, and churn risk in the same forward pass, with no text parsing.

Three checkpoints and language-based routing

Laya is distributed as a single hub on Hugging Face (convaiinnovations/laya) with three checkpoints: an English one built on ModernBERT-large (421M parameters), a multilingual one built on mmBERT-base (322M, more than 100 languages), and one specialized for typed decisions in customer support and agent observability. Instead of downloading the combined 2.5 GB, the SDK uses Hugging Face's allow_patterns to download only the requested subfolder (laya.load("convaiinnovations/laya", subfolder="multilingual")).

The most specific point of the announcement is a 51-language sweep on the MASSIVE benchmark, which showed the English checkpoint silently failing outside the Latin alphabet: 0% accuracy on Khmer with 95.2% average confidence, 5% on Armenian (equivalent to random chance) with 88.5% confidence, 6% on Hebrew, and 8% on Bengali, always reporting high confidence. The author's conclusion is that the model's own confidence score doesn't work as an alarm when it can't read the input script, so the decision of which checkpoint to use has to be made before the forward pass. That's why Laya embeds a pure-Python Router that detects the Unicode script (22 alphabets, including Devanagari, Han, Cyrillic, and Arabic) with an overhead of 0.09ms for English text and 0.54ms for Devanagari text, negligible compared to the ~33ms of the main forward pass.

The direct comparison with Jev

The post includes a comparison table between Laya (routed) and Jev 1.13.0. It's worth noting the author's own caveat: Laya's numbers are measured by him, while Jev's come from independent third-party studies (cited as AbdelStark and nibzard) and from material published by TypeSafe AI itself, not from a neutral benchmark run by ConvAI under the same conditions. Even so, the reported numbers are notable:

• P50 latency for a single question: 236-276ms for Jev versus 32.8ms for Laya (about 7.8x faster).
• For a batch of 10 questions: ~1,500ms serial for Jev versus 72.3ms for Laya (7.2ms per question), a 20x difference.
• Calibration error (ECE): 0.246 for Jev versus 0.081 for Laya, about 3x better.
• Accuracy on AG News (4 classes): 91% for Jev versus 95% for Laya.
• On the DAIR emotions dataset (6 classes): 48% for Jev (with a Brier score of 0.846) versus 59.5% for Laya, with the author noting that Jev shows 16% zero-probability in some answers.
• Cost: $0.042 per million tokens for Jev (metered API) versus $0 for Laya, which runs self-hosted.

In applied workflows published by ConvAI, Laya reaches 99.3% accuracy on spam filtering (Enron dataset), 98% on phishing detection, and, on the jailbreak guardrail over ToxicChat, 75.5% to 76.2% raw accuracy, rising to 93.1% when only the 50% of cases with the highest confidence are answered ("selective coverage").

Where Laya falls short

The announcement itself lists limitations worth reading before deciding to migrate anything into production. On choice questions with more than 20 options, performance drops sharply: on Banking77 (77 labels), Laya scored 0.425 versus 0.870 for Jev, because the options split a budget of 192 to 256 tokens in the header, leaving only 3-4 tokens per candidate when there are 77 options. The author's recommendation is to keep choice schemas below 20 options or use a coarse-to-fine, two-step hierarchy. Another point: the base weights, without fine-tuning, run close to chance (~0.35 on the typed-decisions benchmark); the reported result of 0.766 only appears after tuning the model on the benchmark's own training split, meaning Laya should be treated as a fast base to specialize, not as a zero-shot oracle. And the factory temperature calibration is poor: adjusting a single temperature scalar per question type on the user's domain would reduce the ECE from 0.466 to 0.081, according to the post.

How to try it

Installation is via pip install laya>=0.3.3, with weights available on Hugging Face, code and a reproducible benchmark harness on GitHub, plus an interactive demo space (convaiinnovations/laya-demo) running on ZeroGPU and a fine-tuning notebook on Kaggle with two free T4s, promising to train a custom model in about 4 hours.

What changes for builders

For those who already use a generative LLM (via paid API or local model) just to route a ticket, flag urgency, or filter spam, Laya's proposal is to trade a slow, expensive call for a ~33ms forward pass that runs on a common GPU, with no per-token cost and no dependency on an external API, which enables air-gapped or on-premise scenarios that Jev, being proprietary, doesn't support. The real point of attention lies in the limitations the author himself admits: schemas with many options and the need for fine-tuning to move past near-random zero-shot performance. Before swapping out a production pipeline, it's worth running your own benchmark on the specific domain, since the direct comparison with Jev made in the announcement mixes numbers measured by ConvAI with third-party numbers about the competitor.