Laya vs Jev: Choosing a System 1 Decision Engine
Jev made System 1 a function call. Laya made it open weights. A practical comparison — same Choice/Score/Noul shape, different tradeoffs — and how I'd choose.
Most production AI features aren't chat. They're decisions buried in code: route this ticket, score this lead, gate this prompt, escalate when confidence is low.
TypeSafe's Jev made that interface public: unstructured state in, typed Choice / Score / Noul answers out, with calibrated probabilities, in roughly 70–500ms. I walked through the shape here: Getting Started with Jev.
Days later, an open-weights answer showed up. Laya (Convai Innovations) is a non-autoregressive System 1 decision engine you can pip install, host yourself under Apache 2.0, and point at the same class of questions, including a Jev-compatible POST /v1/systemone server if you already have TypeSafe-shaped clients.
This post is a practical Laya vs Jev read for operators: what they share, where the numbers diverge, and how I'd choose.
Same job, different delivery
Both refuse to write prose. You send a state (ticket, email, JSON) plus typed questions; you get probabilities you can branch on.
| Primitive | What you get |
|---|---|
| Choice | One option from a dictionary you define + full probability mass |
| Score | Ordinal rubric (e.g. urgency 0–3) + confidence |
| Noul | Yes/no-ish with calibrated P(true) |
That shared shape matters more than the brand fight. Put either behind a thin interface so you can swap when the next checkpoint ships.
Head-to-head comparison
Numbers below mix project-published Laya figures, third-party published Jev latency, and independent write-ups (Flowtivity, Hugging Face model card). They were not all measured in one lab run. Treat them as directional, then benchmark on your tickets.
| Laya (open) | Jev (managed) | |
|---|---|---|
| Who | Convai Innovations / Nandakishor Mukkunnoth | TypeSafe AI |
| Access | Apache 2.0 weights + pip install laya |
Hosted API (api.typesafe.ai) |
| Cost | $0 / token (you pay GPU/CPU) | ~$0.042 / MTok input; free output tokens |
| Latency (directional) | ~33 ms / question on T4 (routed multilingual); CPU warm can be hundreds of ms to tens of seconds on weak boxes | ~70–500 ms (TypeSafe); third-party p50 often cited ~236–276 ms |
| Languages | Router + multilingual checkpoint; ~45/51 languages usable (>3× random) on MASSIVE-style sweeps | No published multilingual benchmark I've seen |
| Zero-shot vs specialized | Base English ~0.36 on typed-decisions; fine-tuned specialist 0.766 | Published hard-label ~0.727 on that suite; zero-shot story is "managed and ready" |
| Wide option sets | Degrades past ~20 options at default token budgets (Banking77 ~0.425) | Stronger on high-cardinality choice (Banking77-class ~0.870 on published cuts) |
| Calibration | Advertised ECE after per-question temperature refit on your data; raw ships over-confident | Better out-of-box soft matching / raw calibration in some third-party reads |
| Context | English root 512 tokens; multilingual up to 1k default / 8k with max_len |
Managed API context (follow current docs) |
| Ops model | You own deploy, preload, fine-tune, audit trail | Waitlist/API key, TypeSafe runs the model |
Two honest sentences from the Laya card that should be on every slide:
"Laya is a fast base to specialise, not a zero-shot decision engine."
The 0.766 accuracy belongs to a checkpoint fine-tuned on that benchmark's training split. The base sits near chance / below majority class on the same suite.
How Laya is put together
Three checkpoints, one Router that picks before the forward pass (script/language detection in <1 ms; important because a confident English model on Khmer can score 0.000 accuracy at ~0.95 confidence):
| Checkpoint | Backbone | Params | Best at |
|---|---|---|---|
laya (English) |
ModernBERT-large | ~421M | English triage, guardrails, email |
laya-multilingual |
mmBERT-base | ~322M | 100+ languages; ~2.2× faster in published batch tables |
laya-typed-decisions |
ModernBERT-large | ~421M | Specialist workflows after fine-tune (~0.766 on that suite) |
Training story matches the System One pitch: RLCD, reinforcement learning against strictly proper scoring rules so honest probabilities maximize reward. Architecture is encoder + decision head (option markers at [MASK] tokens), not an autoregressive chat model.
Ops notes that matter in production:
Router(preload=True)avoids multi-second cold swaps when traffic flips languageslaya-servecan speak Jev's/v1/systemoneshape for client reuse- GPU (T4-class) for interactive paths. CPU-only VPS tests (Flowtivity) show warm predicts that are fine for batch, not for a hot request path on a thin box
The Doom lesson that actually transfers
Christian Graham's Medium piece taught Laya to play Doom, not as a gimmick, but as a stress test for messy, half-visible state.
What transferred to product work:
- Ask focused questions. "Should I shoot?" beat dumping shoot into a giant choice list it always lost
- Bolt simple overrides for known failure modes (no ammo, spinning in corners) and log every override
- Calibration + policy beats vibes. The model proposes; your rules and confidence gates decide
That's the same staffing pattern I use with agents: decide cheap, gate hard, write rarely.
How I'd choose
| If you need… | Start with… | Why |
|---|---|---|
| Air-gapped / customer data never leaves your VPC | Laya | Full weights, audit, on-prem |
| Multilingual traffic without per-token bills | Laya | Router + multilingual checkpoint |
| High-volume binary / few-option gates inside a request path | Laya (on GPU) | Sub-50ms directional latency when hot |
| You can label a few thousand examples + fine-tune | Laya | Where the accuracy jump actually lives |
| Zero setup and strong zero-shot today | Jev | Managed System One API |
| 50+ options in one Choice without tuning budgets | Jev | Published edge on high-cardinality sets |
| Soft distribution matching out of the box | Jev (often) | Soft-acc / raw calibration reads favor it in some reviews |
| Prose, explanations, multi-step reasoning | Neither. Keep an LLM | Both are decision engines, not writers |
A useful cost sanity check from the field write-ups: at tens of thousands of decisions/month, Jev's metered bill is already small versus frontier chat routing. Laya zeroes the token line if a GPU is already next to your LLM stack, so the real decision is ops ownership vs managed convenience, not a CFO fire drill.
Five-minute Laya start
pip install laya
from laya import Router
router = Router(preload=True) # keep checkpoints hot
state = "Hi, we were billed twice for March. Please refund the duplicate today or we will cancel."
questions = {
"department": {
"type": "choice",
"instructions": "Which department should handle this?",
"criteria": {
"billing": "invoices, payments, refunds",
"technical": "bugs, outages, system errors",
"other": "everything else",
},
},
"urgency": {
"type": "score",
"instructions": "How urgent is this?",
"criteria": ["not urgent", "soon", "blocking"],
},
"churn_risk": {
"type": "noul",
"instructions": "Does the user threaten to cancel or leave?",
},
}
result = router.predict(state, questions)
print(result["answers"]["department"]["choice"])
print(result["answers"]["churn_risk"]["noul"])
print(result["routing"]["model"])
Then, before any threshold hits production: label your own distribution, fine-tune (the project ships a free Kaggle notebook path), fit temperatures per question type, and log confidence vs outcomes weekly. Open weights don't remove that homework. They make it possible.
Bottom line for builders
Jev established the category: treat System 1 as a function call, not a chat window. Laya showed that category isn't locked behind a closed API: same Choice / Score / Noul shape, open weights, multilingual routing, and a fine-tune path you own.
Ship the decision layer behind a thin interface so either model is swappable. Benchmark on your own tickets before you trust a published table. Keep an LLM for prose. Promote Laya or Jev past read-and-route only after confidence thresholds and failure modes hold up on your traffic.
References
Related Resources
Support the open source behind this post
This post draws on open source work I maintain. You can support it on GitHub Sponsors.
Enjoyed this? Let's work together.
I help companies turn AI strategy into shipped, revenue-generating products.