Jev is hot, but Jev isn't what matters | 5Y View

On September 15, TypeSafe AI released its first System One Model — Jev.

Unlike ChatGPT, Claude, and other models that complete tasks by generating text token by token, Jev abandons open-ended generation entirely: given a state and a set of preset candidates, it directly returns a choice, a score, or a probability for software to consume. TypeSafe claims it can push decision latency down to 70–500ms in specific workflows.

After launch, Jev quickly drew attention in the developer community. Vercel data showed that within 24 hours of integration with AI Gateway, nearly 13% of paid teams were using it — making it the fastest-adopted new model on the platform.

Jev's rise has also brought a long-default premise back into discussion: when we simply need a model to make a judgment, should we still have it generate a block of text first?

The following article comes from Xing Meng's notebook, by Xing Meng:

---

Over the past few months, I've been tracking model acceleration. In non-programming scenarios, I believe model speed is the single biggest bottleneck limiting application adoption.

TileRT operates at the runtime layer. DFlash attacks speculative decoding. DiffusionGemma goes after the generation paradigm itself. All three share the same implicit premise: we still ultimately need to generate — we're just trying to do it faster.

So when Jev blew up these past few days, I initially placed it on this same continuum. But after digging in, I realized it's asking a different question: what if I don't need generation at all?

Jev comes from TypeSafe AI. Founder Diogo Almeida is an interesting figure — he was among the early participants in OpenAI's RLHF and InstructGPT work. In a sense, someone who helped make models better at "talking" has now built a model that barely talks.

To help everyone understand, let me use "investment research" as an example.

When evaluating a company, a founder will give me a complete technical explanation: why they chose this architecture? Why is their approach better than industry standard? Why does a particular benchmark validate their thesis?

But as I dig deeper into papers, code, and competitors, I find that external information and the founder's claims point in nearly opposite directions.

At this moment, what I actually need isn't an AI that writes a 3,000-word analysis. I need a judgment: should I keep investigating, press the founder directly, find an external expert to cross-check, or is this contradiction serious enough that I should deprioritize the project?

The inputs here are actually quite complex. The model needs to understand the founder's technical claims, the counter-evidence I've found, the credibility of sources, whether both sides are even discussing the same thing, or whether this contradiction might simply be definitional. Yet the final software action might only have four options.

The most natural approach today is to dump all this material into a large language model, have it analyze everything, then generate token by token:

{"next_action":"ask_founder"}

Then the software maps this string back to an action.

What truly strikes me as odd: to complete a judgment, we boot up a machine optimized for open-ended generation, have it "say something," then translate that sentence back into the world of software.

To eventually make an investment decision, the system internally needs to complete countless smaller judgments first: is this new arXiv paper worth checking the author; is this new GitHub repo a toy or does it signal startup intent; is someone's LinkedIn change worth tracking; should a project intro from a friend be ignored, added to a watchlist, flagged for a colleague, or immediately trigger deep research.

You might only "pull the trigger" a handful of times per year, but to get there, you may need to make tens of thousands of "is this worth another look" calls.

At this point, whether one judgment takes 500 milliseconds or 50 milliseconds, whether it costs a cent or one ten-thousandth of a cent, becomes a completely different systems economics. Trigger-pulling is low-frequency; aiming is high-frequency. What actually consumes the most intelligence isn't usually those final few big decisions, but the countless tiny screenings, routings, and attention allocations before them.

Jev's approach is far simpler: give it the current state and a few candidates, it directly returns probabilities over those candidates. TypeSafe defines it as "unstructured state in, typed probabilistic decisions out," emphasizing that it's not ordinary autoregressive string generation, but a model and sampler designed specifically for decision-making.

What genuinely interests me about this isn't whether Jev will become a big company. It's that it exposes a premise we've grown so accustomed to that we no longer question it: a universal interface does not equal universal computation.

Why generate tokens one by one just to make a choice?

One of the foundation model's biggest successes in recent years was finding a universal interface: the token.

Previously disparate tasks could now be reframed as generation problems. Spam detection? Generate "spam." Model routing? Generate "use Claude." Math reasoning? Generate a chain of thought. One Transformer, one next-token prediction, handling problems that once required separate AI systems.

Roughly speaking: anything → tokens.

This unification is enormously important. But the fact that a task can be expressed through the same interface doesn't mean it's best served by the same computational approach.

Back to the investment research example. Faced with complex evidence, I need to judge where to spend my time next.

A standard LLM can use constrained decoding to guarantee valid JSON output. But underneath, it's still autoregressive generation: one token after another, with each waiting for the previous. A model purpose-built for decisions can directly evaluate several candidates and produce a result.

Both methods might ultimately conclude "press the founder," but the computation looks radically different.

TypeSafe's numbers are therefore eye-catching: Jev's end-to-end latency is roughly 70–500ms; in specific workflows tested officially, speedups range from several dozen-fold to nearly 200x; pricing is $0.042 per million input tokens, with output free.

But speed and cost alone aren't enough to judge its value.

Across TypeSafe's own four workflow benchmarks, Jev averaged 67.8% accuracy — roughly on par with GPT-5.6 Terra's 67.9%, but below GPT-5.6 Sol's 74.1% and Claude Opus 5's 73.1%.

In other words, its value is closer to this: taking a certain level of "good enough" judgment capability and making it faster and cheaper. It doesn't raise the ceiling on model capability.

Developer Kyle Jeong shares his experience testing Jev for browser operations

These benchmarks have their own limitations. TypeSafe didn't use human-verified ground truth, but rather used stronger models' outputs as reference. In another Wikiracing demo, to control for latency, most competing LLMs had reasoning mode disabled, and Astra used only minimal reasoning intensity. The company itself acknowledges that with reasoning enabled, these models would perform noticeably better.

So Jev's genuinely interesting aspect can't be simply summarized as "equally smart, but 200x faster." The more precise framing: for a class of well-scoped, frequently-called, limited-candidate judgment tasks, we may have been paying unnecessary costs for general-purpose generation capability.

Of course, from a computational standpoint, the boundary between generation and selection isn't perfectly clean. Every token an LLM generates is itself a selection across the vocabulary; classification tasks can certainly be done through generation.

But "can simulate each other" and "suited to the same computational method" are two different things.

Database queries, video decoding, and matrix multiplication can all run on general-purpose computers. We still design different data processing approaches for them, even dedicated hardware, because it computes faster and cheaper.

The same applies to AI. What's worth discussing: how should a task be decomposed into steps, and what method should each step use, to achieve sufficiently reliable results at lower cost and higher speed?

From "generating answers" to the "four basic operations" of intelligence

Following Jev downstream, you find many differently-named tasks actually doing similar things: given current state and a set of candidates, judging which is better.

Reranking picks more relevant documents from a set. Model routing selects a more suitable model for a task. A verifier judges whether an answer is correct. A reward model scores different outcomes, helping the system determine which are worth keeping.

I'll tentatively call these actions SELECT. They all answer one question: in the current situation, how good is this candidate?

What's interesting about Jev is its attempt to combine LLM flexibility with classifier-style execution. Traditional classifiers are fast, but which categories they can choose among is usually fixed at training time. LLMs can receive new questions and new candidates on the fly, then answer through generation. Jev wants to do this: questions and candidates can vary dynamically, and the model gives a direct judgment.

This approach also makes outputs more controllable. TypeSafe's claim of "no hallucination" needs to be understood in this sense: with only candidates A, B, and C, the model won't suddenly output D. But it might still confidently choose the wrong A. Output within bounds doesn't mean the judgment is correct.

However, selection has another more important boundary: where do candidates come from?

Back to investment research. When external information conflicts with a founder's claims, we can have the model choose among "press founder, find expert, keep researching." But to judge what to do next, you often first need to figure out: what might this conflict actually mean?

Is the founder wrong, or is the external material outdated? Are the benchmarks incomparable, or are both sides using different definitions?

If the correct explanation never enters the candidate set, no matter how accurately the model selects, it cannot select it.

The action of proposing these possible explanations, I'll call PROPOSE.

An efficient reasoning system likely operates in cycles of these two actions: propose some possibilities, eliminate some, then along promising directions propose new ones. AlphaEvolve has a similar loop: generator proposes programs, evaluator runs and checks them, evolutionary search decides which candidates merit another round.

But having candidates doesn't mean you can immediately select.

We also need to organize evidence from different sources, determine whether they're discussing the same thing; and consider, if a certain explanation holds, what consequences follow. This involves two more actions: REPRESENT and PREDICT.

Thus, an investment research process can be decomposed into four operations:

REPRESENT: Organize materials into comparable information. What time, technical conditions, and evaluation standards do the founder's claims, papers, code, and competitor results each correspond to?

PROPOSE: List possible explanations. Is the information conflict due to flawed technical judgment, outdated materials, or definitional differences?

PREDICT: Project consequences of different explanations. If the founder's technical judgment is wrong, how does that affect product performance, cost, and competitive position?

SELECT: Judge what to do next. Is current evidence sufficient? Should I keep investigating, press the founder, find an expert, or deprioritize the project?

I'm not saying intelligence has only these four operations. The more practical idea: these operations solve different problems, likely have different computational requirements, and therefore merit separate optimization. Today, we often hand all this work to an LLM, completing it through text generation. Only by breaking them apart can we clearly see: which steps need powerful generation and reasoning capability, and which can be delegated to faster, cheaper specialized computation.

This brings the next question: if Jev makes SELECT fast enough, does the whole system speed up? Or do we finally see where time is actually spent?

The model thought for 0.2 seconds. Where did the rest of the time go?

Aaron Levin recently built a macOS computer-use agent based on Jev. In this experiment, Jev takes roughly 0.13–0.38 seconds per decision, while Claude Opus 5 needs about 5.2 seconds — a 14–40x difference at the model decision stage.

But this agent takes about 1.5 seconds to complete one action.

Where does the extra second-plus go?

Before Jev can judge, the system must first take a screenshot, recognize text, organize text into blocks, read buttons and input fields in the interface, confirm cursor position, which application and URL are open. For error-prone information like dates, it needs advance conversion to explicit, unified formats.

Only after this preparation can the model answer: what should I do next?

Once SELECT gets faster, REPRESENT's time cost becomes visible. The model can choose quickly, but the system hasn't finished preparing the question.

Previously, we'd hand a screenshot directly to a powerful model and have it return the next action. In this process, interface recognition, state understanding, and identifying available actions were typically bundled inside a single model call. Now that selection is isolated and optimized, it becomes easier to see: how much work precedes the model's judgment, just to enable it to decide.

This is also the investment question that interests me more: if the next bottleneck is "organizing the world into a form the model can judge," who solves it?

Today, this work is scattered across different tools and teams' code. Some read interface elements through accessibility trees, some extract webpage DOM structure, some rely on OCR and layout analysis. Every agent team also handles on their own: which information to preserve, which buttons are actionable, whether previously read state is stale after page changes.

This work seems trivial, yet directly determines whether the model gets a chance to choose correctly.

It's much like RAG: no matter how strong a reranker is, it can't rank documents the retrieval stage never found. If a button isn't recognized and doesn't enter the candidate set, the decision model can never select it.

Browser Use's recent jev-ultrafast is already trying to make this pipeline more efficient. It reads current webpage state through a browser harness, letting Jev simultaneously choose "what to do" and "which element to act on" in a single request; only when text input is needed does it call a small generation model to write the specific content.

Its Google Flights demo, from receiving a natural language goal to opening the results page, takes about 7 seconds. But the project readme also lists unsolved problems: nested pages, canvas content, multi-layer scroll areas and other complex cases still create difficulties for interface reading and operation.

Demo video from Gregor Zunic

This shows that turning a webpage into a reliable "multiple-choice question" is itself a non-trivial engineering task.

Whether this forms an independent large market, I'm not sure. Browsers, operating systems, and agent runtimes may gradually standardize these capabilities; or specialized perception and state infrastructure may emerge, responsible for understanding pages and desktops, organizing available actions, and continuously updating state, so every team doesn't have to rebuild from scratch.

From this perspective, the value of an Agent Harness becomes clearer: it's responsible for organizing real-world environments into problems the model can process, and translating the model's judgments into executable actions. The runtime coordinates, deciding when to call which capability.

Actual systems may therefore evolve toward this division of labor: what can be handled by deterministic code, goes to code; well-scoped judgments go to cheap decision models; when writing is needed, call a generation model; for complex problems, escalate to stronger reasoning models, with human handoff when necessary.

The more specialized the model, the more the system needs to prepare the problem correctly and assign work appropriately. Jev accelerates one link in the chain, and makes the surrounding work that was previously invisible become more important.

Will large models "re-absorb" these specialized capabilities?

In AI history, specialized structures losing to general methods has happened too many times. Richard Sutton's The Bitter Lesson observes that what wins in the long run tends to be general methods that can continuously leverage more compute and learning, not carefully designed rules for specific problems.

Is Jev just another round of fleeting specialization?

Every token a standard LLM generates already computes scores across vocabulary options. When candidates are simple enough, you can directly compare candidate token probabilities without waiting for full JSON generation. Introducing a separate model反而 adds deployment, evaluation, confidence calibration, and version management costs.

Rerankers offer a reference point. They're more efficient than having a large generation model read search results one by one, yet haven't replaced generation models in RAG: filtering existing documents and organizing answers remain different jobs.

So I'm not sure whether Jev will persist as an independent model category. It may be absorbed by foundation model providers, becoming a dedicated decision module, a reasoning mode, or another execution path within the same backbone.

This makes the article's judgment more precise: what's truly worth betting on is computation specialization. Whether the model remains independent is a separate question.

Represent, propose, predict, and select can be done by four models, or share one foundation model. What matters is whether different operations employ different training objectives, data processing methods, and execution paths.

The Bitter Lesson may foretell many independent small models being absorbed, but this doesn't mean all operations must ultimately proceed token by token. Even if Jev no longer exists independently in a few years, as long as agents begin adopting different computational paths for different operations, the shift has already occurred.

Models can reunify; computation can still divide labor.

With the same model, why do agents still differ so much?

Sharing underlying capabilities while letting different tasks execute separately — this thinking isn't new. In the CNN era, there were shared backbones with specialized modules. In the agent era, systems can also dynamically adjust candidates and execution paths during operation based on the task.

Research is pushing this division from multiple directions. UC Berkeley's Compound AI Systems emphasize that product capability comes from the combination of models, retrieval, tools, and programs; AlphaEvolve separates generation from evaluation; JEPA and world models explore predicting future states in internal representations; Jev extracts decision-making from generation.

These aren't the same path, but all point to one thing: completing intelligent tasks can involve richer computational approaches than repeatedly calling a generation model.

This also changes how we evaluate AI products. Today people often ask: "Do you use GPT or Claude under the hood?" A more valuable question going forward might be: "For completing a task, how do you organize each step of computation?"

Riley Brown shares his experiment using Jev for agent model selection.

I call this organizational structure an Intelligence Graph: which steps propose solutions, which verify and filter, how they connect, and when to call stronger models.

Using the same advanced foundation model, one coding agent might first propose multiple code modification plans, use a low-cost verifier to eliminate most candidates, then hand the few hard problems to a stronger reasoning model; another agent might call the most expensive model at every step. Same underlying model, yet cost, speed, and reliability can diverge dramatically.

A product's own technical accumulation may increasingly show in these arrangements: how candidates are constructed, when to expand search versus prune branches, what state information to retain, what confidence threshold enables autonomous execution, how to recover from failure, and how to use execution records to improve next-round performance.

These seemingly trivial harness tasks may gradually constitute an agent's most important capability architecture.

What model you use determines what capabilities you can access; how you organize computation determines how much of those capabilities you can actually deploy.

If this judgment holds, what happens next?

I think we can watch for six changes in the coming years.

First, AI interfaces will expand from "generating text" to directly completing different operations.

Judge, verify, route, predict, and search will increasingly become directly callable capabilities. They can share the same foundation model, but need not all be completed token by token.

Second, reasoning will no longer rely solely on longer chains of thought.

Candidate generation, verification, branching, backtracking, and search will take on more reasoning work. Some of this may even happen directly in latent space, without being written out as text.

Third, internal model division of labor will become clearer.

Generators, verifiers, decision models, world models, and policy models will gradually form distinct roles. I'm more certain that operations will differentiate; whether they become independent models remains an open question.

The last three, I think, haven't reached consensus yet.

Fourth, agent competition will increasingly turn on: where to spend compute.

Context engineering focuses on what information to provide the model; intelligence orchestration also decides at which step of a task to call which capability.

When is it worth proposing more solutions, when can you select directly, when do you need to predict consequences, when should deterministic code handle it, when should you escalate to a stronger model? These arrangements directly affect cost, speed, and success rate.

Fifth, the token may no longer be the universal unit for measuring AI cost and output.

Tokens work well for measuring how much content was generated, but poorly capture the value of a judgment, a prediction, or a search. Interestingly, Jev still charges by input token today: computation is starting to change, but billing habits lag from the generation era.

If selection tasks reach sufficient scale, we might care more about: at target accuracy, how many judgments per dollar, how many requests per second. World models might focus on simulated time per dollar; search systems on tasks solved per dollar.

Sixth, computation specialization may gradually enter model architecture, and eventually hardware.

This is the one I'm least certain about, and most interested in. It requires gradual accumulation:

Distinguish tasks via prompt → train specialized models or modules → optimize compute architecture → design dedicated hardware.

Further down the line, investment grows larger, and requires sufficiently stable, sufficiently massive demand to sustain. Distinguishing judgment from generation via prompt is cheap; training separate models is much more expensive; redesigning architecture or chips requires large enough call volume for the economics to work.

Therefore, what's more worth watching now is: can selection, verification, and world prediction form stable, massive computational workloads? Do their memory access patterns, parallelism, and latency requirements differ meaningfully from autoregressive generation? If the answer to both is yes, specialization has motivation to push deeper into hardware.

This gives a test: if in a few years, decision, prediction, and verification are still just the same autoregressive model with different interface names, with no substantive change in training objectives, execution paths, or cost structure, then so-called new primitive operations are likely just packaging.

Conversely, if these operations begin forming their own computational methods, Jev's recent buzz is only a beginning. What's more notable is that it made us re-examine a taken-for-granted premise:

Can be expressed through generation, does not mean should be computed through generation.

Generation is just one operator of intelligence.