System 1 AI Goes Open: Jev vs Laya, Laya MLX and Kev

System 1 AI models answer typed questions in a single forward pass: pick one of these options, place this on a rubric, how likely is this to be true. They return probabilities instead of text. TypeSafe AI launched the category commercially with Jev on September 15, 2026, and within a week the open-source world had copied its interface. Laya offered open weights, Laya MLX ran them natively on Apple Silicon in about 10 ms, and Kev shipped a trainable model that speaks Jev's exact API.

The most durable thing to come out of that week is the schema. Several open projects now serve the same /v1/systemone contract, so you can design against the interface and swap models underneath it. Accuracy is where they differ, and the evidence so far says it tracks model size and training data more than architecture.

I covered Jev itself in two earlier posts, what it is and where it pays off in practice. This one is about the open alternatives and what they change for your stack.

What do System 1 and System 2 mean for AI?

TypeSafe took the names from Daniel Kahneman's Thinking, Fast and Slow: System 1 is fast intuition, System 2 is slow deliberation. TypeSafe's launch post argues its System One models can be made more reliable than generative ones, despite the name's association with snap judgments.

In practice:

	System 2 (LLMs)	System 1 (decision models)
Output	Free text, code, JSON you must parse	Typed choice, score or yes/no probability
Generation	Sequential, token by token	Parallel, one forward pass
Latency	Sub-second for small models, 3 to 329 seconds end to end for frontier models	7 to 500 ms, depending on model and hardware
Confidence	Unreliable when asked for it	Returned with every answer
Can't do	Guarantee a valid type	Generate anything you didn't define

You need both. System 1 makes the many small decisions inside a workflow; System 2 handles whatever needs writing or multi-step reasoning.

Jev: the reference point

Jev answers through three primitives: choice, score and noul (TypeSafe's word for a calibrated yes/no). TypeSafe claims 70 to 500 ms per response at $0.042 per million input tokens, with output free, and trains the model with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD). TypeSafe has not published weights or a parameter count.

Access is wider than "early access" suggests. Benchmarkers already reach Jev through OpenRouter's decisions endpoint, and Kev's repo runs comparisons through Vercel AI Gateway.

TypeSafe is candid about its own caveats. Its workflow evals use GPT-6 Astra and Fable 5.1 as the reference answers and were written by its own team. Its 0% type-error figure holds by construction, so Jev can still give a wrong answer that fits the schema. It also says it can't yet prove its pricing isn't subsidized.

Laya: open weights and a prior-art claim

Nandakishor Mukkunnoth, founder of ConvAI Innovations, says he published the same non-autoregressive decision approach in a March 2025 paper. He released Laya as an installable package in the week after Jev's launch, describing TypeSafe's work as uncredited prior art. Nobody has shown Jev reuses his code, and TypeSafe has not responded publicly.

Laya is Apache-2.0. It ships a 421M-parameter English model on ModernBERT-large, a 322M multilingual model covering over 100 languages, and a typed-decisions checkpoint. Mukkunnoth reports 32.8 ms per question on one T4 GPU. His model card warns the model ships overconfident until you refit its temperature, so budget for that step.

Laya MLX: decisions at frame rate on a Mac

Laya MLX is an independent port of Laya to Apple's MLX framework. The whole model runs in MLX, with no PyTorch, no Transformers runtime and no cloud API. On an M3 Max it reports 13.4 ms median for a short English decision and 7.4 ms with the multilingual checkpoint. AlphaSignal adds peak memory under 1 GiB and 395 questions per second batched. A sibling Core ML port reaches about 5 ms on the Neural Engine, capped at 96 tokens.

The port matches upstream PyTorch on 63 of 63 validation questions. That measures fidelity to Laya, and Laya's own accuracy is a separate question (see the benchmark below).

Speed at this level changes where decisions can live. The laya-vs-jev demo runs Chrome's T-Rex game with Laya MLX playing locally beside Jev playing over the network. Per-frame decisions with no API bill and no data leaving the device open up games, desktop agents and privacy-sensitive tools.

Kev: the one you can train

Kev, from Jared Palmer, speaks TypeSafe's System One API, so the official SDK works against a local Kev server with a base URL change. It ships weights, training code and evaluation data.

The first release, Kev-0.5B, added a LoRA adapter and small readout head to Qwen2.5-0.5B. It packs the document and all questions into one sequence, with a mask that lets each question see the document but not the other questions. Its original README, preserved in forks, reported 79.7% micro accuracy against Jev's 81.1% on 720 development questions.

The current family runs on Qwen3.5 at 0.8B, 4B and 9B. On external test sets with published Jev results, the author reports:

• Support ticket routing (900 tickets): Kev-9B 0.952, Jev 0.897
• Ticket tone: Kev-9B 0.911, Jev 0.914
• Authored decisions (144): Kev-9B 0.917, Jev 0.965
• Confident answers when the deciding evidence was removed: Kev-9B 5%, Jev 9%, older Kev-8B 26%

That last line matters most. A model that stays unsure when it should be unsure is one you can automate against, and Kev-9B reports doing that better than Jev on this set. These are self-reported numbers on the author's harness.

Kev's README also flags a weakness: it can't subtract dates reliably. Supplying a precomputed day count lifts Kev-9B from 0.80 to 0.90 on deadline-policy questions, against Jev's 0.93. Compute facts in code before you ask.

What does independent testing show?

The best neutral comparison so far is a 78-case test on an M4 Pro Mac mini. Kev wasn't included.

Model	Size	Micro accuracy	ms per case
Jev*	Undisclosed	0.974	~302
Bonsai 27B (1-bit, no decision head)	27B	0.885	1,682
GLiNER2	486M	0.795	66
Von	395M	0.769	47
Laya	421M	0.590	30

*Jev's column comes from the suite author's run against the hosted API.

Yes/no questions split the field. On refund eligibility and credential-leak detection, the three small models scored between 0.5 and 0.7. On urgency, results ranged from 0.25 (Von) to 1.0 (GLiNER2). Bonsai, a general chat model compressed to about one bit per weight, got all three yes/no tasks right.

The testers note the limits themselves: 8 to 15 cases per task, and results that shift with question phrasing.

What actually drives accuracy?

This section is my inference from the numbers above, which come from different test sets and shouldn't be compared directly.

The pattern points one way. The 400M-class encoders cluster between 0.59 and 0.80. A 27B chat model with no decision head reaches 0.885. Kev-9B, trained on labelled outcomes, reports near-parity with Jev and beats it on some sets. Architecture copied in days, and every model delivered on speed. Accuracy follows backbone capacity plus training on real outcomes.

For builders, that's encouraging. Parity with a funded lab looks reachable at around 9B parameters if you bring your own labelled decisions. The labelled set is the asset that's hard to copy, and every team already has the raw material in its logs.

What should product leaders take from this?

Cost changes what's worth automating. At Jev's listed price, 10 million decisions a month at 1,000 input tokens each costs about $420. The same volume through an LLM at $1 per million input tokens runs about $10,000 before output tokens. Decisions you once batched or skipped become affordable per event.

On-device becomes an option. Laya MLX and Kev run locally, which matters for clients whose data can't leave the device or the building.

Vendor risk becomes manageable. Jev is closed, in early access, with pricing TypeSafe expects to fall but can't guarantee. Because Kev and other projects serve the same schema, you can build on Jev today and keep a tested open fallback behind the same interface.

Which one should you use?

• Jev: you need the best accuracy now across varied tasks, and a hosted dependency is acceptable. Also your evaluation baseline.
• Laya MLX: Mac-based apps, games or local agents where 10 ms and privacy matter more than peak accuracy. Refit calibration first and test yes/no questions hard.
• Kev: you have labelled decisions and want a model you can fine-tune and self-host behind Jev's API.
• None of them: tasks that need written output, explanations or arithmetic. Send those to an LLM.

Conclusion

The System 1 interface became a commodity in a week. Accuracy and calibration didn't, and they now depend on model size and your own labelled data more than on which lab you buy from.

Start with the data. Pull a week of logs, find every LLM call whose output you parse into an enum, boolean or score, and hand-label 200 of them. Run Jev and Kev against that set behind the same API, compare accuracy at the confidence threshold you'd actually automate at, and keep whichever you'd trust with the escalation queue.