Laya vs Kev: Two Recipes for a Local Decision Model

The most useful number in the Laya-versus-Kev comparison is a receipt. Jared Palmer trained the Kev family for roughly $95 in H100 time on Modal, plus about three cents of API calls for evaluation data, and published the recipe alongside the weights. Convai Innovations took the other route with Laya: released September 18, 2026, three days after TypeSafe AI's Jev, Apache 2.0, weights on Hugging Face, a pip install laya entry point, and no training pipeline — a 421M ModernBERT-large English checkpoint, a 322M mmBERT-base multilingual one, and a router that picks between them. Kev is a family of three small models at 0.8B, 4B and 9B, each a frozen base plus a rank-16 LoRA adapter and a small pointer head. Both answer typed questions in one forward pass and neither generates text. The decision between them is really a decision about which artefact you want to own: a checkpoint or a recipe.

What each project is actually shipping

Laya ships inference. The English checkpoint is a bidirectional encoder with a 512-token window; the multilingual one covers 100+ languages at a 1,024-token window and runs about twice as fast; the router detects script in under half a millisecond. It answers choice, score and noul — a pick from a list, an expected level on an ordered rubric, and a calibrated probability that a claim is true. There is a third checkpoint, laya-typed-decisions, which is the same 421M backbone fine-tuned on the training split of the typed-decisions benchmark. Convai's own model card carries the sentence that should govern how you read every Laya number: "Laya is a fast base to specialise, not a zero-shot decision engine."

Kev ships a method. The repository documents decision-v7: two epochs over 10,000 examples drawn from ten public datasets, 896 generated policy examples, and 1,680 examples built from 60 generated rule structures. The head scores each supplied option against the question's decide token and softmaxes the result. Because the Qwen3.5 checkpoints mix attention with recurrent Gated DeltaNet layers that ignore attention masks, each question runs as its own row with the shared state computed once and cached — which is how the model keeps questions isolated from one another without paying for a fresh prefill per question. Kev mirrors TypeSafe's public /v1/systemone contract, so an existing TypeSafe SDK client can point at a local Kev server by changing the base URL. The README states that no Jev outputs were used in training.

The two failure modes are different, and that is the real story

Both models lose to Jev on the tasks that require knowing things, but they lose in ways that call for different mitigations.

Laya's published weaknesses are about the shape of the input. On TypeSafe's typed-decisions benchmark it scores 0.362 zero-shot, against 0.318 for random guessing and 0.461 for the majority-class baseline — closer to chance than to the trivial answer. Past roughly twenty options it falls apart: 0.425 on Banking77 against Jev's 0.870. It is order-sensitive enough that a pure flip of option order dropped accuracy 13.75 points in one third-party test, leaving a 42.5% same-answer rate. And the shipped checkpoints arrive with invalid temperatures — the library warns at import, which means the calibration figure on the card, an expected calibration error of 0.466, is the number you actually get before you refit. Refitting per question type takes it to 0.081, but that is work you do, not work the download does. There is a published multilingual failure that is worth reading in full: on non-Latin scripts the English checkpoint is catastrophically overconfident, with a Khmer example showing 0.000 accuracy at 0.952 average confidence.

Kev's published weaknesses are about knowledge and arithmetic. Kev-9B scores 0.837 on its own locked new-source test — 0.832 for the 4B and 0.668 for the 0.8B — and around 0.822 out-of-domain on the dev split against Jev's 0.857. The gap opens where world knowledge is required: MMLU around 70% against Jev's 90%, MMLU-Pro 0.515 against 0.840, and day-precision date arithmetic 60% against 93%. On a narrow fixed-label routing set it wins — a support-ticket routing evaluation put Kev-9B at 0.952 against Jev's 0.897 — but the author is explicit that this is his own harness, that Jev's training data is undisclosed, and that no controlled comparison is therefore constructible. Kev also stays overconfident on new sources; setting KEV_TEMPERATURE=2.0 cut confident errors from 8.7% to 4.4% in the project's own testing, which tells you the default is not the safe setting.

The practical translation: Laya's failure is triggered by your option set and your prompt formatting, and you fix it by fine-tuning and refitting. Kev's failure is triggered by questions that need facts, and you fix it by scoping the model to routing and classification and keeping the knowledge-dependent calls elsewhere. Neither fix is a config flag.

What it takes to serve them

• Hardware — Laya: 421M/322M encoders, credible on CPU for low throughput and under a gigabyte resident for the MLX port on Apple silicon. Kev: 0.8B to 9B, needing a BF16 CUDA GPU for the 9B, with the Qwen3.5 architecture requiring flash-linear-attention on CUDA and ROCm.

• Latency — Laya: 32.8ms p50 per decision on a Tesla T4, 7.2ms per question at batch 10. Kev: about 300ms for five typed questions from a 4B model on a 32GB Mac in bf16, roughly 40ms on an H100.

• Ceilings — Laya: 512-token English window, 1,024 multilingual. Kev: choice over 1–255 options, score over 2–255 levels, 384 training-state tokens with 8,192 at serving.

• Server — Laya: in-process Python, plus community ONNX, Go and Apple MLX ports. Kev: a local server bound to 127.0.0.1 with no authentication, an npm SDK, and LangChain and LlamaIndex adapters.

• Licence — Apache 2.0 for both.

Two operational notes that do not appear in the headline numbers. Kev's server is single-request and unauthenticated by design — it is a local sidecar, not something you expose. And Kev's Mac latency is materially worse than its H100 latency because the fast DeltaNet kernels do not exist for MLX yet, which is exactly the kind of detail that turns a "runs locally" claim into a "runs locally on the right hardware" claim.

The generative half of the pattern

Both of these models exist to replace one specific call: the LLM invocation you were making purely to get a label or a probability back. They do not replace the calls where you actually need prose. A support system that uses Kev-9B to route a ticket still needs a model to summarise the thread and draft the reply, and that model is not going to be a 9B LoRA with a pointer head.

That is the seam OrcaRouter sits in rather than a claim about hosting either of these. Neither Laya nor Kev is on our model list — they are weights you download — and the article would be misleading if it implied otherwise. What is on the list is the 200+ generative models behind one OpenAI-compatible key at provider list price passed through with 0% markup. If you are using Kev to decide which of three summarisation tiers a request belongs in, or using Laya to score whether a draft answer is acceptable, the generative side of both loops is one endpoint with automatic failover instead of a second contract and a second SDK. The routing DSL is the piece that fits a decision-model architecture most naturally: compose a cheap model and an expensive one into a single call and let the decision model's output pick the branch.

What to watch next

The gap in the evidence is the same for both, and it is not going to be closed by either project. Nobody has run Laya and Kev on byte-identical inputs with the same prompts, the same option ordering and the same confidence-threshold sweep. Laya's headline wins come from its own harness; Kev's near-parity claims come from its author's harness; the calibration audit that found Jev's calibration varying sharply by task — 44.7% accuracy and 0.325 expected calibration error on a hidden-policy priority task — was a third party's, and neither Laya nor Kev has had that treatment. Until someone does it, the numbers above are the best available and they are not comparable to each other.

If you are deciding today: take Kev if you want a working routing model this week on a GPU you already rent, and accept that it will not know things. Take Laya if your inputs are multilingual or your hardware budget is a laptop, and budget the fine-tuning as part of the project rather than as a later optimisation. Either way, measure on your own labelled data before you put a confidence threshold in front of production traffic — both projects, in their own documentation, tell you to.