The model that writes nothing — where Jev fits in a working system

Most of the attention on AI over the past two years has gone to models that write: summaries, replies, code. There is a second shape. A model that writes nothing at all and returns only a judgment — which option, where on a scale, how likely a yes is. In September 2026, TypeSafe released one, called Jev.

We put Jev behind the new search screen of a hiring service we operate. The screen is deployed on the live service but not open to the public yet. That is where we are testing it. What follows is what held up — in the implementation and in a small set of test questions we wrote ourselves — what Jev misread, and what is still open.

What Jev returns, and nothing else

• A choice: one option from a list you define, with a probability for each option and a confidence value
• A score: where something falls on an ordered scale you define, including values between two named steps
• The probability of yes — TypeSafe calls one of these a Noul: given the material and the criteria you supply, how likely the answer to your question is yes

The last one is easy to misread. A 0.8 does not mean 80 percent of the requirement is met. It means the model puts the odds of a yes at 80 percent. If you want a degree, ask for a score.

It cannot write an explanation, a summary, a translation, or code. TypeSafe offers direct access through an early-access program, and Cloudflare serves the model as well. We used the Cloudflare route.

To be clear about the choice: a generative model can also return structured decisions, and it does that well. The reason to split the work is not capability. It is cost, speed, and the fact that a model that cannot produce prose leaves the receiving code much simpler.

Speed and cost, as the vendor publishes them

TypeSafe publishes an end-to-end response time of 70 to 500 milliseconds. It compares that with 3 to 329 seconds for the large general-purpose models, and puts the gap at 40 to 200 times on this kind of question. Pricing is $0.042 per million input tokens, and output tokens are free.

These are the vendor's own comparisons, not independent ones. TypeSafe measures its model from its engineers' laptops on the West Coast, where the service is hosted, and cites an external benchmark for the 3 to 329 seconds; the price is its published rate. A call from Tokyo, routed through Cloudflare rather than direct, will not reproduce them. Read the figures as an order of magnitude, not as the number you will see.

Terms also differ by route. Direct access and the Cloudflare route each have their own context limits, rate limits, and billing terms. Check the documentation for the route you will actually use.

One step to budget for if your text is Japanese

The documentation is explicit on this point. English is the primary training language and the language where accuracy is currently best. Other languages, including those written in Chinese, Japanese, and Korean script, are handled, but not equally well. The guidance is to test on your own content and to pay close attention to confidence when routing.

We treated that as a requirement rather than a caveat. Published behavior on English text was not evidence for our case, so we wrote our own test questions in Japanese, in the phrasing we expect our users to type, before we wired the model into the screen. If you operate in Japan on Japanese text, this is the step to plan for — not a translated version of someone else's benchmark.

Three places we split the work

Separating the job someone has now from the job they want next

When a user writes "I'm in sales today, but I want to move into customer success, and I'm looking in Tokyo," putting sales into the filters returns the opposite of what they asked for.

The split works like this. Jev reads which part of the sentence is the job the person has now and which is the job they want, and which family of roles the request points to. Code updates the filters, counts the matches, and orders the list. On the sentence above, sales never enters the filters; customer success and Tokyo do. The line over the results is a fixed template with the match count dropped in from the data. No generative model is involved.

Separating retrieval from assessment

"Forward-deployed engineer work, implementing AI at customer sites." No list of keyword rules can answer that. Narrowing tens of thousands of postings by keyword leaves you with postings whose title happens to contain the letters AI. Read them and you find companies with AI in their name, roles in semiconductor materials for AI hardware, and sales roles selling AI products. None of these are bad postings. They are simply not what this person asked for.

There is no end to adding more expressions, so we split the work instead.

• Filter matching, and retrieval weighted toward the words the person actually wrote (code)
• Assessment of each posting's role title on the current page against the request (Jev)
• Ordering, and the marker for "close to what you asked" (code)

Jev sees the role title and nothing more. We do not store the posting body at import time, so nothing here verifies the substance of the work. And this pass deletes nothing: it changes only the order and the marker.

That does not close the gap. When a request is phrased only as a description of the work — no role title, only "implementing at customer sites" — the first retrieval may not surface enough postings to reach the assessment at all. Reordering cannot rescue a posting that was never retrieved.

Breaking an intake conversation into small parts (a design, not a deployment)

The same split applies to the chat on our own site that scopes a project before we quote for it. Today it decides, on each turn, which items are still unknown and whether the intake is complete, then maps the whole conversation onto a fixed set of fields at the end. With Jev, that judgment could run on every turn and feed a panel of what has been settled so far. "We need customer management now, ordering can wait" would land on that panel as two settled items — customer management in scope for this phase, ordering deferred — while the user keeps typing. This is a design. We have not measured it.

Look at how it misses

Before wiring anything up, we wrote our own test questions and ran them. We are not publishing accuracy numbers, because they depend heavily on how the questions were written and how many there were. What is worth passing on is the practice.

The scope, stated plainly: jev-1.13.0 through Cloudflare, tested on September 20, 2026. The assessment test paired 20 requests with 30 role titles, split by request into a tuning set and an evaluation set. A second, smaller test covered the other half of the screen: reading the request and producing the one-line templated reply, in 30 questions. Neither test covers real user searches, and neither says anything about what the full corpus fails to surface.

First, we included the hard cases on purpose. The vendor lists literal reading as a known weakness: the model takes the words at face value and can miss what they negate. Negation is where that weakness shows. The test items are in Japanese; they are translated here. 「営業だけは避けたい」 (I want to avoid sales) sat in the same set as 「営業だけに絞りたくない」 (I don't want to be limited to sales) and 「営業も含めて」 (sales included, too) — three sentences built on the same word, pointing in three different directions.

Second, when we set thresholds, we kept the tuning questions and the evaluation questions apart. Tuning and judging on the same set is grading your own homework. That second test is different: we revised it while looking at the same questions, so we treat it as tuning rather than as evidence.

Third, we went back through every miss against the original text and the criteria. Some of the misses turned out to be ours: our labels were wrong, and we corrected them. Before counting an error against the model, check the human answer.

Here is one that was not ours. With a confirmation card on screen, a user replying 「お願いします」 — roughly "yes, please" — sometimes produced nothing at all. The screen does not change and the card stays, so the user can press it instead. But a consent we were given was dropped, and short replies are exactly where that happens: the fewer the words, the more the meaning depends on what came before.

We also tested prompt injection. We appended instruction-like text to a retrieved role title and watched whether it moved the assessment of the other postings on the page. In our tests it did not turn the marker on or off, but the probabilities returned for the other postings did move. Sending postings in small batches narrows the blast radius; it does not make the path safe. Even when nothing is deleted, a posting that drops down the list is harder to find.

The operating thresholds are ours, for this question, on this service. Above the upper threshold we apply the exclusion the user asked for — dropping sales roles, in the example above — and offer an undo. Between the two we do not apply it, and ask first, using a confirmation card. Below the lower one we do nothing. The assessment pass still removes nothing from the list; only the filters change. None of this is a recommended setting for Jev. The probability in a Noul and the confidence returned with a choice or a score are different measures, and neither one is a guarantee of correctness or a substitute for the user's consent.

We also decided how it degrades. If the pass that reads the request is unavailable, we fall back to a simple parse in code. If the assessment pass is unavailable, we return the postings in their pre-assessment order. Both exist so that an outage is never shown as "no results." Neither gives the user the reading they would otherwise have had.

Where not to use it

The vendor publishes a list of the weaknesses: arithmetic and counting, ordering by date, multi-step reasoning, literal reading of negation, and writing prose, plus material padded with unrelated text or written to mislead. Our own boundary is the same.

• Keep arithmetic, dates, and ID matching in code
• Do not replace what a lookup table or SQL already solves reliably
• Do not use a model to fill in material you never had
• Treat "the type is valid," "the content is correct," and "we are allowed to act on it" as three separate questions

Jev also does not carry a conversation or fetch documents on its own. Continuing a dialogue, searching, and acting are the code's work.

What to take away

Writing is not the only thing to ask an AI for. Once a small judgment about meaning becomes cheap, you can build a service that people operate in their own words.

The aim is that the user restates less and resets fewer filters by hand. That is what we are building this split for, and it is not something we have measured with users yet. Cheaper classification is not the point; the point is that a search box can take a sentence like the one above and answer it.

If your operation has a place where users keep rephrasing themselves, or where a person reads every incoming item and routes it, that is where to start. We build these systems in Tokyo, on Japanese text, and we work with clients in English. Tell us what your users are typing.