Understanding Jev and Where It Fits in the AI Stack

Calibrated Probability?

Calibrated probability is the biggest unlock that Jev introduces. It means when Jev gives an answer a probability of 0.8, Jev will be correct ~80% of the time. That might not seem like much, but it gives us measurable confidence and interpretability.

LLMs like gpt-5.6-luna can generate a confidence score — but it can mean anything, it is not calibrated for 0.8 to mean "this is correct ~80% of the time". It is the LLM saying "trust me bro".

We can measure calibration between models by taking their reported confidence scores and the actual % accuracy. gpt-5.6-luna typically went with very high (97-99%) confidence scores all the time. Jev on the other hand is genuinely well calibrated, often reporting low confidence on answers it got wrong.

Jev's confidence is a real threshold we can mostly rely on. Making it possible to write code that depends on Jev's choices with predictable error rates. This begins to fulfil one of the earliest visions of AI, the idea of merging symbolic logic (ie code) with neural decision making (ie AI) [3].

With Jev we can begin bringing ultra-fast intelligent decision-making into code logic. Stop and think about what that could mean for a moment — it's a big deal.

Ultra-Fast?

That brings us back to latency. Code is fast, can the neural decision-making match that?

Where to Use Jev?

Jev is phenomenal at fast decision making if we can define all potential decisions beforehand. Where we have no need for natural language, and need only a probability of doing X, Y, Z, etc. We can see this in decision and classification focused benchmarks:

Jev actually matches or beats gpt-5.6-luna on all but one benchmark, showing very strong performance for tool selection and guardrails – two major use-cases for LLMs. For guardrails this is a very real use-case, you probably should refactor your guardrails to use Jev.

For tool selection there is more nuance – Jev cannot generate text. If your tool call is web search and the agent is expected to generate the search query, Jev does not work. If your tool call is "display a predefined pop up" or "swap to shotgun", Jev works.

Where Not to Use Jev

Jev intentionally does not replace LLMs — it is a completely new and separate component in the AI stack. LLMs are still the go-to for anything that needs generated text, ie chat, search, and code generation.

Even within the realm of "make a decision" — Jev cannot always be used. The model is limited to a maximum of 255 choice options [1] — so no large scale parallel decision-making.

Jev also does not handle large context windows. The state size is limited to 32k tokens (including the longest question) [4]. Even below that, Jev's performance is reported to degrade as we add more to the input state [5].

Open Source Alternatives

Jev is marketed as a big new advancement in AI — and maybe that is true, but we cannot know. Jev is closed-source with no research paper so details are sparse. We do know Jev's post-training process has been coined Reinforcement Learning for Calibrated Decisions (RLCD) [1] — mirroring RLHF, the breakthrough that paved the way for ChatGPT [6].

We also know that Jev is not an autoregressive model [1]. That means Jev does not sequentially generate outputs (tokens) like an LLM. Instead, Jev pulls probability values directly out of the network — like a transformer with a classification or regression head.

Archer Hume posted a phenomenal analysis where he infers further architecture details based on response latency and qualities of the model (such as output answers independence) that give us a glimpse of the potential architecture — but nothing concrete [7].

Regardless, there are plenty of open source alternatives being placed under the umbrella term "OpenJevs" [8]. OpenJev models consist of various architectures and even intended purpose but can all be applied to Jev-like problems. Here is a small selection of these models, it is not exhaustive and will be quickly outdated.

All of these models can be easily run on consumer hardware. GLiNER, Laya, and Von (on Apple Silicon) each require PyTorch and a pip install. The latency numbers were collected on an M4 Pro GPU.

Both Laya and Von are currently fan-favorites. However, from my tests, GLiNER models are generally superior.

Von performs best on tool selection and mediocre-to-poor elsewhere. Laya excels at detecting prompt injection attacks but collapses against intent detection and tool selection. GLiNER2.5 and GLiGuard are most consistent and run multiple questions in parallel making them much faster for batched queries [A.2].

GLiNER

GLiNER is a family of models that share little more than an idea. They place labels and some input text together, feed them into a bidirectional encoder (a type of transformer lacking the autoregressive token-generation of LLMs), and have the encoder score each label against the text in a single pass.

There is no single shared mechanism between GLiNER models as to how label scoring happens. GLiNER focused solely on Named Entity Recognition (NER) by scoring candidate entity spans in the text. GLiNER2.5 drops spans and instead identifies "boundaries" when in NER-mode.

Thinking fast and slow

A decision in ~10ms is a reflex. Reflexes are fast and necessary but lack reasoning. Jev and OpenJev alternatives don't necessarily lack intelligence or logic, but they can't reason over sequential token generation like LLMs.?Remember, LLMs are autoregressive models, they sequentially generate tokens and can therefore "reason" over those tokens. Jev-type models are non-autoregressive and fundamentally cannot reason due to their non-sequential nature.

Returning to Kahneman's work, our brains operate two systems — System One, ie intuition or fast thinking and System Two, ie reasoning or slow thinking. By adapting a similar fast and slow system we can improve performance on the most important benchmarks — playing games.

Our fast and slow system keeps Jev-type models as the decision-maker but adds an LLM to generate instructions on what to prioritize.?This idea of layering fast and slow models exists elsewhere in AI — Figure robotics employ a three tier model system that they coincidentally name System Two (a slow reasoning model), System One (a fast perception/movement model), and System Zero (a super-fast reflex model) [15].

For example, in Doom deathmatch the player is able to run into a parallel room to pick up better weapons, health, etc. When Jev-type models play solo they focus on shooting enemies. An LLM will instead say "go get the chaingun in the parallel room" — this delays player points momentarily but once the player switches to the chaingun they can kill far more enemies and farm points.

Our fast and slow system can also decide whether the slow LLM coach is needed at all. Returning to the Doom examples, our LLM was barely consulted on three-of-four tested maps.

What to Make of Jev?

Jev delivers typed, ultra-fast, and calibrated decision making — filling the gap that LLMs cannot fill.

Calibrated probability means we now have trustworthy decision making that we can put in code. Our code defines the logic and execution, a neural net decides the path. This makes the decades old idea of neuro-symbolic AI practical at ultra-low latency.

Jev's place in the AI stack is as the neural glue between pieces of symbolic logic. It is the fast decision-maker unlocking neural integration with code, going at it alone or in tandem with the slow-thinking but powerful LLMs. Thinking both fast and slow to 4x Jev and GLiNER's solo Doom deathmatch scores.

Some of Jev's greatest qualities make it hard to capitalize on. The use-case is real, but the model already has several open source imitators. Even before Jev there were model families like GLiNER enabling similar use-cases.

These open source alternatives trail Jev's overall performance but some already beat or match Jev across multiple benchmarks. All of them can be run easily on consumer hardware. The one real edge that TypeSafe has is calibration, but open source may not be far behind.

All of this makes AI a little less dystopian. Jev has real utility as a major component in AI stacks, and unlike LLMs it prioritizes control. And Jev has triggered a wave of open source models that can be run locally — bringing near-frontier AI decision-making to our own machines, not locked inside a handful of mega-corporations.

Beyond those utopian dreams, Jev and OpenJevs absolutely deserve a place in your agentic workflows. Start with guardrails and tool selection — integrating decision-making into your code logic — and explore where else these new models might fit into the AI and broader software stack.

References

• [1] D. Almeida, TypeSafe (2026), Introducing System One Models & Jev
• [2] D. Kahneman (2011), Thinking, Fast and Slow, Farrar, Straus and Giroux
• [3] J. Briggs (2024), AI Agents are Neuro-Symbolic Systems
• [4] TypeSafe (2026), Models, TypeSafe docs
• [5] TypeSafe (2026), Jev 1.13 jaggedness, TypeSafe docs
• [6] L. Ouyang et al. (2022), Training language models to follow instructions with human feedback
• [7] A. Hume (2026), Jev's Architecture Unmasked
• [8] Jev alternatives: open-source reproductions, local models and classifiers, a catalogue of 33
• [9] Fastino (2026), Introducing GLiNER2.5; models fastino/gliner2.5-base-v1
• [10] Fastino (2026), fastino/gliguard-LLMGuardrails-300M
• [11] wfzyx (2026), Von: the open-source System One decision model; weights wfzyx/von-1.0
• [12] B. Warner et al. (2024), Smarter, Better, Faster, Longer: A Modern Bidirectional Encoder for Fast, Memory Efficient, and Long Context Finetuning and Inference
• [13] Convai Innovations (2026), Laya; weights convaiinnovations/laya
• [14] U. Zaratiana et al. (2023), GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer
• [15] Figure AI (2026), Introducing Helix 02: Full-Body Autonomy
• [16] I. Casanueva et al. (2020), Efficient Intent Detection with Dual Sentence Encoders
• [17] S. Larson et al. (2019), An Evaluation Dataset for Intent Classification and Out-of-Scope Prediction
• [18] Berkeley Gorilla (2024), BFCL V3: Multi-Turn & Multi-Step Function Calling; leaderboard
• [19] jackhhao (2023), jackhhao/jailbreak-classification
• [20] deepset (2023), deepset/prompt-injections
• [21] Z. Lin et al. (2023), ToxicChat: Unveiling Hidden Challenges of Toxicity Detection in Real-World User-AI Conversation; data lmsys/toxic-chat
• [22] U. Zaratiana et al. (2025), GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface
• [23] M. Kempka et al. (2016), ViZDoom: A Doom-based AI Research Platform for Visual Reinforcement Learning
• [24] E. Leurent (2018), An Environment for Autonomous Driving Decision-Making
• [25] C. Guo et al. (2017), On Calibration of Modern Neural Networks

Appendix

(Appendix primarily written by Fable 5.1 and Opus 5)

A.1 Methodology

Decision benchmarks. Six sets, the same items for every model: Banking77 [16] (400 messages, 77 intents), CLINC150 [17] (500, 150 intents plus out-of-scope), BFCL v3 [18] (260, multiple-function and irrelevance splits; scored on function selection only, with a "none of these" option), jackhhao/jailbreak-classification [19] (262, balanced test split), deepset/prompt-injections [20] (116, test split) and lmsys/toxic-chat 0124 [21] (400, positives are toxic or jailbreaking). Intents and tools report accuracy; guardrails report F1 on the "block" decision. Every model sees the same labels; descriptions are the label names unless noted.

How each model was asked. Jev, Von and Laya get the identical request — one state (the message) and Jev-format questions: a Choice over the labels for intents and tools, and for guardrails a battery of three Nouls (jailbreak, injection, harmful) plus a four-level Score; the block score is the highest Noul, threshold 0.5. Von and Laya sit behind a small adapter that maps the same question dicts to their SDKs. GLiNER2.5-base uses its classification schema [22] with the labels and the same question, as its task prompt; GLiGuard is the guardrail variant. gpt-5.6-luna is asked for a strict JSON-schema answer with reasoning_effort="none", temperature default. Laya's option budget (192 tokens) refuses CLINC150; it was run through its documented predict_shortlist route (embed, top-20, predict).

Latency. Median wall-clock per call from the same machine. For Jev, server time is the x-envoy-upstream-service-time header and the round trip uses one keep-alive HTTPS connection (a fresh TLS handshake per call costs more than the model does). For GPT, server time is the openai-processing-ms header. Local models run on the M4 Pro GPU (MPS).

Games. ViZDoom 1.3 [23] (defend_the_center, defend_the_line, deadly_corridor at skill 5, deathmatch) and highway-env [24] (exit-v0, ego started in the third lane). Eight episodes per configuration from the same seed; deathmatch and the motorway exit vary far more from run to run, so deathmatch pools 8 episodes on each of four seeds (32 per configuration) and the motorway exit runs 32 episodes (seeds 0–31). System 1 decides every 4 game tics (≈9/s); a slow decider's last answer is held until its next one arrives. GLiNER2.5-small gets the question Jev gets, as its task prompt. System 2 is gpt-5.6-luna (reasoning off) consulted before the first tick and only on triggers (no kill for 10s, no route progress for 8s, low health, ammo out), answering with typed guidance that code validates and clamps; geometry, safety and routing are code. Scores are the scenarios' own rewards; deathmatch points are kills weighted by monster.

Environments. Python 3.12; gliner2, typesafe-sdk, openai; Von (von-sdk 1.1) and Laya (laya 0.3) in a separate environment because they need transformers 5. Code and result files: link to follow.

A.2 Latency by input shape

Median milliseconds per call on the M4 Pro GPU, same machine and same inputs for every model. "Short" is a one-line support message; "long" is a ~325-word jailbreak prompt. Jev's server time is ~90ms for any of these shapes (measured with one to three questions); gpt-5.6-luna ~700ms. The GLiNER models were timed without the question in their task prompt; with it, a call takes 2–8ms longer.

All five are encoders, so cost follows the tokens they read: the state, plus every option's text, plus the question text. What differs is how questions are handled. GLiNER2 scores every question's labels in one pass, so a battery of four costs the same as one. Von runs roughly one pass per question (4× for the battery); Laya batches questions but pays heavily for options (219ms at 77, and it refuses more than ~50 without its shortlist step).

A.3 Calibration (ECE)

Expected Calibration Error (ECE) [25] measures the gap between the confidence a model reports and how often it is right. 0 is perfect.

What counts as confidence. For intents and tools, the probability of the chosen option: the top of probabilities for Jev, Von and Laya, GLiNER's score for its chosen label, and the confidence number gpt-5.6-luna writes in its JSON answer. For guardrails, every model gives a probability p that the message should be blocked (for Jev, Von and Laya the highest of the three Nouls [A.1]; for gpt-5.6-luna the probability it writes). The decision is "block" when p ≥ 0.5, so its confidence is max(p, 1 − p), and it is right when it matches the label.

Calculation. Sort the N answers into ten equal-width confidence bins: (0, 0.1], (0.1, 0.2] … (0.9, 1.0]. For each bin b take its size n_b, its mean confidence and its accuracy. Then:

Each bin adds its gap, weighted by its share of the answers. Every bin counts toward ECE; the reliability chart only draws bins with at least ten answers.

Worked example: CLINC150, N = 500.

gpt-5.6-luna's ECE comes almost entirely from one bin: 472 of its 500 answers sit at 0.99 confidence and are right 88% of the time. Jev spreads its answers across the range, and most bins sit close to their accuracy.

ToxicChat is the extreme case. gpt-5.6-luna put all 400 answers in the top bin at 0.99 and was right on 82%, so its ECE is simply 0.99 − 0.82 = 0.17.

Jev's confidence field. The numbers here use Jev's top probability. Scoring its separate confidence field instead gives 0.13 on Banking77 and 0.04 on CLINC150, against 0.14 and 0.05.

Every model, every benchmark.

A.4 Local models on the decision benchmarks

Three things stand out:

• The GLiNER family is the only local option that holds up across the board: GLiNER2.5 within a few points of Jev on Banking77 (0.70 vs 0.74), GLiGuard better than everything on ToxicChat (0.94). The weak spots are "none of the above" (CLINC150, 0.59) and prompt injection (0.46).
• Von is a tool-selection model. 0.90 on BFCL at 18ms is close to Jev's 0.95 at a fifth of the latency. On intents it collapses (0.27 / 0.41) and its probabilities are near-uniform (ECE 0.65 on Banking77): the confidence it returns is not something you can threshold.
• Laya is a guardrail model. 0.95 on jailbreak, 0.74 on prompt injection (better than Jev's 0.71), 0.77 on ToxicChat, 50–100ms. Past ~50 options it cannot answer at all without its shortlist step, and with it CLINC150 falls to 0.20.

A.5 Videos

Twelve full episodes, one per configuration. Game on the left; what System 1 reads and scores on the right; System 2's guidance below it. Coach calls took about 2s in these takes. Deathmatch varies from run to run for Jev alone and both coached setups, so for those three we recorded four takes. For Jev alone and Jev + coach we show the one closest to the setup's median benchmark score; for GLiNER + coach, the best of the four (54 points). The numbers above are from the benchmark runs, not these takes.