Meet Jev: AI decisions in milliseconds, at $0.042 per million input tokens

Start with the 45-second video

Matija Sošić explains the idea in the original video below. Watch on X if the player does not load.

A customer writes: “We've been charged twice, and nobody has replied since Monday.”

Before someone answers, a support system has several decisions to make. This belongs in billing. It may need escalation. There is a possible refund request. The customer is frustrated. None of those decisions requires a paragraph of beautifully written prose.

On September 15, TypeSafe introduced Jev, an AI model built around that kind of work. The company reports 70–500 milliseconds per request. Its direct API lists $0.042 per million input tokens, with output free. Those are different kinds of claims: the price is a published rate; the latency is a reported range, largely measured from the US West Coast, rather than a worldwide guarantee. Launch announcement, model card.

Within days, builders were showing document classifiers, browser controls, agent-memory selectors and games. The variety makes more sense once you understand what Jev returns: answers to questions with a defined set of possible outcomes.

A model you give a form to fill in

Imagine handing someone the customer's message and a small form. One field asks for the department. Another asks whether a refund is requested. A third asks how urgent the issue is, using a rubric you supplied.

Jev works through a similar contract. Your application provides the evidence, called its state, plus questions and allowed answers. State can contain ordinary text or structured records. The application receives values it can use in its existing logic. State documentation.

There are three main answer types:

• Noul: a probability for a yes-or-no question. For example, whether the message requests a refund.
• Choice: a selection from permitted options, such as billing, technical support, sales or manual review, together with a probability distribution.
• Score: a result across ordered levels you define, such as a severity scale with a concrete description for each level. The returned score reflects probabilities across those levels.

These are different questions. A 0.5 probability that a refund was requested means uncertainty about whether it happened. It does not mean the customer asked for half a refund. Noul, Choice, Score.

Your code then decides what to do. It can send a ticket to billing, ask a person to review it, or collect missing information. Jev supplies the judgment; the application supplies the permissions and performs the action.

That last distinction explains many of the launch videos. A model choosing “tap this button” still needs another system to find the button, tap it and check what happened.

Several questions can share one reading

The support system does not need to ask for the department, wait, ask about refunds, wait again, then ask about urgency.

Jev can evaluate multiple questions against shared evidence in parallel. The questions are independent: one answer cannot secretly become the evidence for another answer in that same request. If a later decision genuinely depends on an earlier result, the application needs another stage. Parallel decision pattern.

This matters because software often needs several small judgments about the same input. Repeatedly sending the customer message to separate calls adds waiting and repeats input. In one official, older-version example, asking 13 questions together took 0.27 seconds and $0.000497, versus 2.71 seconds and $0.006090 separately. That compares two ways of calling the same system, not Jev against a competing model. Batching example.

TypeSafe calls this family “System One models” and describes training for calibrated decisions. The name borrows from fast human judgment. It is a product category and training claim, not evidence that the model works like a human brain. TypeSafe's explanation.

The useful question for a builder is more concrete: which parts of this application need an answer from a known set?

The public interface is clearer than the underlying architecture. Archer Hume has published a reconstruction based on API probes, but explicitly labels parts of it speculative. It is useful technical reading, not a disclosure of TypeSafe's internals. Open-source integrations should also not be confused with downloadable model weights. Architecture investigation.

Cheap and fast change different things

For an interactive application, latency determines whether a decision can happen while someone is using it. A slow decision might be acceptable in an overnight report and unacceptable between every click.

For an archive, cost determines how much material is worth examining. A business might check today's messages but leave years of old conversations untouched. Lowering the cost makes it plausible to revisit those records whenever the business has a new question.

Here is the arithmetic behind the price. At $0.042 per million input tokens, a request containing 1,000 total input tokens costs $0.000042. A million such requests would cost $42 in Jev input charges. Tokens are the small chunks into which text is divided; a token is not necessarily a word.

This is an illustration, not a measured workload. A 10,000-token request costs ten times as much. Questions and candidate descriptions also consume input. Repeating context, retrying failures and asking additional questions increases the bill.

The rest of the system still costs money. Retrieving documents, reading scanned pages, generating replies, running a browser and reviewing mistakes are separate work. Free output also does not mean unlimited free computation: Jev's answers are bounded decisions, and rate limits still apply.

Three results worth looking at closely

The launch-week examples are useful because they show where a decision fits. Their evidence varies, and I have not rerun these experiments.

Revisiting 20,000 business records

Zac Gawn reports classifying 20,000 emails, Slack messages and transcripts in seven minutes for $1.45, looking for categories including complaints, upsells and missed follow-ups. The report does not provide an inspectable dataset, accuracy evaluation or complete cost breakdown. Original report.

The idea is easy to picture. A business launches a service and wants to find past conversations where someone needed it. The old records have not changed. The question has.

That is a useful reason to run classification again. It is also why “we already tagged our archive” may become a less convincing stopping point. The important test is whether the newly found conversations are actually useful, including the ones the classifier misses.

Choosing the right memories for an agent

Aera tested which saved information an assistant should recall. On 276 unattended cases within an offline study, Jev matched 46% coverage, improved precision from 79% to 85%, and reduced median selection time from 463 to 147 milliseconds. Reported cost fell from $0.00028 to $0.00017 per case. Aera's study.

Coverage describes how much useful information was recovered; precision describes how much of the selected information was useful. Together they prevent “faster” from hiding a selector that simply returns less.

The study used one working profile and automated judgments, and it was explicitly an offline experiment rather than a shipped integration. Its narrower lesson is valuable: retrieving an existing memory can be a selection task, so a model does not necessarily need to generate text to do it.

Deciding which PDF pages need OCR

OCR reads text from images. A mixed PDF may already contain usable digital text on some pages, while scanned pages need extra processing.

In the doc-router author's test of 19 documents and 155 pages, routing reduced reported cost from $0.3100 to $0.1783 and time from 35.578 to 20.666 seconds. But it also missed nine pages that needed OCR. Code and measurements.

This is the result I would keep beside every impressive cost chart. The cheaper pipeline produced a quality trade-off. Whether that trade-off is acceptable depends on the documents and what happens when text is missed.

Why the demos look much broader than classification

Browser Use reports a 7.073-second Google Flights search, with 178-millisecond median Jev request latency. The clock excludes browser setup, initial navigation and independent post-run verification. Jev chooses browser actions from structured page information, while a separate small model supplies text to type. The demonstration finds flight options; it does not complete a booking. Browser Use's measurement notes.

The mobile-jev project follows a related pattern on Android. Its Uber demo reaches payment selection in about 21 seconds across nine actions. Mobilerun observes and operates the device; Jev chooses from the available actions. Again, reaching payment selection is different from buying the ride. Mobile project.

The same separation appears in games. Sprite Fusion's prototype asks Jev to choose terrain properties and lets game code place them. Its author reports 319–375 milliseconds per request and an estimated $0.00286 for the five-request demo. Jev does not draw the art or write the engine. Developer's walkthrough.

An interface builder can similarly choose from existing components. A document system can choose the right folder. A research workflow can rank questions someone else generated. The visible outcome changes because the application around the model changes.

The companion Jev use-case field guide follows those applications, including the smaller experiments and proposals that do not yet justify a headline benchmark.

A valid answer can still be wrong

Jev's constrained answers remove a particular problem: software receiving an answer outside the expected structure. They do not remove incorrect judgment.

If the available labels are “safe” and “unsafe,” a perfectly formatted “safe” can still be wrong. Adding a confidence number does not change that by itself.

For Choice and Score, TypeSafe's confidence field summarizes the shape of the probability distribution. It is not a direct statement that the selected answer has that probability of being correct. A threshold of 0.85 does not automatically establish 85% real-world accuracy. Thresholds need evaluation on the actual task. Confidence documentation.

Calibration is a related but different idea. Across many comparable predictions assigned a probability of 0.8, the event should occur about 80% of the time. That is a property to measure over a collection of outcomes, not a promise about one answer. TypeSafe's probability primer.

The external phishing benchmark illustrates how much the question design can matter. Its direct verdict test reports 62.6% accuracy for Jev versus 81.3% for Haiku 4.5. A later experiment combines five Jev signals in a separate statistical classifier and reports 95.0% accuracy, versus 93.2% using Haiku signals; that difference was not statistically significant at the conventional 5% threshold, with p = 0.063. These are different experimental setups. Benchmark repository.

A broad claim that Jev either wins or loses at phishing would erase the most useful finding: breaking a task into questions and combining their answers can materially change the result.

The company's headline speed and cost multipliers also come from particular workflows. Its evaluation uses other models' answers as references, so agreement with those references should not be described as independently verified human accuracy. Evaluation methodology.

What you can actually use today

As of September 19, 2026, the direct documentation lists jev-1.13.0, text-only input, a 64k-token total request budget, and a 32k limit for state plus the longest question. Its listed rate limits are 250,000 tokens per second and 1,200 requests per minute, subject to change during early access. Current model card.

That text-only boundary matters. Audio needs transcription or derived state. Images and PDFs need text extraction or another preprocessing system. A game or phone demo can use structured descriptions without giving Jev native vision.

TypeSafe provides a direct API and SDKs. Integrations also exist through Vercel, Cloudflare and LangChain. Check each provider's limits and interface; these are not necessarily identical to the direct endpoint.

The published weaknesses include counting, numerical precision, date comparisons, distracting context and adversarial instructions. Exact calculations and permissions belong in ordinary code. Model limitations.

For business data, TypeSafe states that requests and responses are not used for training. Its zero-data-retention offering is described for enterprise customers, not universally for every account or gateway. Data-handling terms.

The first experiment I would run

Choose a decision your application already makes: selecting a support queue, ranking a short set of search results, or deciding whether a page needs additional processing. Keep the surrounding workflow stable so you can identify what changed.

Use examples with known outcomes, including confusing and incomplete inputs. Compare Jev with the existing method and a simple rules-based baseline. Measure correct decisions, missed cases, unnecessary escalations and whole-task cost. For latency, record the slow requests as well as the median, from the region where users will run it.

Then decide what happens when the model is uncertain or unavailable. A cheap judgment is useful only if the application has a sensible next step.

What interests me most about Jev is the possibility of checking things that previously went unchecked. A forgotten conversation can get another look. A generated answer can be checked against its sources. An agent can reconsider which memories belong in its context before it starts working.

Whether those checks deserve to run everywhere will come down to their errors as much as their price. Jev makes that a practical experiment for more kinds of software.