Laya vs Decider: A 421M Encoder Against a 35B Mixture

Laya and Decider are both open-weight, non-autoregressive decision models that answer typed questions — a choice from a supplied list, a score on an ordered rubric, a yes/no probability — in a single forward pass, and they sit at opposite ends of the size spectrum. Convai Innovations released Laya on September 18, 2026 under Apache 2.0: a 421M ModernBERT-large encoder for English with a 512-token window, a 322M mmBERT-base multilingual checkpoint with a 1,024-token window covering 100+ languages, and a router that detects script and dispatches to the right one. Mapika's Decider family runs from decider-0.8b and decider-2b on small generative bases up to decider-35b-a3b, a 35B mixture-of-experts with roughly 3B active parameters. Both are free to download and both return probabilities rather than text. The reason they are not interchangeable is not the accuracy figure most write-ups lead with.

Two families, one architectural bet

The shared bet is that a decision does not need a decoding loop. A generative model asked "is this ticket a refund request?" has to emit tokens, and the moment it emits tokens you own parsing, schema validation, and a retry path for the one time in two hundred it forgets a brace. Laya and Decider both skip that by reading the answer directly out of a single forward pass — Laya from a bidirectional encoder, Decider from the logits of lettered option tokens at a dedicated answer slot in the prompt.

That is where the resemblance stops. Laya is two small encoders behind a language router, which is what buys it a 512-token English window and a 1,024-token multilingual one at a 421M and 322M parameter count. Decider keeps a generative backbone and adds a readout on top: decider-2b is a supervised fine-tune of Qwen3.5-2B-Base followed by a calibration-aware reinforcement pass on live browser tasks and exact games, while decider-35b-a3b freezes the routed experts and trains block matrices with Muon. The practical consequence is that Decider inherits a language model's world knowledge and Laya does not. The other consequence is that Decider inherits a language model's footprint.

Mapika's own documentation puts decider-2b at 18ms median per decision on a B300 in bf16, batch of one, no CUDA graphs or compilation, and decider-35b-a3b at 41ms on the same setup. On a GH200 with support-ticket contexts of roughly 230 tokens and three to five typed questions, the same project reports 49ms eager, 4.0ms with CUDA graphs and torch.compile, and about 1,370 decisions per second at batch 32. Those are vendor-published figures from the project's own write-up, not an independent measurement. Laya's headline number is likewise vendor-published: 32.8ms p50 per decision on a Tesla T4, and 7.2ms per question at batch size 10.

The calibration question, which the two projects answer on different scales

Calibration is the number that matters most for a decision model, because the whole point of returning a probability is that someone downstream will set a threshold on it. This is also where comparing Laya and Decider directly will mislead you.

Laya ships with an expected calibration error of 0.466 on its own model card, and the card states plainly that refitting a temperature per question type moves that to 0.081. That is an unusually honest disclosure, and it also means the shipped checkpoint is not the calibrated artifact. The number you get out of the box is the 0.466.

Decider reports on a different instrument entirely. The Decision Index — an open leaderboard that ran every open reproduction of Jev over 132,422 requests — places decider-35b-a3b fourth overall at 54.3 behind Jev's 59.5, and reports it as the best-calibrated of the 32 entries with a calibration error of 3.1 points and 0.4% wrong answers at 95%+ stated confidence. decider-2b reports 8.8 points and 0.9%. Those are leaderboard-published numbers, and 3.1 points on the Index's ten-bin ECE is not the same measurement as Laya's 0.466 on its own eval. Putting them side by side in a table would be an apples-to-oranges error dressed as rigor. What you can say is that Decider's author chose to be measured on a third-party leaderboard and Laya's author chose to publish its weakest calibration number itself; neither has been audited by the other's harness.

Where each one wins, dimension by dimension

• Backbone — Laya: ModernBERT-large 421M encoder, bidirectional. Decider: Qwen3.5 generative bases, 0.8B to 35B-A3B.

• Languages — Laya: 100+ via a 322M multilingual checkpoint behind a router. Decider: English only, stated as a limitation.

• Context window — Laya: 512 tokens English, 1,024 multilingual. Decider: inputs up to 32k accepted, trained to 16k on the v6 generation, probed to 30k.

• Option-set ceiling — Laya: degrades sharply past roughly 20 options, 0.425 on Banking77 against Jev's 0.870. Decider: Choice over 2 to 255 named options, Score over 2 to 10 described levels.

• Zero-shot accuracy — Laya: 0.362 on the typed-decisions benchmark, below the 0.461 majority-class baseline. Decider: not published as a zero-shot number; the project reports task-specific results instead.

• Calibration — Laya: ECE 0.466 as shipped, 0.081 after per-question-type temperature refitting. Decider: 3.1 points on the Decision Index for the 35B, best of 32 entries.

• Reasoning — Laya: none, by construction. Decider: none, stated explicitly — it is a pattern-matching readout, not a reasoner.

• Licence — Apache 2.0 for both.

One more Decider detail worth knowing before you pick it: the project warns that picking one record out of a long JSON array by position is a weak case, and recommends addressing records by key. That is the kind of limitation you only learn by running it.

What it costs you to run either one

Laya's cost profile is a fine-tuning project. The model is small enough to run on a laptop CPU for low-throughput work, but the shipped English checkpoint's zero-shot score sits below the trivial baseline, which means adopting Laya is adopting the job of building a labelled set, fine-tuning, and refitting temperature per question type. The reward is that once you have done it, the artifact is 421M parameters and answers in tens of milliseconds on a T4. Convai's own fine-tuned laya-typed-decisions checkpoint reaches 0.766 on the benchmark's training split — a number that says more about fine-tuning than about the base model, and the card says so.

Decider's cost profile is a serving decision. You are choosing how much GPU to rent, and the family gives you a genuine dial: 18ms on a 2B versus 41ms on a 35B-A3B, with the larger model buying knowledge and reasoning headroom on GPQA, GSM8K, CRUXEval and MMLU that the small ones do not have. If your task is narrow and your labels are fixed, decider-2b is the cheaper machine. If your task needs the model to know things, you pay for the mixture.

Where OrcaRouter fits — and where it does not

Neither Laya nor Decider is a hosted model on OrcaRouter. You download the weights and run them yourself, and nothing here changes that. What does change is the other half of the pattern. A typed decision model is almost never the whole application: something has to read the ticket, summarise the thread, or draft the reply the decision gates. That half is a generative call, and it is the half OrcaRouter is built for — 200+ models behind one OpenAI-compatible key at provider list price passed through with 0% markup, so a vendor price cut lands on your bill the same day rather than at the next contract renewal. If you are fine-tuning a Laya checkpoint against a frontier model's outputs, or routing between decider-2b for triage and a large model for the hard 4%, keeping the generative side on one endpoint means the decision side and the generation side do not need two contracts and two SDKs. Automatic failover covers the case where the big model is the part that goes down.

Which one to pick

Pick Laya if your inputs are multilingual, your labels are few, your latency budget is tens of milliseconds on modest hardware, and you are prepared to fine-tune — because you will have to. Pick Decider if your inputs are English, you need the model to carry some world knowledge into the decision, and you would rather choose a model size than run a training pipeline. If your option sets run past twenty labels, read Laya's Banking77 figure before you commit; if your inputs are long JSON documents you address by position, read Decider's stated limitation before you commit.

The comparison that would actually settle this — both models on byte-identical inputs, same prompts, same option ordering, same threshold sweep — does not exist yet. Until it does, the honest position is that Laya has the better cost curve and Decider has the better calibration evidence, and that both are early enough that the eval you build on your own data will be worth more than either project's published numbers.