If you use Jev to classify requests, what would change if you used LAYA for that task and ran it yourself?
LAYA publishes code and model weights under Apache 2.0. Its interface accepts application state and typed questions, with outputs for choosing an option, rating against a scale and estimating whether a condition holds. That puts it in the same area as Jev, TypeSafe’s model for structured decisions.
This article reviews public documentation and source checked on 22 September 2026. It does not report a head-to-head model evaluation. The distinction matters here because the deployment choice is already clear, while the performance choice needs more evidence.
What changes when you run LAYA locally
With Jev, your application sends a request to TypeSafe’s hosted API. With LAYA, you can load published weights into a process you operate. The model repository contains English, multilingual and a specialised typed-decisions checkpoint. A checkpoint is a saved set of model weights; choosing one changes what runs.
For a team building a support tool, local inference could mean evaluating tickets inside its own infrastructure. It also means someone has to provision compute, load models, manage memory and observe failures. Those responsibilities belong in the comparison.
I would separate three questions before choosing:
- Where may the data go? Map the actual request path, including downloads, logs and any services your application calls. Local inference alone does not prove that the whole application keeps data private.
- Who operates the model? Include maintenance and spare capacity in a self-hosted estimate. Removing a hosted API bill does not remove operating costs.
- How will you adapt it? LAYA provides a fine-tuning workflow. TypeSafe currently documents shared Jev weights across accounts, with behaviour shaped through state, instructions and criteria. See LAYA’s training notebook and TypeSafe’s model guidance.
Read the benchmark with its conditions attached
LAYA’s benchmark report says its Jev figures come from third-party experiments with different prompts and sample sizes. It also distinguishes the specialised checkpoint from weaker base-model results on typed-decisions, and reports overconfidence in the shipped base checkpoints.
That makes the report useful for deciding what to test. It cannot establish which model will perform better on your workload.
For a comparison I would trust, both systems would receive the same held-out cases and answer definitions. Record the LAYA checkpoint and machine, the Jev version returned by its API, and client-side conditions such as concurrency and network location. Measure elapsed time until the application has a usable answer. Measure local model loading separately from warm inference. Jev’s internal hardware and cold-start state may be unavailable to you; record those as unknown rather than inferring them from a slow first request.
Correctness needs similar care. A classifier that looks good overall might miss the particular category your business cannot afford to lose. Read the errors by category, language and consequence. My evaluation guide covers how I would organise that work.
The router detail I would check first
There is a useful distinction in LAYA’s router source at the reviewed revision. auto_task_detection defaults to False. Language-based routing remains active. Automatic selection of typed-decisions requires enabling task detection and matching the exact question IDs of a recognised workflow. You can also select the checkpoint explicitly through model or task. A default router should not be assumed to reproduce that checkpoint’s headline result.
For an integration, I would log the chosen checkpoint and the routing reason with each evaluation. That gives you something concrete to inspect when an English case works and a Spanish one takes a different path.
The same source shows a default resident-model limit of one. Alternating between models can therefore require loading them again. Preloading or keeping the required models resident changes that behaviour, at the cost of memory. This is another reason to measure the application under the traffic pattern you expect.
What I would evaluate in English and Spanish
For an application that handles English and Spanish, I would begin with paired support messages: clear requests, short ambiguous messages and mixed-language tickets. A message such as “Me cobraron twice, ¿pueden revisarlo?” is a useful test case because its wording crosses a language boundary. It is an illustrative input, with no model result claimed here.
Keep a separate held-out set for the final check. Use other labelled cases to choose thresholds, and record how often the system sends work to a person. Otherwise, a model can appear safer simply by declining almost everything.
TypeSafe’s confidence documentation describes Choice and Score confidence as a statistic derived from the returned distribution. I would verify the meaning and calibration of each model’s scores before carrying a threshold from one integration to the other. A number of 0.9 in two responses is insufficient evidence of equivalent behaviour.
For an initial pilot, I would let either model suggest a queue while a person retains control of the action. That gives us observable mistakes to learn from before connecting the result to a consequential operation.
LAYA is worth investigating when running and adapting the model yourself would solve a real constraint. Jev remains a candidate when a hosted decision API fits the system. My next step would be a small comparison built around actual bilingual requests, with the deployment conditions recorded beside the results.
Follow the English RSS feed for the next article.
About the author: see my portfolio and my agency, Bimbi Digital.