Jev: System One Models, Use Cases, Open Source and Benchmarks

• LargitData
• 2026-09-20

Over the past few years, we have learned to send almost every AI task to a large language model: deciding which team should receive a support ticket, choosing which source a RAG system should search, checking whether a model response violates policy, or answering a simple yes-or-no question. Yet most of these tasks do not actually need fluent prose. They need a decision that software can use immediately.

TypeSafe AI built Jev for that category of work. Jev is not a chatbot and does not generate an answer token by token. It receives state plus a set of typed questions, then returns choices, scores, or probabilities. TypeSafe calls this a System One model.

This article explains the problem Jev is designed to solve, how a System One model differs from a conventional LLM, where it can be applied, and what is actually open source. It then uses our public Jev Benchmark to compare Jev with several self-hosted systems on a multi-turn RAG routing task.

The pain point Jev addresses: software needs decisions, but LLMs generate text

A conventional LLM is fundamentally trained to predict the next token. Even when it is asked to return JSON, it is still generating a string underneath. That is useful for human conversation, but it creates several structural problems when another program must consume the output.

1. The output still needs parsing and validation. A program may need exactly billing, technical, or other, while a model may add an explanation, rename a field, or return an option that was never allowed. Structured output reduces formatting failures, but the caller is still using a model whose primary behavior is text generation.
2. Simple decisions inherit generation latency. Classification, routing, and yes-or-no checks usually need one closed answer. If a large model still writes an explanation token by token, the system pays for text that no one will use.
3. Confidence is hard to operationalize. A fluent answer can sound certain even when the underlying decision is weak. Production software needs calibrated probabilities and explicit thresholds so that it can automate high-confidence cases and escalate uncertain ones.
4. Control can leak into the model. If an LLM is allowed to invent tool names, selectors, database fields, or actions, its output starts to behave like executable control flow. That makes permissions, auditing, and rollback much harder.

Jev narrows the contract. The application defines the legal output space first, and the model chooses within it. The result is still probabilistic, but the uncertainty is exposed in a form that a program can inspect, log, test, and govern.

What is a System One model?

The name comes from the familiar distinction between fast, intuitive System 1 thinking and slower, deliberate System 2 reasoning. In TypeSafe's terminology, a System One model is optimized for rapid semantic decisions rather than open-ended generation or long chains of reasoning.

Jev accepts text, a JSON object, or an array of text as state. The caller then asks one or more typed questions. Its core output types are:

• Choice: select one item from a closed list, such as billing, technical, or other.
• Score: assign a value on a defined scale, such as relevance from 0 to 5.
• Noul: return the probability that a statement is true, such as whether a page element is an advertisement.

A Choice result can include a probability distribution over the allowed options, and a Noul result exposes the probability of the proposition. That means the application can implement explicit policies: high-confidence decisions execute automatically, medium-confidence decisions ask the user to confirm, and low-confidence or high-risk cases go to a human or a reasoning model.

This is not a claim that fast intuition is always better. It is a division of labor. System One is useful when the answer space is known in advance, the task is frequent, and a wrong decision can be detected or contained. Arithmetic, date comparison, permissions, and irreversible actions should remain in deterministic code. Complex explanation and multi-step reasoning should remain with a generative or reasoning model.

A typical Jev workflow

Consider an enterprise RAG assistant. A user asks, “Using the contract we signed last month, can you confirm whether this expense is reimbursable?” The application can package the conversation history, available data sources, and permission state, then ask several questions at once:

• Should the answer come from the named document, the knowledge base, the public web, or a tool?
• Does this turn continue the previous topic, or has the scope changed?
• Should the system answer, analyze, ask for missing information, or block the request because of permissions?
• Does the “use only this contract” restriction remain active for the next turn?

Jev returns structured decisions, while the real control flow remains in application code. The application checks permissions and confidence thresholds before it opens a file, performs retrieval, or asks the user for more context. Only after the correct evidence has been collected does it ask a generative model to write the response.

A practical architecture therefore has four lanes:

1. The System One lane handles frequent, closed, measurable judgments.
2. Application code owns state, permissions, arithmetic, thresholds, and side effects.
3. Generative or reasoning models handle explanation, writing, multi-step reasoning, and open-ended answers.
4. Humans review low-confidence, high-risk, or irreversible cases.

The point is not to replace every LLM with Jev. It is to stop using a large generative model for every small decision.

Where can Jev be used?

Any task with a predefined answer space, where the result is meant for software rather than direct human reading, may be a candidate for a System One model. Soon after Jev launched, developers applied the pattern to browser agents, ad filtering, trading, search, code review, and smart-home automation. The following four examples make the pattern concrete.

Case 1: real-time ad filtering

TypeSafe AdBlock is an MIT-licensed Chrome Manifest V3 extension. The program first uses DOM rules to find elements that look like ads. It then packages tag names, CSS classes, text summaries, link domains, and placement geometry into compact JSON. Jev uses a Noul question to estimate whether each candidate is a paid advertisement. By default, the extension removes an element only when P(ad) ≥ 0.70.

Images: frames from creator Zachi's original demo video.

This example shows the System One division of labor clearly. Candidate discovery, batch limits, thresholds, animation, and deletion are all controlled by code. Jev performs only the semantic judgment. The creator also states that this is an experimental capability demo, not a security-grade ad blocker. It can miss ads or remove ordinary content, and it does not block trackers, malware, or video ads. Mature blocking tools remain the right choice for production use.

Case 2: deciding what to wear

Choosing an outfit is a useful System One design pattern because the required output is not a paragraph of fashion advice. It is one executable choice from the clothes a person actually owns. An application can collect local weather, rain probability, calendar context, laundry status, and the user's wardrobe, then enumerate only valid combinations as Choices. Jev can judge warmth, formality, color coordination, and personal preference, while code removes items that are wet, in the laundry, or incompatible with a dress code.

If the wardrobe exists only as photographs, a vision model or a human should first convert the images into fields such as material, color, and garment type. Jev currently accepts text and JSON, not raw images. Temperature conversion, rain status, and garment availability should also be computed deterministically. When confidence is low, the interface should show two or three candidates instead of making an irreversible purchase.

Verification note: as of September 20, 2026, we could not find a verifiable, completed outfit-selection application in the public Jev directories or GitHub projects we reviewed. This section is therefore an implementable product pattern, not a claim about a deployed case, and we have not attached an unrelated image.

Case 3: investment and trading decisions

Jev Trader is an MIT-licensed experiment. It reads the MON-USDC order book from Kuru on Monad and asks Jev to choose buy or sell on each block, roughly every 300 ms. Application code still determines the order price, quantity, cancellation policy, position limit, and trading state. Without a private key, the project defaults to dry-run mode: it reads the real order book but simulates fills.

Image: Jarrod Watts's original Jev Trader demo; the upper-right panel is marked dry run. The figures are from the creator's example and do not represent investment performance.

This is not a license to turn Jev into an unconstrained investment adviser. Price calculations, risk limits, capital permissions, and the decision to submit a real order must remain in testable code and under human control. A more conservative production pattern is to let Jev classify financial statements, events, and central-bank communication with Choice, Score, or Noul outputs, creating an auditable research queue for a person to accept or reject. The open-source SmartMoney-Cub project follows that direction with a read-only journal and explicit human promote or reject actions. None of these demos is investment advice or evidence of persistent profitability.

Case 4: accelerating a browser agent

Jev Ultrafast replaces each browser agent's “next action and target element” step with one Jev request. The page is first converted into a numbered list of interactive elements. Jev chooses from closed actions such as CLICK, TYPE_TEXT, SELECT, SCROLL, WAIT, and DONE. A small generative model is called only when the agent genuinely needs to produce text.

Image: the Browser Use project's original Jev Ultrafast result. The 7.1-second completion time and 178 ms figure describe that creator demo, not a universal benchmark for every website.

“Accelerating the browser” here does not mean making Chrome's JavaScript engine or network downloads faster. It means shortening the agent loop that observes a page, decides on the next step, and acts. The project normally makes decisions from a structured DOM representation rather than screenshots. Before execution, it also checks that the element still exists, is not obscured, and was not taken from a stale page. Model output is not treated directly as a selector, screen coordinate, or executable program.

What other applications already exist?

Beyond those four patterns, the public projects collected by Awesome Jev cover several other categories:

• Reading and page cleanup: Unclutter decides which page elements are not part of the main content, then stores the resulting rule locally for the next visit. jev-skip assigns sponsorship probabilities to segments of a YouTube transcript.
• Search and data organization: semantic function search, selecting the next relationship in a Neo4j graph, classifying papers, and filtering large JSONL or Parquet datasets.
• Code and agent quality: reviewing a staged diff, deciding whether an agent has completed its task, detecting sensitive information, prioritizing logs, or choosing whether a stuck agent should continue, re-plan, or stop.
• Model and tool routing: choosing a model, thinking depth, or agent skill based on the difficulty of each turn, with an option to abstain at low confidence.
• Enterprise workflows: resume screening, email intent routing, support-ticket classification, content moderation, citation support, and smart-home sensors or automation.
• Real-time interaction: Doom, Mario, Tetris, drones, and robot arms, where code owns physics and safety boundaries while Jev makes tactical choices at branch points.

Conversely, Jev is not the natural tool for writing articles, generating code, answering open-ended questions, exact counting, date arithmetic, or deep multi-step reasoning. TypeSafe's Jev 1.13 limitations list several known weaknesses: the model can interpret instructions too literally, cannot count reliably, struggles with mathematics and date comparison, loses accuracy on multilayer indirect reasoning, and can suffer from context rot when given large amounts of irrelevant information. Anything that code can calculate exactly should remain in code.

Is Jev open source? Separate the model, SDKs, and alternative implementations

Discussions about Jev's open-source ecosystem often combine three different layers.

1. The Jev model itself

At the time of writing, Jev 1.13 is accessed through TypeSafe's hosted API at POST /v1/systemone. TypeSafe publishes the pricing, context window, input format, and known limitations, but it has not released the Jev 1.13 model weights or training data. Jev is therefore not an open-weight model that can be downloaded and deployed inside a private network. According to the official model page, Jev 1.13 costs US$0.042 per million input tokens, does not charge for output tokens, and currently accepts text, JSON objects, or text arrays.

2. Official SDKs and adapters

TypeSafe's Python SDK, JavaScript and TypeScript SDK, and System One Adapter, which wraps a conventional LLM behind a similar interface, are all public MIT-licensed repositories. An open-source SDK, however, does not make the hosted Jev weights open source.

3. Community-built self-hosted models and compatible implementations

Several public projects took different approaches to the same decision interface:

• SemIf reads option probabilities from a frozen open model and is MIT licensed.
• Laya is a family of encoder-based decision models with self-hostable weights under Apache 2.0, including a multilingual 322M model.
• djev-spark exposes a Jev-compatible API using DiffusionGemma on a DGX Spark. Its repository currently does not state a license, so commercial use or redistribution requires additional verification.
• system-one demonstrates how to turn a conventional open LLM into a one-forward-pass option classifier.

Self-hosting can keep data out of an external API, pin a model version, and enable domain-specific fine-tuning. The tradeoff is that the organization becomes responsible for GPUs, operations, calibration, and evaluation. More importantly, these systems may return similar Choice, Score, and Noul structures while using very different architectures, languages, option limits, context sizes, and meanings of confidence. A common interface does not make them interchangeable.

Our test: five systems on multi-turn RAG routing

To test whether hosted Jev and self-hosted alternatives can really substitute for one another, we built the public Jev Benchmark. The scenario is an enterprise RAG assistant with six knowledge bases, eight named documents, and six tools. The evaluation measures routing decisions made before the final answer is generated.

The dataset contains 20 conversations with five turns each, for a total of 100 multi-turn decisions. On every turn, the system must correctly answer four questions:

1. Route: should the answer use conversation context, general knowledge, a named document, a knowledge base, the public web, or a tool, or should the system clarify or refuse?
2. Scope change: has the topic continued, changed, expanded, narrowed, conflicted with a restriction, or been blocked?
3. Mode: should the system answer, rewrite, analyze, ask a clarifying question, or block the request?
4. Restriction: does the next turn remain limited to a named document, or is public-web access still forbidden?

The “decision correct” column uses a strict definition: all four dimensions must be correct on the same turn.

What the benchmark tells us

Jev's advantage is not winning every accuracy column; it is stable latency

Jev was close to Gemma 4 31B on “where should the system look?” and “did the topic change?” The main gap was in restrictions that must persist across turns. Jev's p50 latency was 749 ms and its p95 was 818 ms, so the slow tail was only modestly slower than a typical response. Gemma's p50 was 2,293 ms and its p95 exceeded 4.7 seconds. When a product promises predictable responsiveness, p95 latency often matters more than an average.

Open source, self-hosted, and interchangeable are three different claims

djev-spark, SemIf, and Laya all expose a similar structured-decision interface and can keep data in the user's environment, but their accuracy differed sharply on this zero-shot, multilingual, multi-turn RAG routing task. Laya 322M was the fastest system, yet it did not produce a single turn on which all four decisions were simultaneously correct. That does not mean Laya is ineffective for every task. It means an untuned base model should not enter production merely because its latency is attractive.

A routing model must not be the only guard before a high-risk tool

When a prompt genuinely lacked required information, Gemma correctly asked a clarifying question in only 43% of cases, while Jev did so in 31%. A common failure for both systems was to call a tool instead of asking. If a tool can send email, create a ticket, move money, or modify production data, the application must add explicit permission checks, parameter validation, user confirmation, and reversible execution. High confidence is not authorization.

Verify that the model received the intended input before trusting a low score

During testing, we obtained severely distorted results from incorrectly escaped Chinese text, inflated input length, and broken SSH tunnels. In the most extreme case, a score changed from 3.8% to 32.2% after the pipeline was corrected. The benchmark therefore publishes not only aggregate scores but also task definitions, per-item predictions, timing logs, ground-truth audits, and methodology. A low score can indicate a weak model, but it can also reveal a failure in the adapter, serialization, connection, or scoring pipeline.

Five questions to answer before adopting Jev or an open alternative

1. Is the answer space truly closed? If the legal answers cannot be enumerated in advance, use a generative model or add a candidate-generation stage first.
2. What is the cost of one wrong decision? Opening the wrong page and sending the wrong email require very different confidence thresholds and confirmation policies.
3. Can the data be sent to a hosted API? Internal secrets, personal data, or data-residency requirements demand classification and legal review, and may require a self-hosted system.
4. Do you have a task-specific test set? Vendor and third-party aggregate scores cannot replace tests using your languages, domain terms, real options, and actual error costs.
5. Who owns state? Multi-turn applications often fail not because of one classification, but because a restriction, permission, or scope from the previous turn was not preserved correctly.

The safest adoption path begins with a high-volume but reversible routing or classification task. Keep the existing process in shadow mode, record the model version, full probability distribution, actual outcome, and human review, then tune thresholds from real data. Re-run the same regression suite whenever the model version changes.

Conclusion: let the model judge while software retains control

Jev matters not only because of speed or price, but because it redraws the boundary between AI and software. The model interprets semantics and makes bounded judgments. Code owns state, permissions, thresholds, mathematics, and side effects. A generative model appears only when the product genuinely needs language or reasoning.

A System One model does not eliminate errors. It puts them into a form that is easier to measure, log, and govern. That is why model selection cannot rely on one attractive latency number or a single demo. The model must be tested inside a real multi-turn flow: do restrictions persist, does the system stop at low confidence, and can an error trigger an irreversible action?

The complete tasks, code, per-item results, charts, and test limitations are available in the Jev Benchmark GitHub repository. If you are building an enterprise RAG system, agent router, or model guardrail, you can reproduce the evaluation directly and contribute new adapters or results so that different System One implementations can be compared on the same transparent benchmark.