Jev vs. Open-Source GLiNER: Can System 1 Models Be Replaced?

What Is Jev: A Non-Generative "System 1" Model

One of the most talked-about models in the AI world this year, Jev, stands out for a surprising reason — it's neither an LLM, nor does it come from OpenAI, Anthropic, or DeepSeek^Ad. It comes from a brand-new lab called TypeSafe AI. More importantly, its architecture doesn't follow the generative paradigm that has dominated AI development over the past four years.

TypeSafe describes Jev as a "System 1 model" — a term drawn from Daniel Kahneman's Thinking, Fast and Slow, which distinguishes between slow, deliberate reasoning (System 2) and fast, intuitive thinking (System 1). Jev corresponds to the latter. In plain terms, it's essentially an ultra-fast classification model. Companies like Figure Robotics have adopted a similar layered naming scheme (System 0/1/2).

Jev is available exclusively via API. It takes a "state" and a set of "questions" as input, and outputs decisions based on that state. In the official Doom demo, Jev doesn't directly see the game screen — instead, the visDoom library translates the game state into a JSON object describing health, ammo, enemy positions, and item locations.

The fundamental difference between autoregressive generative models and non-autoregressive classification models is worth clarifying here. Mainstream LLMs like GPT and Claude use autoregressive architectures: the model predicts one token at a time, generating output serially — one token after another — which naturally accumulates latency. Classification models, by contrast, operate over a finite, predefined output space. The model simply outputs a probability distribution over known options without needing to "generate" anything step by step. This difference produces fundamentally distinct speed and determinism characteristics: a classifier's inference time is nearly independent of the number of classes, while a generative model's latency scales with output length. Jev exploits this architectural property by framing decision-making as a classification task, entirely bypassing the autoregressive bottleneck.

Three Decision Types and the Key Concept of "Calibrated Probability"

Jev supports three types of output objects:

• Choice: An unordered set of fixed options; Jev outputs a probability distribution.
• Score: Similar to Choice but with ordered options — for example, "retreat—hold—advance—charge" forms a sliding scale, and the output value can fall between options, reflecting a non-fully-discrete characteristic.
• Null: Essentially a yes/no, but mapped onto a 0-to-1 scale, where 0.5 means the model is uncertain.

What truly sets Jev apart is that every output comes with a calibrated probability. When Jev gives a probability of 0.8, it means the model is correct about 80% of the time on that type of judgment. This provides measurable confidence and interpretability for code integration.

Looking at the Expected Calibration Error (ECE) charts, Jev's curve tracks very closely to the ideal calibration line. GPT-5.6 Luna, while not bad, almost always reports extremely high confidence (95%+ routinely); Jev, by contrast, "honestly" gives lower probabilities when it might be wrong. This property is hugely meaningful for building production-grade pipelines — you can explicitly say "this pipeline will be correct approximately 80% of the time," something LLMs struggle to offer.

Expected Calibration Error (ECE) is a standard metric for measuring the reliability of a model's confidence. The core idea: if a model gives 0.8 confidence across 100 different questions, then ideally exactly 80 of those 100 predictions should be correct. ECE groups predictions into confidence buckets and computes the weighted deviation between "claimed confidence" and "actual accuracy" within each bucket. The closer ECE is to 0, the more "honest" the model is. Many large language models suffer from systematic overconfidence — they tend to output very high confidence even in uncertain domains, making their probability outputs statistically unactionable. A well-calibrated model lets engineers use confidence thresholds directly in control-flow logic — for example, "hand off to human review when confidence is below 0.6" — which has real-world significance in high-stakes domains like finance and healthcare.

Speed Advantages and Capability Limits

Another major selling point of Jev is its extremely low latency. On the server side, in the time it takes Luna to produce a single decision, Jev can output 12 to 14. More importantly, Jev processes all decisions in parallel — if there are 10 judgments to make at once, they all complete at the same time, whereas an LLM must generate more tokens and takes proportionally longer.

In benchmark comparisons, Jev matches or outperforms Luna in nearly every category except Banking 77 (bank intent classification), and leads significantly on guardrail-related tasks (prompt injection detection, toxicity detection). This means Jev has been tested and validated as a viable replacement for LLMs in two of their most common current use cases: guardrails and tool selection.

But Jev has clear capability limits:

• It's a classifier — it cannot generate text. Chat, search, and code generation still require LLMs.
• The maximum number of parallel decisions is approximately 255.
• The state input limit is approximately 32,000 tokens, and performance degrades well before that limit is reached.

In other words, Jev isn't a replacement for LLMs — it's a complementary component in the AI stack. It advances the case for neurosymbolic systems that combine neural networks with symbolic logic (code), enabling fast, predictable decisions to be confidently integrated into production code.

Open-Source Alternative: Can GLiNER Replace Jev?

Here's an interesting tension: Jev is closed-source and proprietary. TypeSafe has only disclosed that the post-training method is called RLCD (reinforcement learning for calibrated decisions), and that it's not autoregressive — it pulls probability values directly from the network, likely still a Transformer but with a different output head. Architecture researcher Archie Hume's piece Jev's architecture, amassed goes deeper into speculation on this.

The thing is, much of what Jev does can be replicated using open-source models that already exist. Within days of Jev's release, multiple "Open Jev" clones appeared. In hands-on testing, the standout recommendation is Fastino AI's GLiNER 2.5.

GLiNER is a model family — the name comes from "GLiNER NER" (named entity recognition), with the earliest versions dating back to 2023. GLiNER 2.5 can perform the same structured classification tasks as Jev by changing the input schema. Both are bidirectional encoder models, lacking the autoregressive head of an LLM.

The most striking thing is the size: the GLiNER 2.5 series has only 74 million to 300 million parameters and runs smoothly on consumer hardware. In the author's Doom test, the 74-million-parameter small model was used for gameplay, and in many cases it outperformed Jev; GlyGuard also beat Jev on several guardrail benchmarks.

That said, the open-source approach has notable weaknesses: GLiNER does not provide calibrated probabilities and doesn't output a full probability distribution — a score of 0.65 doesn't mean a 65% correct rate. Different use cases also require switching between different models (GLiNER 2.5, GlyGuard, etc.), unlike Jev's single-model-for-everything approach. This is precisely where Jev and TypeSafe offer their greatest value.

Bidirectional encoders and autoregressive decoders are the two primary variants of the Transformer architecture. BERT-style models use bidirectional encoders: when processing input, each position can simultaneously "see" both left and right context, making them well-suited for understanding tasks (classification, entity recognition, similarity computation). GPT-style models use causal (unidirectional) decoders, where each position can only see the left-side history — ideal for generation tasks but naturally less suited for classification. Both GLiNER and Jev are based on the bidirectional encoder paradigm, which is precisely why they can achieve high-quality classification with far fewer parameters — these models don't need to store the vast world knowledge required to generate text; they only need to learn to distinguish among a finite set of options in a given context. RLCD (Reinforcement Learning for Calibrated Decisions) is TypeSafe's post-training reinforcement learning method, specifically designed for probability calibration, making the model's confidence outputs statistically trustworthy.

Fast Thinking and Slow Thinking: Using an LLM to Command System 1

On latency: Jev's reported server-side time is approximately 88ms per classification; running GLiNER 2.5 small locally on a MacBook M4 Pro GPU is about 8x faster. The low latency of local execution is critical in real-time scenarios.

Returning to Kahneman's fast-and-slow framework, the author experimented with combining both systems: using the fast model (GLiNER or Jev) alone, the model becomes very tactical — it will "shoot on sight" but won't think about grabbing a weapon or finding supplies. Adding GPT-5.6 Luna as a "System 2" coach, the LLM issues more strategic commands ("go to that room and get the plasma gun," "your health is low, go grab a medikit"), while the fast model handles execution.

This layered approach isn't unique. Figure Robotics' Helix 2 model explicitly distinguishes System 2 (reasoning LLM), System 1 (fast neural network executing instructions), and even System 0 (reflex-like stable control similar to human instincts).

The real-world results are compelling: on maps like Defender and Deadly Corridor — "pull the trigger" maps — adding an LLM coach made almost no difference, with the LLM mostly idle. But on the Deathmatch map, GLiNER with an LLM coach more than doubled its score. The reason: local GLiNER can make approximately 8.8 decisions per second, while the hosted Jev, affected by network latency, only achieves 2.5 per second — even cutting Jev's latency in half still leaves it far behind local GLiNER.

Figure Robotics' Helix 2 layered architecture provides an industrial-grade reference for this kind of System 1/2 collaboration. In real robot control, relying solely on a large reasoning model has a fatal flaw: network latency and inference time make the robot slow to react, which in a dynamic physical environment means collisions or task failures. Helix 2's solution is three-layer separation: System 2 handles long-horizon planning ("put the red block in the box"), System 1 receives instructions and processes sensor input at millisecond speeds to output joint torques, and System 0 handles balance and fall prevention — reflex-level control requiring hard real-time guarantees. The core insight of this layered approach is: different cognitive tasks have radically different requirements for latency and abstraction level. Forcing a single model to handle all layers wastes compute and cannot satisfy real-time constraints. Game AI and robot control reveal a remarkably isomorphic architectural need.

How Deep Is Jev's Moat?

The author raises questions about TypeSafe's strategy: the very qualities that make Jev powerful — it must be fast, therefore it must be small — are what make it hard to build a durable moat. Small models mean open-source will likely catch up quickly, and calibrated probabilities aren't new technology per se — they just haven't been widely applied in the open-source world yet, but that will inevitably change.

Still, the author acknowledges Jev's significance: it brought smaller, more specialized models to a mainstream audience and made people realize this class of model is genuinely production-ready. If intelligence in the future is concentrated only in a few large companies with massive compute, that's a dystopian outcome. Jev has carved off a piece of that pie, doing it with a model that most people will soon be able to run locally.

Whether it's Jev or open-source alternatives like GLiNER, both deserve a place in agentic workflows. The clearest entry point is guardrails, followed by tool selection (noting that scenarios involving text generation still require an LLM), and beyond that, exploring where these new models fit in a broader software stack.