Jev by TypeSafe AI: 193× in the headlines, 7× in user reports

An agent needs to choose which model handles its next step. Imagine it asks a large reasoning model, waits four seconds for two paragraphs, then keeps only the answer at the end: codex. The rest goes in the bin. You still paid for it.

That kind of call is what TypeSafe AI built Jev for. The company launched it on 15 September with a claim of 20 to 200 times the speed and 40 to 400 times the cost savings, with free output tokens. By the end of our collection window, the announcement thread had 29.8 million views.

We wanted to know what happened when people tried it. Between 15 and 18 September 2026, we collected 26,896 tweets and retained 12,759 relevant posts with usable content. We extracted the numbers and separated authors’ reports of their own measurements from figures they repeated from the vendor. We also rechecked the vendor figures against TypeSafe’s site and docs on 18 September. This article describes that launch window.

The reported gains are substantial. They are also much smaller than the homepage multipliers. Those comparisons involve different tasks and starting points, so the gap alone does not tell us whether the vendor’s results are reproducible.

The median speed-up figure repeated across the posts was 193×, almost exactly the homepage number. Repetition gave that claim reach, but added no independent evidence.

Even the homepage presents more than one comparison. Its worked example lists TypeSafe at $0.000081 and 0.114 seconds, against an LLM at $0.013880 and 8.566 seconds. Those numbers give roughly 75× the speed and 171× the cost savings. The headline has a footnote referring to workflows for System One tasks. Without the same workload and measurement procedure, the example and headline cannot be treated as interchangeable results.

This is a survey of public reports, not an independent benchmark. We did not rerun the experiments. The method and its limits are at the end.

What Jev returns

Jev takes unstructured input and a set of typed questions. It returns probabilities for the available answers. TypeSafe describes it as answering those questions in one parallel pass, instead of generating text token by token.

For example, an application could ask for risk: low | medium | high and manual_review: yes | no. It would receive scores for those choices, which its code could use to select high and yes. The model does not need to write an explanation that the application then parses. The application still needs to decide what to do with the scores.

TypeSafe calls this category System One models and positions Jev as a way to make decisions before calling a chat model. Its published price is $0.042 per million input tokens, with no output-token charge. Free output is a pricing policy; the API still returns data.

The company announced a $40M seed round led by DCVC. Founder Diogo Almeida co-authored the InstructGPT work on reinforcement learning from human feedback. TypeSafe calls Jev’s training method RLCD, short for reinforcement learning for calibrated decisions.

As of 18 September, the access options listed in our research were Vercel AI Gateway, OpenRouter’s newly added beta, AI/ML API, and direct API access through a waitlist.

Why the multipliers differ

A speed-up means little until you know what was replaced.

The extracted reports name very different baselines: Opus 5, Gemini, gpt-5.6-luna, DeepSeek, Astra, gpt-5.4-nano, Claude and Sonnet. Some say only “our previous setup”. Replacing a long reasoning call with a short classification call is a different comparison from replacing a small model already configured to return one answer.

This is one plausible explanation for the spread. The middle half of reported speed-ups ran from 2× to 20×. Our aggregate figures do not isolate how much of that variation comes from the baseline, the task, or the way the author measured it.

@nurbolatsn raised a useful objection to the demos. An LLM can be asked to return y or n; it does not have to write a paragraph first. A comparison that makes it produce an explanation may measure the cost of that output as well as differences between the models. The practical comparison is with the shortest reliable call your application can already make.

The latency reports also need care. Their median of 76 ms falls inside TypeSafe’s stated 70 to 500 ms band. But the lower quartile is 2 ms, well below it, and the upper quartile is 270 ms. These are not enough to establish agreement on end-to-end latency. Before combining such figures into a benchmark, we would need to check what each author timed, including whether they measured one request or divided a batch’s duration by its item count.

What people built in the first four days

Of the 12,759 relevant tweets, 3,105 came from authors classified as having tried Jev themselves. That is about 24% of the posts, from 2,172 unique accounts, during a period when direct access required a waitlist.

Their reports cover both measured experiments and descriptions of working applications. The table keeps that distinction where a report gives no numerical result. These are the authors’ results, not tests we reproduced.

The security pipeline and safety classifier reports are worth examining in particular. Both claim an accuracy gain as well as a cost or speed improvement. To judge whether those gains transfer to another application, we would need their test cases and accuracy definitions.

Routing appeared in 604 tweets, classification in 565, ranking and scoring in 263, and tool selection in 108. These categories suggest a practical place to try Jev: a repeated decision that determines what an expensive model sees or does next.

Some developers used it to route work between Claude Code, Codex and OpenCode, or to select files before sending them to Claude. Others replaced the decision about which tool to call while keeping Fable, Astra or Opus for the subsequent work.

Review was another use. One build checked a pull request description against the actual diff. Another flagged agents that passed CI by weakening tests. Other examples included PII redaction in support messages inside Postgres and a rule engine that accepted conditions in plain English. The rule-engine author reported 0.7 seconds and $0.0001 per check.

Can filtering replace session compaction?

On 17 and 18 September, context pruning drew 83 tweets and 2.1 million views. Twenty-one authors reported building a version of it.

@tamarajtran, whose post received 1.45 million views, proposed scoring tool calls in the session history and removing records the agent no longer needed. That would avoid waiting for a model to write a summary. The author published the plugin, and TypeSafe’s co-founder reposted it.

A Japanese walkthrough in our collection described two questions for each past tool call. Does the agent still need a record of this call? Does it need the full result, or can it fetch that result again? Code then rebuilt the context using those answers.

The disagreement was about what gets lost. @theo, in a post with 256,000 views, argued that compaction also reorganises history to keep the agent focused. @apanasenko questioned whether a tool result could be judged useful without the wider task context.

Those objections point to different tests. A pruning system needs to show that it preserves information the agent will need later. A summarisation system needs to do the same while rewriting it. The collected posts did not settle that comparison with measured task outcomes.

Experiments beyond routing

Some of the most useful demos make the model’s constraints visible.

Generating text one character at a time. @ryanvogel asked Jev 29 yes/no questions per character, one for each letter plus a space, comma and period. The program appended the highest-scoring choice and submitted the updated string again. The surrounding loop turned repeated classification into text generation.

Playing Othello. A Japanese developer supplied the board state and selected the square with the highest score. A heat map displayed Jev’s predictions beside those from negamax search with alpha-beta pruning. That made the choices visible, though the description alone does not tell us how often Jev won or chose the best move.

Simulating a customer survey. @ytiskw created 150 fictional personas and asked 12 questions per persona. The reported total was ¥1.8 and about five seconds, including requests from Japan to the US. That measures the cost of simulated answers; it does not establish how well they predict real customers.

Rebuilding feed ranking. @leojrr used Jev to estimate a post’s likely popularity in a feed-ranking implementation with a global timeline.

Scoring debate statements. @chetaslua ran statements from a presidential debate through five yes/no questions. The report listed 1,191 calls, 1.18 million tokens, 415 ms median latency and a total cost of $0.0497. It demonstrates inexpensive scoring, not verified fact-checking accuracy.

Removing ads by reading the page. @iam_zachi classified DOM elements as ads or non-ads and removed those classified as ads, without a filter list.

Building a local alternative. A Japanese developer reported 40 ms per decision from an inference engine on DGX Spark that omitted text generation. This was a separate implementation, not Jev running locally.

Training a model with a similar API. @vinnylarouge published a repository for training “jevlikes”, working backwards from the API’s return types. Matching the interface does not establish that the underlying architecture is the same.

Rating a dating profile. @steveruizok used early access to score his Hinge profile. The reported cost was a hundredth of a cent, with a response in 70 ms. The experiment says more about how easy it is to try a new classification task than about the quality of dating advice.

How it compares with existing classifiers

Developers already using classifiers asked a reasonable question: what would Jev change for them? We found that discussion in 164 tweets.

@alexisgallagher pointed out that fast, inexpensive zero-shot classifiers have existed for years. For a stable task with training data, a specialised classifier is an obvious baseline. Jev’s launch claims alone do not establish that it would beat one.

The argument for trying Jev is partly about setup time. One Japanese developer described collecting data and fine-tuning a classifier as a project that could take one or two months. An API that accepts a new question immediately can shorten the route to a first experiment. You still need to define the task and evaluate the answers. Whether it saves a training project depends on whether those answers are good enough.

Structured output is another relevant comparison. @AlecTPhD named Haiku as an existing inexpensive option for filling a schema. Constrained decoding, JSON schemas and token restrictions can also limit a generative model’s answers. Jev’s proposition is that a model built for these decisions can deliver them faster and at lower cost. That is something to test against the configured model you use today.

The architecture debate remained unresolved in the launch posts. Several developers published 1B-parameter fine-tunes with constrained decoding and described them as equivalents. @4rcherhume disputed that comparison. @austinvhuang, who trained a small version, also argued that the design could not be reduced to a conventional classifier or parallel sampling from a prefix. Closed weights limit what outsiders can establish about Jev’s implementation.

As of the review date, the API offered no fine-tuning option. @rileybrown had asked about it directly. One developer proposed the reverse arrangement: use Jev to label data, train a smaller model on those labels, and run that model independently. That approach would also need checks for errors inherited from the labels.

Repositories to explore

The launch produced applications that call Jev and separate attempts to reproduce its approach. Those are different starting points. The open reimplementations can run without Jev access; integrations with its API still need access through a supported provider.

The two open reimplementations listed here do not claim parity with the closed model. Treat them as implementations to inspect and test, rather than interchangeable copies.

Limits reported during launch

The demos make more sense once you separate Jev’s decision from the code preparing its input and acting on its answer.

Jev had no image input in the reviewed release. The Doom and driving demos supplied text representations of the environment. @FakePsyho described Doom’s input as preprocessed monster and item positions. The driving demo drew a similar objection about its simplified environment. Those demos do not show a model interpreting raw video.

The surrounding application also handles retries and recovery. A developer may use Jev to choose a recovery action, but something still has to detect failure and execute that action. One PR-review author reported passing harder checks on for further review. A computer-use author found that OCR remained the bottleneck even when Jev answered in 90 ms. A faster decision only helps the part of the workflow it replaces.

Choosing a valid option also says nothing about whether it is the best option. A PR-review author reported a Rubik’s cube experiment that took 94 moves, compared with a stated reference of 22. The report does not give enough detail here to establish that reference as an optimal solution under the same move-counting rules.

Other posts raised operational questions. @DhravyaShah asked the founder about production readiness and rate limits. That question is evidence of a concern, not a measurement of the service’s reliability.

@odashi_t also questioned explanations of determinism based on “temperature 0”. If the model does not decode text autoregressively, that explanation does not describe its mechanism. Applications that depend on identical answers should test the service’s behaviour for repeated inputs.

What the confidence score can tell you

Probabilities make it easy to write a threshold into code. That is useful, but choosing the threshold is part of the work.

We found 212 tweets about decisions involving people, including fraud checks, candidate filtering, document triage and moderation. Sixty-two described implementations classified as already running. That label does not establish production use; our method could not reliably separate it from experimentation.

@AgomaMitchell raised the key question about a score of 0.95. Does that score correspond to the observed frequency of correct answers on your task? The number alone cannot establish it. To assess calibration, you need labelled examples and a comparison between predicted probabilities and observed outcomes. Measuring calibration reveals whether they agree; it does not automatically make them agree.

TypeSafe’s name for its training method includes “calibrated decisions”. That is not a substitute for checking calibration on the data you will send it. In the launch discussion, the founder said public evaluations “reward bad actors” and that the company would de-emphasise them, “even if we look good”. The materials reviewed for this article did not provide a reproducible benchmark that resolved these questions for a particular application.

The same distinction matters for the phrase “hallucination-free”. Restricting answers to a schema prevents free-form invented text. It does not prevent a false classification or a confidently wrong decision.

What critics objected to

Our labels marked 4.3% of the posts as explicitly negative. Separately, 1,376 posts contained a concrete objection. Those counts describe different categories; a broadly positive post can still raise a problem.

The most-viewed critical post, with 590,000 views, came from @NathanFlurry. He called Jev a “really smart switch statement” and argued that the launch repackaged an existing class of tool. @alexisgallagher similarly thought the reaction showed how unfamiliar many developers were with encoder-only classifiers.

@MatijaSosic, whose explainer reached 400,000 views, interpreted the launch language as a deliberate response to that objection. References to AGI, 200× gains and a ChatGPT creator drew attention; other people then explained the classifier use case. That is his reading of the launch strategy, rather than evidence about model performance.

@ainativefirm questioned whether the low price supported a viable business and asked whether the company resold data. The question itself provides no evidence of data resale and should not be treated as a finding about TypeSafe’s practices.

@mattn_jp reported a tendency to answer yes even to false propositions. That experiment used an LLM-based imitation, so it does not establish the same bias in Jev. It does suggest a useful evaluation case for anyone building a similar classifier.

Access was a more frequent complaint than price. The collection recorded 507 mentions of the waitlist and 363 of having no access, compared with 112 about trust and 13 about price. These are mention counts, not necessarily separate people. The closed weights also prompted the open reimplementations discussed above.

Where to try it in an agent workflow

Start with a repeated decision you can already evaluate. Model routing and file selection are good candidates for an experiment because the inputs and available choices can be made explicit. A decision about whether a change is safe to merge needs a much stronger evaluation than a decision about which files to include in a prompt.

Compare Jev with the call you actually use, configured to return the shortest reliable answer. Record end-to-end latency, total cost and errors on the same examples. Include any extra calls needed when Jev’s answer is uncertain or wrong. A lower per-call price can disappear if the workflow needs more retries or sends more cases to an expensive model.

For an interactive loop, look beyond the median. The 76 ms median in these reports is a reason to investigate, but it does not establish a latency guarantee for your application.

Jev’s API does not directly produce prose or accept images in the reviewed release. It can choose among actions defined by a planner, but the application still needs to define those actions and manage the plan. The character-generation experiment shows how much surrounding code can change what a classifier appears to do.

The most useful launch result is that developers found concrete decisions to replace and reported meaningful gains. Whether you can get those gains depends on the decision, the baseline and the cost of being wrong. Those are the measurements to make before replacing a working component.

Method and limits

We used an X search API to make 5,855 requests covering 15 to 18 September 2026. The collection contained 26,896 unique tweets. Filtering retained 15,425 relevant posts, and a model pass reduced that set to 12,759. We stored raw responses before filtering so the criteria could be changed without collecting the posts again. This is the set our search collected, not proof that we captured every post about Jev.

Each tweet received labels across 18 fields. Every judgement had to include a verbatim excerpt, and an automatic check confirmed that the excerpt appeared in the tweet. That check catches invented excerpts; it does not establish that the label interprets the excerpt correctly.

We accepted the schema after it reached 98% agreement on 50 manually labelled tweets. Two earlier versions scored 68% and 82%. That small review set is a check on the labelling process, not a 98% accuracy guarantee for every field across the collection. A per-number source field separated vendor claims from authors’ reports of their own measurements. It could not verify that those measurements were sound.

Distinguishing a one-off trial from production use was the least reliable judgement, with 64% agreement against manual labels. We dropped that distinction from the usage counts. Those counts describe reported use, without establishing production adoption.

The numerical summaries combine reports about different tasks, models and measurement setups. The sample sizes in the opening table count extracted figures, not necessarily independent authors or experiments. Their medians describe the collected reports, not Jev’s expected performance on a new task.

There are also selection effects. People may publish successful experiments more readily than failed ones, and the waitlist limited who could try the model during these four days.