Rebuilding our agent with Jev as a core primitive

← Nym Technical Blog Jev is a new model from TypeSafe that has quickly caught fire in SV and beyond as a new primitive in the agentic engineering tool belt. What is it? What can it do for you? Well we're going to walk through how in the last few days we've rebuilt our agent's decision-making around this new primitive, reduced our generative-model costs and increased our agent's speed while keeping our safety and security controls in place.

Writer's note: I've been up to 4am several nights in a row working on this, sleep is important but the potential was just too great not to press on.

First Jev for all the marketing hype is a super fast classifier model with a parallel serving implementation. You give it state, questions and the possible answers, and it returns typed decisions with probabilities and confidence. TypeSafe describes its training approach as Reinforcement Learning for Calibrated Decisions, with outputs produced in parallel rather than generated token by token. Their introduction goes into the details.

That confidence score is one of the keys that makes it useful. You can use it to determine when you need more context, ensemble multiple Jev requests or finally kick over to a larger model for further review. This gives you a way to decide in code which decisions to automate and which ones need another look, with thresholds you evaluate against your own tasks.

From a product perspective this makes it a rock solid primitive you can quickly slot into what you're building for guardrails, decision making like tool selection and general classification. Instead of gathering a bunch of data and training a classifier that in the age of agents will quickly run into out of distribution cases, you can describe the decision you need and evaluate it directly. You still own the evals, but you don't have to build a separate training pipeline for every new judgment your product needs.

What has it meant for Nym's previous classifiers? #

What has this meant for us here at Nym? Well Nym is a consumer agent (join the private beta) that is meant to help you run your life. Nyms shop for you in the browser, make you tools to help you manage your day to day life, email people, text and more. Speed and correctness as well as security and trust are key product requirements for us that help our customers accomplish their goals and build trust in us.

This means every time you make a request to Nym we have a bunch of classifiers running that help determine whether the Nym needs to ask for your approval and prevent scenarios where Nyms would misuse sensitive information like credentials or credit cards. The seven text-based reviewers we replaced were previously running on Gemini 3.1 Flash Lite. Our spending limits and credential and purchase authorization checks are still enforced in code, the replacement is the classifier that feeds those checks.

Gemini Flash is not a bad model, but it's an LLM. LLMs autoregressively generate tokens, often one at a time. They rely on prefix or KV caching to reduce repeated processing of previous tokens, but still do calculations for each new token. This makes them slower for these classification tasks than a model that produces its decisions in parallel.

Jev is one such parallelizable model and in our case we experienced a 4.1–5.7× speedup in median reviewer latency by switching to it. Not only that, Jev beat our previous Gemini classifiers on several evaluations.

To check this we ran both implementations through the same evaluations, covering approvals, credentials, checkout, abuse and the other decisions Nym makes while working. This gave us 167 calls across 88 distinct inputs with Jev passing all of them.2

The Gemini implementation had four errors and three wrong answers here compared to zero for Jev.

Taking it further: Using Jev for computer use #

It's no secret that Jev has potential to speed up computer use and we've done that exactly with Nym. Our previous implementation had a typical agentic loop where DeepSeek received initial context, then on each turn selected batches of tools to use, up to and including browser actions. This is pretty standard and it's how a lot of computer use loops work.

Now we've replaced this with a browser_use tool that receives a goal and then separately executes using a combined loop where Jev decides actions and targets from the page view. If it's uncertain the controller can get a fresh observation, and if Jev is still uncertain it falls back to DeepSeek with the observations and actions taken so far.

In the case a resulting action requires a text fill we call out to again a separate LLM to generate the fill.

It's also interesting to mention that during browsing we run several (now Jev based) classifiers that review potentially abusive actions by the agent, credential release and checkout state. These work with our sensitive-field protections that control what the agent can see and fill and our pre-checkout flow.

A more complex shopping task, side by side

Here's the request I used for the side by side shopping video:

hey can you grab me a couple of men’s xl shirts from quince I like the work shirt style and tshirts also want some matching blue or black chinos or jeans w38 l30 add them to the cart

For this I used two fresh Nym instances with the same browser infrastructure and Guardians. This is a more complex shopping request than our Quince benchmark below which just navigates to the men's section. The Jev implementation handily won this one, taking fewer turns and less time and actually landing on the type of shirt I wanted to buy, a utility shirt, even though I ambiguously referred to it as a work shirt.

Taking it EVEN FURTHER: Using Jev to drive tool selection in the main loop #

This is where it gets even more interesting. What if you could apply this to all the tools your agent uses? Having already discussed our former general agent loop in the previous section I won't do so again here. For Nym that includes working with files and scheduled tasks and making tools as well as computer use.

In our implementation we now replace per turn tool selection with a Jev call that receives the context and available tools and returns probabilities and confidence that determine whether to use the selection and have the LLM generate the actual call or fall back to DeepSeek for the decision itself. For routine argument generation we turn off thinking and keep the conversation and model route consistent, letting the LLM reuse the cached prompt prefix and reduce the work required to generate the call while retaining the full reasoning path for decisions that Jev isn't confident about.

This resulted in 41 generative-model calls compared to 72 which is about 43% fewer calls and both versions reached 100% completion on our 17-task benchmark. Times below are in seconds.

Across these 17 tasks, Jev + DeepSeek finished 4.0% faster and reduced generative-model spend by 36.0%. Including estimated TypeSafe charges brings the combined model saving to about 15%.1

Some of what people ask for doesn't exist yet, and solving it means Nym quietly building a piece of software for that one person's problem. We tested five requests that resolve this way and the speed improvement was larger, with both versions delivering all five:

Across the five this took 17.1% less time, measuring all the way through to the finished thing in the person's hands. Another comparison covered the same five and cancelling one during publication and both systems passed all six cases with 1,247.741s for Jev + DeepSeek versus 1,325.586s for DeepSeek alone. After we added eight more tasks to the general suite, a later run reached 25/25 passing.³ This gives us a decision model that works across several of Nym's capabilities and keeps DeepSeek available for generation and decisions requiring further review.

And this is to go even FURTHER BEYOND: Using Jev to select and recursively expand context #

This is the next thing I want to try. For a persistent agent like Nym, your conversation history and memories as well as files and app state are all potential sources of context that need to be selected before the model can work on your request.

Currently for our context selection we have a custom search and ranking system that combines classic text and vector search. It recursively packs the context up to a certain token limit and includes concessions for recent task context without modification. This system works well, but can be slower and lossy.

As part of this system we maintain different levels of representation of the chat history. These representations include facts and excerpts which all have references back to the full messages. Using this system the idea is to run Jev in a sliding window over the cheapest representation, the excerpts, and first pick them using a weighting between Jev and classic search signals. After picking the relevant excerpts there would then be subsequent passes to choose whether to expand the excerpt to a full facts list and then whether to expand the facts list into the full fidelity stored messages.

For shopping you need preferences and sizes. For a change to an app you need the existing app structure and the requested behavior and probably don't need yesterday's shopping conversation, even though both requests belong to the same person and go to the same agent. To evaluate this we would need to check that the necessary context gets selected and that the extra classification calls save time over the full task.

This is what makes Jev interesting to me beyond the individual speed ups. The same primitive that replaced our existing classifiers can select browser actions and tools and potentially the context those decisions depend on.

Classifiers as a decision primitive for agents #

It's clear to me that we'll see many Jev like classifiers in the future and perhaps even dual interface autoregressive / fast decision models that let us combine both worlds. Overall Jev has been very successful for Nym over the last few days and will be making its way to prod.

Remember if you want to sign up and check Nyms out you can join the private beta. I'd love to hear how Nym helps you achieve your personal goals.

1. TypeSafe costs are estimated from its hourly usage export, allocating that hour’s 3,739,497 input tokens across the runs in proportion to their logged request counts (226 and 86 out of 600). This assumes equal average request sizes. At TypeSafe’s published rate , the estimated combined saving is 14.6%. The export does not separate individual requests; browser and VM costs are excluded. A separate run of the same 17 tasks on a later software version, with provider-reported TypeSafe token usage, measured combined model costs of $0.38332 versus $0.45035, a14.88% saving , with both versions passing 17/17. One rejected TypeSafe request returned no usage and its unknown cost is excluded.↩
2. Smaller case sets were repeated to produce 167 calls across 88 distinct inputs. Latencies include the classifier request and response processing, excluding context retrieval and action execution. Passing this set does not establish correctness on all future inputs. ↩
3. These comparisons used separate runs and software versions; the six-case app run used a different browser implementation. Totals sum individual task durations; tasks ran across four fresh agents in parallel. The later 25-task run took 249.160s for the original 17 cases and 72.662s for the eight additions. Its app rerun failed in five cases after repeated OpenRouter network errors. App tables above report separate successful runs; results vary with software version and service conditions. ↩