On October 15, Vercel announced that Jev, a decision-only model from TypeSafe AI, had recorded the fastest adoption in the history of its AI Gateway. In the 14 days after launch, 35.3% of paying teams used it, while its share of spending over the same period was just 0.27%. An AI that generates no free-form text and instead returns judgments to predefined questions is being widely tried, yet it accounts for only a small slice of inference costs. The speed of uptake shows interest in this kind of use, but whether it can automate work correctly has to be verified separately from speed or price.
The 35.3% measures breadth of use, not accuracy
Jev was announced as early access by TypeSafe on September 15, and in Vercel's tally it became available on the Gateway on September 17. The record is based on usage by external paying teams going through Vercel AI Gateway, which provides access to models from multiple companies.
The 35.3% over the first 14 days is a share of teams using it, while the 0.27% over the same period is a share of spending.
Sorting the measurement definitions in Vercel's October report by subject and denominator gives the following.
| Metric | Jev's value | What the figure is measured against |
|---|---|---|
| Share of teams using it in the first 14 days | 35.3% | Paying teams active from the start of the launch month to the data cutoff |
| Share of spending in the same 14 days | 0.27% | Total paid spending on the Gateway in that period |
| Reuse rate the following week | 55.6% | Teams that tried Jev in the first week after launch |
Spending is estimated from public list prices and may differ from actual billing. The reuse rate is the share of teams that tried Jev in week one and used it again in week two. It does not measure whether they keep using it daily or whether it took hold afterward. The report body also does not give the actual number of teams in the denominator.
Jev's use has spread across paying teams, yet it makes up a small share of the Gateway's inference costs. A use case that calls a light judgment cheaply and repeatedly can be used by many teams while keeping its spending share small. However, these statistics alone do not prove that low prices drove adoption. They also exclude usage of each company's APIs that doesn't pass through the Gateway, so they cannot be read as a share of the overall AI market.
Skipping text generation to evaluate candidates
What you give Jev is the material for judgment and a question about that material. According to TypeSafe's documentation, it combines "Choice," which picks from candidates; "Score," which defines levels and grades; and "Noul," which returns the probability of a yes.
Consider routing an inquiry to the "billing," "technical," or "account" team. Jev doesn't write a reply; it returns which candidate is appropriate, with probabilities. The app then decides whether to forward the inquiry or ask a person to check. This is an example to explain the behavior, not a record of adoption by a specific company.
TypeSafe says it adopted a mechanism that returns judgments on multiple questions in parallel, along with a training method called RLCD, which stands for reinforcement learning for probability calibration. The design skips the step of generating text sequentially and then reading off the result, building repeated judgments into software. Because developers define the questions and candidates, the types of classification can be tailored to the task.
That said, the internal structure that enables the parallel processing has not been independently verified. The political science researchers discussed below also note that details of the model structure, training data, and rewards are not public, so they cannot directly check the developer's explanations.
At announcement, pricing was US$0.042 per million input tokens, with output free. Even if the design lets you make judgments cheaply and repeatedly, the cost of reading the input and the processing that acts on the judgment remain. Faster selection of which team to route to does not mean the subsequent search or answer generation speeds up by the same factor.
The conditions behind "193.6x faster"
TypeSafe's claim of "193.6x faster and 444.6x cheaper" comes from the company's workflow evaluation. The company itself cautions that this is probably toward the upper end of the improvement you can actually expect.
In the evaluation, the same workflow was given to each model, and the average of the predicted probabilities from GPT-6 Astra and Fable 5.1 was used as the reference value. It is not a test that directly measures agreement with human-assigned ground-truth labels. Moreover, the LLMs being compared were fitted with a mechanism, compatible with Jev's API, for returning judgments and probabilities, and TypeSafe acknowledges this tends to make them slower and more expensive than having them return judgments without probabilities.
The development team also created the tasks. These conditions don't make the multiples meaningless, but they are not a guarantee that any classification will be that much faster at the same accuracy. Tasks that need only a short label and tasks that branch finely using a probability distribution also ask different things of the models being compared.
External research splits on speed and cost
Steven Denney and Matthew DiGiuseppe of Leiden University evaluated Jev 1.13 in a preprint replicating seven existing political science studies. They compared it with human-made benchmarks, GPT-6 Luna, and Qwen3.8-27B on tasks such as classifying political text and rating it on scales.
Jev's capability was equal or close to the comparison models on many tasks, and it had an advantage in speed. On cost, however, no advantage was seen when GPT-6 Luna was used at batch pricing. Short classification labels require few generated characters, and with Jev the questions and answer candidates also count as billable input. Even if output is free, the total cost of processing does not necessarily go down.
Easily handled probabilities do matter. As an illustration, if you gather many judgments each predicted to be correct with 80% probability and about 80% of them are actually correct, predictions and outcomes correspond well. Probability calibration is what tunes this correspondence. Even a model with a high accuracy rate is hard to use as a basis for separating automated processing from human review if it attaches overly strong probabilities when it is wrong.
In the study, on a set of reading comprehension tasks where each question was asked once, Jev's probabilities were better calibrated than those from Luna's output tokens. However, its advantage over Qwen was not consistent, and results also change depending on the comparison method, such as averaging over varied question orderings. These are results for specific models and conditions, not a demonstration that Jev's probabilities represent correctness in every use.
Even a correctly formatted answer can be wrong
In another independent evaluation, speed and the burden of false positives appeared at the same time. A safety-classification preprint released on October 13 by Xiang Li and colleagues at Nankai University and elsewhere compares Jev 1.13.0 with LLM-based judges and others.
In the input check before any attack was applied, strict sorting criteria fixed by the researchers were applied to 100 harmful and 100 harmless requests from JailbreakBench. Jev did not let 79 of the harmful requests through, but it also blocked or sent to human review 27 harmless requests. The false-positive rate on harmless requests was 27%, with a 95% bootstrap confidence interval of 19–36%.
What is counted here is not only outright blocks but also cases routed to human review. The median API response time in the same experiment was 0.7 seconds, but even if judgments come quickly, more harmless inputs requiring review create a separate operational burden. This is a fixed test of 100 cases per condition, and the 27% cannot be taken as a general false-positive rate for ordinary work or Japanese-language input.
The developer's claim that it "doesn't get the type wrong" guarantees only the format of the returned value. Even if it picks the wrong team from the candidates, the output format remains correct. TypeSafe also states that its figure of 0% for outputs not matching the type is not a measured value but is based on a format guarantee.
Further, the API's confidence value is an indicator calculated from the probability distribution of the answer. That number must not be interpreted as the accuracy rate for that same value. TypeSafe itself advises testing on your own data and adjusting, since the threshold for permitting execution depends on the use case and the model's performance. The independent studies cited here are all arXiv preprints and should be read as results obtained with specific versions and tasks.
As more teams adopt Jev, the question will be not only whether it returns judgments quickly but how much it can reduce wrong judgments and human review. If a team checks that correspondence on its own inputs and picks processes that improve even after counting the review burden, it can combine models suited to text generation with decision-only models according to their roles.