I expect a lot of activity around models like Jev. They give developers a way to put language-based judgments directly into software: choose the right tool, recognize an invoice, decide whether a result needs review. Those are small operations individually, but they appear throughout the applications we build.
What interests me is the possibility of treating these judgments as programming primitives. By a primitive, I mean a reusable operation with a defined input and output that you can combine with ordinary code. If we can describe a decision in language and get back an answer the program can use, we can automate some of the behavior that previously required hand-written rules, a custom model, or a person.
Jev, released by TypeSafe AI on September 15, is an example of this direction. It brings renewed attention to classifiers, a form of machine learning that never stopped being useful. Open-source alternatives are already appearing too. I don’t know yet whether broadly capable models or smaller, fine-tuned ones will do most of this work. I do expect these operations to become a more common part of how we develop software.
The first builds give that expectation some substance. Marcel Pociot made a tool that watches his Downloads folder, identifies invoices, renames them, and moves them according to rules written in ordinary language. Nader Dabit added an urgency score to spreadsheet rows that updates as someone types. Gregor Zunic showed a browser agent selecting its next action while searching for a flight. (Downloads organizer, spreadsheet, browser demo)
In each case, the model makes a bounded judgment and the surrounding software acts on it. That is enough to build quite a lot.
What a classifier does
A classifier assigns an input to a category. A spam filter decides whether a message belongs in the inbox or the junk folder. A support classifier decides whether a ticket concerns billing, access, or a technical problem. The output can include probabilities, allowing the application to handle uncertain cases differently.
Classifiers never went away. What attracts attention here is the ability to describe many different decisions through the same language-based interface. A developer can supply the categories and relevant context without building a separate task-specific model for every new experiment.
Consider a customer message: “You charged me twice, and I still cannot log in.” A keyword rule can find “charged” or “log in.” Deciding which team should handle the message first requires interpreting the request and knowing the support policy. The possible destinations may already be known. The difficult part is choosing among them.
Jev supports three related operations. Choice selects among supplied alternatives. Score evaluates something against an ordered rubric, useful for urgency or relevance. Noul, TypeSafe’s name for its yes-or-no operation, returns the probability that a proposition is true. These cover classification, ranking, and checks that decide whether a workflow should proceed. (TypeSafe documentation)
The developer supplies text or structured textual state and defines the answers the model is allowed to return. Jev does not write explanations or accept images, audio, or video in the interface described at launch. Applications using those inputs need another component to turn them into text first.
TypeSafe calls this a “System One” model. Its launch figures put response time at 70–500 milliseconds and price at $0.042 per million input tokens, with no metered output-token charge. Those are vendor figures; the company says its latency tests generally ran near its West Coast service. (Launch announcement)
The practical question is how often a developer can afford to ask for a judgment. An overnight batch, a spreadsheet edit, and every step of a browser session have very different tolerances for delay.
Decisions inside everyday tools
The Downloads organizer starts with familiar work: files arrive with inconsistent names, and someone has to recognize the invoices and put them where they belong. Pociot’s demo connects that recognition to ordinary file operations.
Related builds apply the same idea to different records. Ryan Vogel classified and triaged roughly 1,500 personal emails. Iago Last demonstrated accounting classification of company invoices. Each application turns an interpretation into a field or destination that the rest of the software already knows how to use.
Dabit’s spreadsheet goes further by bringing the judgment into editing itself. His reported response time was roughly 100 milliseconds per row. An urgency column can therefore react while the user is entering information, rather than wait for a separate analysis step. He also showed a predictive launcher that infers intent on each keystroke.
These are early demonstrations. Their speed and cost figures are the builders’ reports, and they do not establish accuracy over months of use. They do show where developers want this capability: close to the small actions people repeat throughout a working day.
Choosing what an agent does next
Agents create their own classification work. Before answering a request, a system may need to choose a model, select a tool, decide whether to browse, or discard irrelevant material from its context.
Jack Gor demonstrated hooks for Codex and ZCode that choose between a fast and a stronger model and decide whether browsing is needed. Tamara Tran used Jev to score agent tool calls and remove irrelevant calls from context. One decision allocates computation; the other controls what information remains available for subsequent work.
Coding Garden built an assistant that routes requests to tools for web search, Wikipedia, weather, Todoist, and Home Assistant. A request can be useful to software because it identifies a tool to run. Generating a conversational response is a separate capability.
Browser control extends selection to actions. Zunic’s flight-search demo uses Jev to choose the next DOM action, while Kyle Jeong’s Stagehand demo chooses actions from an accessibility tree. Those structures describe the page’s elements in a form the model can process. Browser software performs the selected action and supplies the next state.
A browser task develops through these small choices. Selecting an action changes the page, and the next choice uses the new state. The sequence still depends on what the browser tells the model, which actions it allows, and whether the system can recognize a mistake.
Reading a collection through the same questions
Another group of builders is using Jev to ask consistent questions across large collections.
Matthew Berman analyzed 724 competitor ads across 37 brands, identifying attributes such as the hook, offer, call to action, and awareness stage. He reported 40 seconds and a cost of nine cents. Ian Nuttall applied eight questions to 3,282 X posts to investigate growth patterns. He later described using Jev for search reranking and content tagging in keep.md.
Once each ad has the same fields, an analyst can compare offers, group hooks, and see how messaging differs across brands. The model does the interpretation record by record, giving ordinary software something consistent to count and compare.
The quality of the questions matters. A category called “good ad” leaves much of the judgment unspecified. Separate questions about the offer, intended audience, and call to action give the analyst something more concrete to inspect. Even then, an appealing score is only a prediction until it is compared with outcomes.
Pociot applied classification to consumption as well, building a content filter for X that hides or collapses posts according to natural-language criteria. Here the output determines what the user sees next.
Games make the control loop visible
The research also includes Mario players, a driving simulator, and a football simulation. In atarikcaliskan’s football demo, local code generates candidate actions for 22 players and batched Jev choices drive the simulation. In umuterarsln’s driving experiment, Jev acts on clean simulator state, while a comparison uses Gemini for visual perception; the builder reports perception as the bottleneck.
These examples help separate the jobs inside a system. Representing the world, choosing an action, and executing it can be handled by different components. A model selecting from textual game state does not, by that fact alone, demonstrate that it can understand the same scene from pixels.
The same separation appears in the browser and invoice tools. What the classifier can decide depends on what the rest of the application tells it.
The open-source alternatives are already here
Several open projects are exploring the same interface. SemIf, formerly OpenJev, reads scores for supplied options directly from existing open models, with the questions defined at runtime. Featherless’s Simple Jev also turns compatible open models into classification and scoring endpoints without requiring a separate classifier head. It includes an optional training pipeline for adapting a model to the decisions an application needs.
Laya takes a trained-model approach, publishing BERT-family decision models and checkpoints aimed at different workloads. These projects offer different routes toward the same kind of component. Some use a model as it comes; others depend on specialized training, and a particular application may still benefit from further fine-tuning. Similar interfaces do not establish equal accuracy, speed, or calibration. Simple Jev, for example, explicitly says its scores are not calibrated probabilities of correctness.
We have had a version of this discussion before with smaller, specialized models and larger frontier generalists. Fine-tuning can make a recurring task cheaper or more accurate, but it creates work: assembling examples, evaluating the model, and adapting it when the task changes. A generalist may handle new categories from their descriptions, saving that preparation. Whether the specialist earns its upkeep depends on the workload and how quickly the generalist improves.
I would leave that contest open. A strong result on a tuned task does not settle performance on unfamiliar decisions, and broad capability does not guarantee the best economics for a task repeated millions of times. We need time and results from actual applications to see where each approach holds up. Either could make these primitives more widely usable.
A valid answer can still be wrong
Constrained outputs make integration easier. If the allowed choices are “billing,” “access,” and “technical,” software can rely on receiving a supported category. For the customer waiting for help, though, a valid category is little use if it sends the message to the wrong team.
Probabilities offer a way to make that uncertainty affect behavior. An application might automate a decision above a tested threshold and send ambiguous cases for review. The threshold needs evidence from the intended workload. TypeSafe’s documentation describes calibration across groups of predictions; a confidence value does not guarantee that an individual answer is correct. (System One concepts)
One of the most useful examples in the research is a partial failure. GoSailGlobal classified and scored more than 25,000 GitHub issues for signals including regression, frustration, and whether the reporter was stuck. The builder reported useful labels at the individual-issue level, but the attempt to turn them into an aggregate early-warning system failed its seven evaluated cases.
Useful classifications did not automatically produce a useful monitoring system. The way scores are combined, and the action attached to them, needs its own evaluation.
The primitives I expect to see next
I would start with one recurring decision, a clear set of possible answers, and past cases whose outcomes can be checked. Measure wrong decisions and the review work they create alongside response time and cost. A fast classifier that repeatedly sends work to the wrong place can make a process more expensive.
But my interest extends beyond that first classifier. I expect more reusable operations for interpreting requests, selecting actions, checking results, and deciding when to ask for help. Some will be powered by general models, some by fine-tuned specialists. Developers should increasingly be able to specify the judgment they need and connect it to the rest of the program.
That can automate parts of software development itself. A developer who would otherwise build and maintain a collection of rules for interpreting customer requests could instead define the available routes, supply the policy, and test the resulting decisions. Coding agents can use the same components to select tools or flag work for review. The developer still has to define acceptable behavior and handle failures, but less of the interpretation has to be implemented case by case.
This is where I expect to see a lot of building. Jev has supplied an early set of examples, and the open-source projects are already exploring other ways to provide the same operations. I will be watching which of these components developers keep using after the demos, and how much custom logic they actually replace.