Early experimentation using Jev to rethink harness UX

This video and blog post covers internal experimentation with a new type of model, using it as part of the infrastructure of our harness. None of this is in production yet, it’s just alpha work. 

TL;DR: 

• Using a model like Jev (Classifier with LLM intelligence) and another LLM simultaneously powers different types of user interactions that (we think) are going to be the future of UX. Or, at the very least, be an interesting new way for software to work. 
• elvex is a model-agnostic harness built for team collaboration. It is a software to use LLMs, and aspects of the platform itself are powered by LLMs. Working Jev into that second aspect, the platform, is enabling some pretty magical new stuff. 
• Here’s the cool thing: Interfaces that assemble themselves as you type … Ambient classification while typing powering live UX orchestration

What this post covers

This post is a writeup of an internal prototype walkthrough where we wired Jev into our agent harness and explored where instant classification changes product UX. It is aimed at developers. It stays approachable but does not shy away from implementation detail.

Here is what is covered:

• What Jev is and how System One Models differ from autoregressive LLMs
• How we put Jev inside our harness as a callable tool
• 2,000 expense reports classified in 21 seconds for about five cents
• Smarter attention filtering: instead of notifications for everything, what about a platform that intelligently decides when you need to be notified?
• Search reranking and intent routing for magic search style UX
• Per message context extraction at 75 percent lower cost
• Risk aware approvals, instead of binary auto approve rules
• Interfaces that assemble themselves as you type: Ambient classification while typing powering live UX orchestration
• How System 1 and System 2 models work together
• Why we are not shipping it yet: early access, vendor, and legal risks

What is Jev?

Jev is the first public model from TypeSafe AI, released in early access on Sep 15, 2026. The announcement post is here.

Most of what we build with LLMs today is “System 2” work. Slow, deliberate, step by step reasoning. You give the model a prompt, it generates one token at a time, and you wait while it thinks out loud. Jev is built for System 1 work: snap judgments, instant classification. Here is some input, which bucket does it belong in, and how confident are you?

TypeSafe frames Jev as a new class of frontier model: System One Models. The name comes from Daniel Kahneman's Thinking, Fast and Slow distinction between fast intuitive System 1 thinking and slow deliberate System 2 reasoning. Jev is named after William Stanley Jevons, a nod to the Jevons paradox idea that every order of magnitude drop in cost unlocks orders of magnitude more use.

Technically, three things are new according to TypeSafe:

1. Model architecture focused on automation, not chat. Jev gives up string generation entirely. It is optimized for structured outputs.
2. Parallel sampler for maximum efficiency. Instead of generating tokens autoregressively, Jev outputs all probabilities in parallel in a single forward pass.
3. Training method called Reinforcement Learning for Calibrated Decisions (RLCD), aimed at producing well calibrated probabilistic decisions.

The mental model that TypeSafe suggests is useful: think of Jev as a frontier intelligence function call. Unstructured state in → typed probabilistic decisions out.

What that means in practice:

• Choice: given up to 255 options, which one is it, with a probability distribution. Higher cardinality choices use a two stage score then a choose step.
• Score: a float from 0 to 1 for how well a given input matches a description.
• Yes/no: a boolean judgment with confidence, framed as a Bernoulli output.

There is no free text generation: you cannot ask it to write a paragraph. Because outputs are constrained to the schema, TypeSafe claims it cannot hallucinate in the type error sense. Schema matching is guaranteed, so no malformed tool calls buried three layers deep in a dependency chain.

On performance, TypeSafe publishes workflow evals that compare Jev to large models like GPT-6 Astra and Fable 5.1 as reference answers on production style workflows. Their headline numbers are 193.6x faster and 444.6x cheaper. 

For developers the takeaway is simple: you define a decision boundary in natural language instead of training data, and the model applies it with broad world knowledge. If you have used LLM as judge prompts, you get similar zero shot flexibility but at two orders of magnitude better speed and cost.

Putting this into a harness as a callable tool

Once you internalize that noticing is now cheap, you start seeing places to apply it. The examples below were all prototyped in about a day and a half. 

To test this, we wired Jev into our agent harness as a tool callable from code execution. In other words, a LLM plugged into our harness understands what Jev is and how to use it and creates the interaction the user wants. The agent itself writes the classifier definition from a natural language prompt, validates it on a small sample against a slower frontier model, then fans out across the full dataset.

The first, simple use case: 2,000 expense reports in 21 seconds

The task: take a CSV with 2,000 expense reports and answer a yes/no style policy question for each one. “Is this spend okay?”

The agent did three things:

1. Wrote the classifier definition for Jev from a natural language prompt (a normal LLM did this)
2. Ran it on 20 rows as a spot check, then compared those results against a slower frontier reasoning model to validate agreement
3. Fanned out across all 2,000 rows

Total time spent by Jev was about 21 seconds, and the cost was about five cents.

For comparison, the same experimentation we did via Jev, run through a capable chat model, would take orders of magnitude longer and cost well over $100 for similar throughput. Even at a few seconds per row, you are looking at hours, not seconds.

The interactions between two types of models here is the cool part. Use your System 2 model to label a small sample, measure agreement, then let the System 1 model do the bulk work. It is the same pattern as distillation and evals, except the student model is configured in plain English and requires no training loop.

Why is this better than classifiers we already had? Traditional classifiers needed labeled training data and retraining for every new policy, LLM prompts as classifiers needed no training but cost seconds and cents per call (which kills high volume use cases), but here you get on demand classifiers with broad world knowledge, created at runtime by the agent itself, running fast enough to sit in hot paths.

There is potentially an argument that traditional classifiers have higher accuracy. (It would need to be compared use case by use case). But they are not on-demand–Jev lets you build classifiers as you go, which is a totally different paradigm. 

Smarter attention filtering: instead of notifications for everything, what about a platform that intelligently decides when you need to be notified?

Many apps have a deterministic “waiting on you” list. If there is a new comment or a meeting, flag it. You get a notification for everything. But that logic is brittle, it flags noise and misses messages that need a reply but have no formal trigger.

With Jev you can add an intent classifier on top: does this message actually ask the user a question that needs attention? The classifier runs after the fact on every message because it is fast enough and cheap enough to do so. In the demo it caught a message with no formal trigger and correctly flagged it as requiring feedback.

If you can classify completion cheaply, you can drive downstream behavior like auto resolving threads, triggering retros, or suggesting agent instruction updates.

Search reranking and intent routing

Searching through your application—for previous conversations, for agents and datasources, for artifacts—is a key part of working. This applies to other software too, obviously; ones that are not agent harnesses.

Jev enables a smarter, more helpful search, that connects you to the right thing you were looking for immediately, using frontier-grade intelligence to make the decision. 

Pull back a broad candidate set with keyword or vector search, then score each result against inferred intent with Jev, and the score becomes your reranking. 

You can also classify the query itself before you search at all. For example, a user is in a thread with marketing ad spend reports, and they start asking a question. Do they want to be pointed towards a thread, or a document, or do they want to be pointed directly towards the portion of the document that answers their question? A classifier can detect that and route directly to analysis instead of showing document results.

Historically that kind of query understanding took large amounts of training data and dedicated ranking infrastructure. Here it was built with minimal examples during the demo.

Per message context extraction

elvex updates a users context when they interact with our system. This is currently done by a LLM. It’s expensive (but worth it). And it’s also, frankly, as imperfect as LLMs: surprisingly good, but not always accurate. Sometimes the suggestions for what should be added to a users context are not useful. 

With Jev, we can immediately improve this system. Every message a user sends can be classified for memory worthiness: does this contain something worth adding to personal context?

In the prototype, as soon as a message was sent, a classifier as either “yes, useful” or “no, irrelevant.” Then a normal LLM grabbed the useful interactions and interpreted them for the context that should be added.

In testing on real personal usage data with manual labeling before and after, this approach cut cost by about 75 percent compared to the existing LLM extraction pipeline, with about 38 percent fewer mis suggested updates. 

Risk aware approvals for Human-in-the-Loop

Human in the loop (HITL) approvals today tend to be binary and coarse: auto approve everything, auto approve by action type, or approve nothing. That forces a tradeoff between safety and interruption.

Classifiers let you write nuanced rules: does this action match what the user actually intended, and does it look safe? In the demo, a request to create a Linear issue went through without a prompt because a classifier judged it safe and intent aligned, even though auto approval was off for that action type. This mirrors patterns like the auto approval systems in coding agents, where low risk, high confidence actions skip review.

Implementation wise, think of it as policy as code where the predicate is a natural language classifier plus threshold.

Interfaces that assemble themselves as you type: Ambient classification while typing powering live UX orchestration

Speed has a quality of its own. The most striking demo was running classification inside the input debounce.

As the user typed, the app ran intent classification on the partial text to suggest what type of interaction might help the user most, whether that was a related open thread, the right space for the conversation, a relevant data source to attach, or a missing integration to connect. 

Think of it as Google’s auto complete when typing in a search, but instead of completing the sentence you’re working on, it’s completing “which part of our software does the user need” and dynamically serving that to the user as they act, with no detectable latency. 

For the integration example in the video, the team had pre classified all integrations by function and use case, then matched live typing intent against that map. If you typed email the Q3 recap without an email integration connected, it suggested connecting one. If you typed write a Linear ticket and Linear was already connected, it stayed quiet.

Five different suggestion types ran in a single Jev request with a P50 of 171 milliseconds. At current pricing that is roughly 14,000 such checks per dollar.

During all testing, 17.5 million input tokens cost 65 cents. For scale, 1.7 million output tokens through a strong chat model for equivalent coverage would be well over $100, and multiple orders of magnitude slower (to the point where you would not be able to power these UX interactions in a way that any user would tolerate).

Using two models together is the point

The biggest takeaway is that LLMs and Jev combine very, very well. Think of it as: System 1 proposes and triages continuously, System 2 disposes and handles exceptions.

• Use the autoregressive model for what it is good at: complex inference, writing code, drafting instructions, resolving ambiguity, asking follow up questions. 
• Use the “System One model” – the classifier – for what it is good at: applying that understanding repeatedly, cheaply, and quickly.

A concrete example from the end of the demo: the user asked to build a support agent that answers questions from help center articles and opens a Linear issue on bug reports. 

As they typed the description, Jev classified intent in the background and began scaffolding the agent: finding the support site, enabling tools, drafting instructions. When it detected missing info, the LLM took over to ask a clarifying question, then incorporated the answer into the configuration. The classifier model assembled the answer rapidly, the LLM reasoned when the process got blocked.

What this unlocks

When every message, keystroke, search result, and agent action can be classified for intent, risk, and relevance for fractions of a cent, you can build UX that was previously uneconomical: continuous context extraction, proactive integration help, intent aware search, calm approval flows that only interrupt when risk is real, interfaces that assemble themselves as you type.

That is a new building block, not just a cheaper model. It rewards thinking like a classifier designer: what would you detect if detection cost nothing, and what would you stop asking the user once you can?

‍