Comparison · 12 minute read

Laya vs Jev

They expose the same decision shape—state in, typed probabilities out—but make opposite product choices. Laya gives you weights and control. Jev gives you a managed frontier service.

evidence labelled by sourceupdated 22 Sep 2026
Bottom line. Choose Laya for local control, privacy and domain specialization. Choose Jev for managed operation, larger option sets and stronger evidence of out-of-box behavior. Neither is a universal replacement for the other.

The same interface, not the same model

Both systems answer choice, score and noul questions against a state. They return probabilities that application code can threshold, combine or escalate. Neither is designed to draft prose.

Jev is TypeSafe AI’s closed, hosted System One model. Laya is an Apache-2.0 family built around ModernBERT-large and mmBERT-base encoders with a decision head. Jev’s parameter count and model architecture are not public, so claims that Laya “reproduces the Jev architecture” go beyond the evidence available.

Feature comparison

DimensionLayaJev
AccessDownloadable weights and Python packageHosted API in early access
LicenseApache 2.0Commercial service terms
Known architecture322M mmBERT-base or 421M ModernBERT-large plus decision headNot publicly disclosed
DeploymentLocal, private cloud or your own serverTypeSafe-managed endpoint
CustomizationWeights and fine-tuning workflow availableNo public weight access
Input priceNo API fee; compute and operations still cost money$0.042 per million input tokens, per TypeSafe
Maximum choice cardinalityDefault head budget degrades on large label setsUp to 255 options, with a two-stage path for high cardinality
Language storyDedicated multilingual checkpoint; 51-language public sweepNo comparable public multilingual benchmark found
Cold start / networkCheckpoint loading can take seconds; warm inference is localNo local load; every call pays network and service latency

Accuracy: the headline is not the whole story

Laya’s repository reports that its workflow-specific checkpoint reaches 0.766 accuracy on 2,000 typed decisions, compared with a published Jev result of 0.727. It also reports leads on AG News and DAIR Emotion. These are useful signals, not a universal leaderboard.

The same report states that the two base Laya checkpoints score about 0.34–0.36 on typed-decisions, below a 0.461 majority-class baseline. The 0.766 result comes from a checkpoint fine-tuned on the benchmark’s training split. In other words: the evidence favors Laya as a base to specialize, not as a universally strong zero-shot judge.

Jev has a clear published lead on Banking77: 0.870 versus 0.425 for Laya at its default head budget. Laya’s options share a fixed prompt budget, leaving only a few tokens per label when dozens are supplied. Increasing the budget, shortlisting or using a hierarchy may help, but those are additional engineering choices.

Latency: local inference and API latency are different measurements

The Laya repository reports roughly 33–40ms for one question on a Tesla T4 and faster per-question throughput when batching. Independent Apple Silicon testing has measured a warm MLX call around 7.6ms. Jev measurements commonly include the network round trip: roughly 236–276ms in references collected by the Laya project, and 588ms in one small Chinese support-ticket test.

That makes Laya attractive for real-time local workloads, but it is not an architecture-only speed comparison. A fair operational comparison must include Laya model loading, GPU or device cost, concurrency and your actual distance to Jev’s endpoint.

Calibration: validate before automating

Laya is trained with rewards based on proper scoring rules, but training objective does not guarantee calibration on every new domain. The project reports that shipped base checkpoints are over-confident and that held-out temperature fitting substantially reduces expected calibration error.

An independent 40-case Chinese ticket test found examples where Laya remained highly confident while choosing the wrong label. The sample is far too small for broad conclusions, but it reinforces the correct deployment practice: measure reliability curves on your own labelled traffic before setting automation thresholds.

Which should you choose?

Prefer Laya when

  • inputs cannot leave your environment;
  • you can collect labelled domain examples;
  • low warm latency matters;
  • you want to inspect, adapt or redistribute the runtime;
  • your choice sets are usually modest.

Prefer Jev when

  • you want an API rather than model infrastructure;
  • you need large option sets out of the box;
  • the task must work before you have fine-tuning data;
  • managed versioning is preferable;
  • sending state to a hosted service is acceptable.

A practical third option: a cascade

For high-volume workloads, run Laya first and send low-confidence or out-of-scope cases to Jev or a larger LLM. This can keep obvious decisions local while preserving a stronger fallback. The threshold must be learned from a frozen validation set—not chosen because 0.8 “sounds confident.”

STEP 01

Run Laya locally

Return a typed distribution without a network call.

STEP 02

Check a validated gate

Accept only task types and confidence regions that held up on your labelled data.

STEP 03

Escalate the rest

Send ambiguous or unsupported cases to Jev, an LLM or a human reviewer.

Primary sources: Laya repository, Laya benchmark report, TypeSafe’s Jev announcement. Independent small-sample evidence: laya-jev-lab. This independent guide is not affiliated with or endorsed by either project.