More than 1,300 public builds appeared in the first days after launch. Here is what they actually do, what they cost to run, and which of them are businesses rather than demos.
Jev is being used for small decisions made at volume. Classifying, routing, scoring, filtering, picking the next action. Not writing, not thinking out loud, not holding a conversation.
It has been out a week. Community catalogues have tracked well over a thousand public builds already, which is enough to see a pattern rather than guess at one. If you want the mechanics first, our explainer covers what Jev is and how it differs from a language model. This is about what people have pointed it at.
Any decision where you can write the possible answers down in advance. That constraint sounds limiting and mostly is not, because a surprising share of the work inside software is exactly that shape.
The builds fall into four families. Sorting things into categories. Scoring them against a rubric. Answering a yes or no about them. And choosing the next step from a list of available steps. Everything below is one of those four, repeated a lot.
The obvious ones arrived first: browser agents choosing which element to click, support triage, guardrails on message pipelines. Those are covered in the explainer. The more interesting builds are the ones nobody would have bothered doing at frontier-model prices.
One builder ran twenty-one questions over each of thirty-seven documents and paid a cent for the lot. Another grouped 1,018 AI papers by topic for eight cents.
The work is the same shape either way: a fixed set of questions asked of every item, where the answers were defined before anything was read.
Seven hundred leads scored in forty seconds is the published figure, with a confidence attached to each so the uncertain ones could be separated out.
The useful part is not the speed. It is that the same rubric gets applied to the seven hundredth lead as to the first, which is not true of a person at 4pm on a Friday.
People have built real-time filtering into their own browsing: labelling timeline posts as substance, humour, promotion or junk, and flagging machine-written text while scrolling.
The same approach classifies page elements to strip advertising, deciding element by element rather than matching a blocklist someone else maintains.
One build answers questions against PostgreSQL tables without embeddings or a vector store, using typed decisions to narrow down which rows matter.
That removes an entire piece of infrastructure from a search feature, along with the re-indexing job that usually comes with it.
A router sits in front of several language models and picks the tier the question actually needs, sending simple queries to something small and only escalating when it must.
The routing decision used to require a model call of its own, which meant paying frontier prices to decide whether to pay frontier prices.
Little enough that the cost stops being part of the decision. That is the actual change, and it matters more than the latency.
A check you could not justify running on every record becomes one you run on all of them. That is a different question from "can we afford to automate this", and it is the one worth asking.
The games are demos. Jev has been wired into Doom, Super Mario, Subway Surfers and chess, and it plays them by scoring the legal moves every frame. It is a genuine demonstration that the latency is real. It is not a business.
The businesses are the boring ones. A useful test: does somebody currently make this judgement by hand, repeatedly, using a rule they could write down if asked? Ticket triage passes. Lead scoring passes. Invoice review passes. Anything where the interesting part is producing a sentence does not, because that is still a language model's job.
Shadow mode. Run it beside whatever you do now, let it decide nothing, and compare.
The second check is the one people skip. A model that is right 85% of the time but cannot tell you which 85% is far less useful than one that is right 80% of the time and knows when it is unsure.
The limits are consistent across the builds. It reads questions literally and misses nuance. It is unreliable at arithmetic, counting and comparing numbers. Dates and anything temporal are not its job.
The one that catches people out is subtler: accuracy drops when the state you hand it contains irrelevant information. Getting good results is mostly about trimming the input down to what the question actually needs, rather than wording the question more cleverly.
Whichever judgement somebody on your team makes more than fifty times a week. In most businesses we look at, that is the inbox.
Is this a bug or a billing question. Is this lead worth a call. Does this invoice need a human. Has this supplier document got the clause in it. Each is a typed question with a known set of answers, each is currently done by a person, and each gets done slightly differently depending on how busy that person is.
That inconsistency is usually the real cost, not the minutes. The point of putting a model on it is not speed, it is that the five hundredth one is judged the same way as the first.
