Jev vs Tev1 vs Laya: The 2026 Guide to AI Decision Models

Quick answer: Jev is the hosted reference product for typed, probabilistic decisions; Tev1 is an experimental Hugging Face checkpoint that fine-tunes Qwen to select one option; Laya and Kev are open-weight alternatives with broader typed-decision interfaces; OpenJev and several smaller projects make local or self-hosted deployment possible. There is no universal winner. Pick by task fit, measured accuracy on your own cases, privacy, option count, confidence calibration, serving cost and operational control—not by the largest benchmark number.

This guide compares the projects and model families available on September 26, 2026. It separates project-reported results from a small same-input community benchmark, and links the Hugging Face model cards so readers can inspect the actual checkpoints and license terms. New model cards and revisions can appear quickly; verify the exact revision before deployment.

What is a System One or decision model?

A conventional language model generates a string. Even when asked for JSON, it predicts output tokens in sequence; application code still has to parse the result, validate it, and decide what to do when the response is malformed or uncertain.

A decision model takes a piece of state—such as a support ticket, agent trace, invoice or current web page—and one or more questions whose answer types are defined in advance. Common primitives are:

• Choice: select one option and provide a distribution over the choices.
• Noul: answer a yes/no question as a probability.
• Score: rate a state on a defined scale.

The model supplies a judgment; the application owns the workflow. That is useful when software needs a bounded answer, not a paragraph. It does not mean the model cannot be wrong: a type-safe answer can still select the wrong label, misunderstand negation, or report confidence that is poorly calibrated for your domain.

The strongest design is usually not “replace the agent with a tiny model.” It is a fast decision layer inside a harness: use code for deterministic rules, a decision model for fuzzy bounded judgments, and a general LLM or person for ambiguous work. For the broader design, see how to build a better agent harness.

At a glance: Jev, Tev1, Laya, Kev and OpenJev

“API-compatible” describes a request/response shape; it does not certify equal behavior, benchmark parity or support from the original vendor. Model weights, server code, base models and datasets may each have different licenses. Check the specific card and upstream terms before commercial use.

Jev: the hosted reference point

Jev is TypeSafe AI’s first public System One model. Its API lets an application send a state and typed questions, then receive machine-readable answers with probabilities. The official API documentation lists the POST /v1/systemone endpoint and Choice, Noul and Score answer schemas. TypeSafe’s launch article explains the product’s parallel decision approach and publishes its own latency, cost and workflow comparisons.

Why teams may choose it: the application can try the interface without downloading weights or operating a model server. Multiple questions can be sent against shared context, and the product returns answers in a defined shape. The trade-off is a hosted dependency: account availability, network latency, data policy, service changes and current pricing matter. TypeSafe’s published figures are vendor-reported, and the article itself identifies evaluation choices and possible sources of bias. Treat them as useful product evidence, not independent proof that Jev wins every workflow.

Good fit: a low-risk ticket-routing or triage pilot where the team can send representative examples, measure outcomes, and keep an explicit review path. Poor fit: state that must never leave a private environment, or high-impact actions that have no validation, audit trail or human escalation.

Courtesy: viewport screenshot of TypeSafe’s API documentation, captured with Trawl for this comparison. Documentation and product marks belong to TypeSafe AI.

Tev1: an accessible experiment, not “open Jev”

Tev1-4B-experimental is a Jev-inspired Qwen3.5-4B fine-tune published by Together AI. Its model card describes a narrow format: provide state, question and 2–24 labeled options, then ask for a single answer letter. The GitHub recipe uses ordinary LoRA supervised fine-tuning and Qwen’s existing language-model output head. That distinction matters: the public recipe is not evidence that Tev1 reproduces Jev’s full native parallel Choice/Score/Noul interface or its calibration behavior.

The repository currently reports 37,840 unique training examples, 4,568 validation examples, and saved results of 880/1,000 main decisions plus 300/300 policy-transfer decisions. Its maintainers explicitly say those are reused development benchmarks, not untouched final tests. Together’s earlier training walkthrough advertises a roughly $17 example run; that is a dated provider-specific training estimate, not a guaranteed total cost for your data, endpoint, storage or inference.

The practical upside is inspectability: the checkpoint is on Hugging Face, and the data-building/training recipe is public. But “open weights” is not the same as “same architecture,” “same quality,” or automatically permissive commercial use. Check the current model card’s license and usage section and Qwen base-model terms before shipping. Also build output validation: a language-model head can emit extra text or the wrong option unless the runtime and application constrain and check it.

Choose Tev1 for: a bounded experiment that needs one of a small number of labels and where a Qwen-based checkpoint is convenient. Do not choose it just because its name resembles Jev: benchmark it on your own prompts, labels, negation, long inputs and edge cases first.

Courtesy: viewport screenshot of Together’s Tev1 repository, captured with Trawl. Repository content and marks belong to their respective owners.

Laya: open weights, with a critical fine-tuning caveat

Laya is an Apache-2.0 non-autoregressive decision-model project. Its Hugging Face family includes the English checkpoint, multilingual checkpoint, and typed-decisions checkpoint. The project documents a Jev-shaped interface, one-pass decisions, CPU/GPU serving and optional MCP integration for agents.

The model-family table lists a 421M ModernBERT-large English checkpoint, a 322M mmBERT-base multilingual checkpoint, and a 421M fine-tuned typed-decisions checkpoint. The Laya team’s current benchmark says the base checkpoints are near chance on its typed-decisions suite, while its fine-tuned checkpoint scores higher on that suite. The same report also shows why a single headline accuracy is insufficient: Jev has stronger soft-distribution agreement on the cited comparison, raw calibration differs before fitting, and Laya’s score on a high-cardinality Banking77 test drops sharply at default option-token limits. Those figures are project-published and not a universal cross-domain verdict.

This is the main lesson for Laya: do not download the general checkpoint, send business-critical traffic, and assume the impressive fine-tuned number transfers. Select the correct checkpoint, verify the context/option budget, fit calibration on held-out examples, and evaluate your own workflow. For multilingual traffic, test each language separately; the project itself documents uneven per-language results.

Courtesy: viewport screenshot of the Laya repository, captured with Trawl. Project content and marks belong to their respective owners.

Kev: self-hosted Qwen-based models with a built-in training path

Kev is an Apache-2.0 family built on Qwen3.5 and Qwen3.8, with published Hugging Face checkpoints and code to train, evaluate and serve a custom model. The project documents four sizes—0.8B, 4B, 9B and 27B—and says its serving API matches TypeSafe’s public System One request shape. The 0.8B option is aimed at smaller hardware; the largest checkpoint calls for a substantial GPU. Use the model cards for actual memory and runtime requirements rather than parameter count alone.

Kev’s maintainers publish results on new and trained sources, and explicitly warn that Jev has only been run on some of their development sets, so this is not a controlled architecture comparison. That transparency is useful: it makes Kev a strong candidate for a self-hosted, train-on-your-own-labels evaluation, but the reported scores remain the author’s results. If local hardware is the deciding factor, compare the card’s quantized format and memory needs with our local model fit tool and AI model directory.

OpenJev and smaller local projects

OpenJev is a self-hostable server around open models with a Jev-shaped interface. Its Hugging Face organization publishes text and screenshot-oriented variants; the current model page describes up to 52 options and an Apple-Silicon MLX quantized build. The GitHub project’s model table also references other people’s models—Laya, Verdict, CLM and JevK5—so do not assume those weights are owned or licensed by OpenJev. Some OpenJev model-card variants are marked CC BY-NC 4.0, which is non-commercial: verify each exact variant before business use.

Another small project, system-one by mpuig, is an MLX-first learning and local-serving project with Qwen and MiniCPM-based checkpoints. Its authors label the published 24-question comparison as an illustration, not a benchmark. It is valuable for understanding local adapters, calibration files and request compatibility, but the small diagnostic should not be treated as evidence of production parity.

More Hugging Face decision-model cards worth knowing

• JevK5 is an Apache-2.0 Qwen3.5-4B-based typed-decision model. It reads answer-letter probabilities with a calibration temperature rather than generating a free-form explanation. Its GGUF builds target llama.cpp-compatible GPUs and CPUs. Treat its own held-out/task scores as author-reported until you reproduce them on your workload.
• CLM-v0.1-8B takes a different route: small state/action projection heads score candidate actions against an encoded state, using a Qwen3-8B encoder. The model card says its scores are relative to the candidate set, and warns that the strongest agent-verifier results require fine-tuned heads. It is a particularly interesting fit for ranking a set of tool actions, not a drop-in general-purpose text model.
• Von is an Apache-2.0, 395M ModernBERT-large option-scoring model. Its compact size makes it worth testing for CPU or edge serving, but small parameter count does not establish accuracy or calibration on your labels.
• Plek-1 is a 0.8B Jev-style checkpoint whose model card describes non-autoregressive choice scoring. Its long-context and calibration claims are project claims; verify them against a pinned revision and your own data before relying on them.
• Decision-4B is a Qwen3.5-4B LoRA adapter with a separate GGUF route for local runtimes. Its card describes a 2,800-case held-out evaluation. It is an option to test when laptop deployment matters, with the usual requirement to inspect the adapter/base-model license and reproduce quality locally.
• AutoTrust JEV-9B and JEV-27B explore a combined System One decision path and a System Two generative path. This is architecturally different from a small encoder: it can keep a familiar Qwen-scale backbone, at a much larger serving footprint. The benchmark results and “indistinguishable from Jev” wording on the cards are author-published claims, not independent certification.

These are not all equally mature, and the word “Jev” in a model ID is not evidence of affiliation. The Hugging Face System One model search is a live discovery page, but results can include unrelated tasks, forks and user uploads. Prefer each project owner’s canonical card and pinned revision.

What do the benchmarks actually say?

The comparison most worth reading is a community same-input benchmark. It sent identical inputs to Jev 1.13.0, Laya 0.3.11 and a Qwen constrained-decoding baseline. On its 952-case evaluation split (1,240 scored decisions), it reports Jev at 0.9065 accuracy, Laya at 0.6863 and the baseline at 0.6048. Its authors also disclose that one human reviewer checked an AI-drafted label set, with no second independent reviewer or adjudication. This is a more controlled within that experiment comparison than comparing unrelated vendor tables—but the dataset and review procedure still limit what we can generalize.

So why does Laya’s own fine-tuned typed-decisions report show 0.766 against Jev’s published 0.727? The prompts/checkpoints and evaluation sets are different, and the report itself says its Jev figures are third-party published rather than measured in the same run. Neither table cancels the other. Together, they show that checkpoint, training, prompt construction, label cardinality, hardware, latency measurement and ground-truth quality can change the conclusion.

Also separate these metrics:

• Accuracy: how often the top answer matches the label.
• Calibration: whether a stated 0.8 confidence is correct about 80% of the time on comparable cases.
• Brier score / log loss: how good the full probability distribution is, penalizing confident misses.
• Latency: clarify whether it is model-only, API round trip, batch latency or end-to-end action time.
• Cost per correct outcome: better than cost per call when models differ in errors and retries.

The benchmark question is not “which model has the biggest percentage?” It is “which candidate meets our minimum quality and risk thresholds on the exact decisions we plan to automate?”

Decision-model API shape: a small example

The following is the general shape used by Jev-compatible implementations; exact fields, auth and available model names depend on the selected server. Never treat a sample response as a guarantee of equivalent behavior.

1{
2  "model": "your-selected-model",
3  "state": "Customer says the invoice contains a duplicate charge and asks for a refund.",
4  "questions": {
5    "team": {
6      "type": "choice",
7      "instructions": "Which team should handle this?",
8      "criteria": {
9        "billing": "Charges, invoices, refunds",
10        "technical": "Product defects or access problems",
11        "other": "Anything else"
12      }
13    },
14    "urgent": {
15      "type": "noul",
16      "instructions": "Does this need a response today?"
17    },
18    "sentiment": {
19      "type": "score",
20      "instructions": "How dissatisfied is the customer?",
21      "criteria": ["calm", "concerned", "upset", "angry"]
22    }
23  }
24}

Notice what is missing: the model is not asked to write a reply, issue a refund, or decide policy. Code checks the output, applies business rules, and decides whether a person must review it. This decomposition is usually safer and easier to measure than putting the entire task into one prompt.

Which one should you choose?

Choose Jev when…

You want a managed API and the typed decision interface is a fit; your data policy permits a hosted service; and you can evaluate the API’s quality, latency and cost against a baseline. Start with a shadow run before allowing any consequential action.

Choose Tev1 when…

You want to inspect or experiment with a Qwen3.5-based, fixed-choice fine-tune and 2–24 options are enough. Treat it as experimental, validate letter-to-label mapping and malformed outputs, and check the card’s current license. It is not a one-for-one replacement for Jev’s full set of decision primitives.

Choose Laya when…

You need Apache-2.0 open weights, a local/self-hosted route, multilingual options, or a fine-tuning and evaluation workflow. Choose the right checkpoint and do not rely on confidence until calibration is measured on held-out domain data.

Choose Kev when…

You want a family of self-hostable Qwen-based checkpoints and a path to fine-tune a model on your own labeled data. Pick a size your hardware can actually serve, and reproduce the benchmark on your dataset rather than transferring the project’s scores to your use case.

Choose OpenJev or a small local project when…

You need an open server interface, local experimentation, or image/screenshot decisions. Confirm the exact model behind the endpoint and read that checkpoint’s license carefully; a server’s open-source license does not automatically relicense every model it serves.

Choose a regular classifier or rules when…

Your categories barely change, labeled data is available, and the task is simple. A calibrated logistic regression, gradient-boosted model, embeddings-plus-classifier, or plain deterministic rule may be easier to audit and cheaper to operate. A System One model is useful when the decision needs flexible language understanding that rules alone do not handle well.

A safe evaluation plan you can run this week

1. Freeze the job. Write down the state fields, exact question, allowed labels, and action each answer could trigger.
2. Create a held-out set. Gather real, consented examples with human-reviewed labels. Include negation, missing context, long inputs, rare labels, multilingual examples and adversarial text inside the state.
3. Run a baseline. Compare the current prompt/LLM, a simple classifier or rules, and each viable decision model. Use byte-identical inputs and pinned model revisions.
4. Measure distributions, not only winners. Record accuracy, per-label recall, calibration (ECE plus Brier or log loss), abstention coverage, p50/p95 end-to-end latency, and cost per correct result.
5. Tune a review threshold. If confidence is below the threshold, labels conflict, or the action has high impact, abstain and route to a person or a slower model. A probability is a signal—not authorization.
6. Shadow first. Log what the system would have done while existing human policy remains in control. Inspect false positives and misses before enabling even reversible automation.
7. Version the whole decision. Store the model ID/revision, prompt/question schema, label definitions, calibration artifact, policy version and outcome. Re-run the held-out suite after any change.

For private inference and hardware trade-offs, use the local AI model fit tool. To explore the rest of the Hugging Face and provider catalog, open the AI model directory; for the software that runs these models inside developer workflows, browse the coding-agent directory.

Hugging Face checkpoint shortlist

These are the canonical cards linked for the projects above—not every quantization or fork. We have added these canonical Hugging Face IDs to our AI model directory, including the ones that did not appear in the regular trending/download snapshots. Each opens a stable individual model record; use the upstream model card as the source of truth for files, revisions and license:

Jev itself is a hosted TypeSafe service in the reviewed sources, not a Hugging Face weight download. Tev1, Laya, Kev and OpenJev are distinct projects with different architectures and licenses; “Jev-like” or API-compatible does not imply equivalence or TypeSafe endorsement.

Frequently asked questions

Is Tev1 open source?

The training code/recipe is public and an experimental checkpoint is hosted on Hugging Face. The code repository’s MIT license does not automatically set the weight license. Check the model card and underlying Qwen terms before redistributing or using the checkpoint commercially.

Is Tev1 the same model as Jev?

No. Tev1 is a Qwen3.5-4B fine-tune using a conventional language-model output head and a fixed-choice prompt. Jev is TypeSafe’s hosted product with a typed Choice/Score/Noul API and its own model/training approach.

Which System One model is best for running locally?

There is no hardware-independent answer. Start with Laya for compact encoder-style checkpoints, a small Kev or system-one checkpoint for Qwen-based local experiments, or a compatible OpenJev variant when the required model and license fit. Measure memory, throughput and accuracy on your actual device; the hardware fit tool estimates model capacity, not a guaranteed tokens-per-second score.

Can a decision model safely approve payments or block accounts by itself?

Do not infer that from a confidence score. Start in shadow mode, define false-positive costs, require a human for high-impact or low-confidence cases, and retain a deterministic validator and appeal path. Evaluate the complete action workflow, not just the model response.

Are “zero hallucinations” and “calibrated confidence” guaranteed?

A constrained output schema can prevent malformed answer types, but it cannot guarantee the selected answer is semantically correct. Calibration is empirical and can drift across domains, languages, prompts and model revisions. Re-measure it on held-out production-like cases.

Bottom line

Jev is the simplest hosted reference to evaluate; Tev1 is a small, useful fixed-choice experiment; Laya and Kev make open-weight specialization and self-hosting more practical; OpenJev and smaller projects broaden local and multimodal experimentation. The best production decision system is the one that passes your held-out tests, stays within your privacy and license rules, and knows when not to act.

Sources and image references

• TypeSafe Jev launch and product claims
• TypeSafe System One API documentation
• Together AI Tev1 repository and evaluation notes
• Tev1 Hugging Face model card
• Together AI training walkthrough
• Laya repository, checkpoints, benchmarks and limitations
• Laya typed-decisions Hugging Face card
• Kev repository and benchmark methodology
• Kev-4B Hugging Face card
• OpenJev repository and model table
• OpenJev Hugging Face organization
• Same-input community benchmark and limitations
• Jev edge-orchestration research preprint
• system-one MLX learning project