What Jev is
Jev comes from TypeSafe AI. It launched on 15 September 2026 and was built by Diogo Almeida, who co-invented the training methods behind ChatGPT at OpenAI (launch post). It does not write text. You give it some information, such as a message from a member of the public, and a set of questions with the answers already defined. It picks an answer and tells you how confident it is.
So instead of asking a chatbot “what does this person want?” and reading its reply, you ask Jev “is this about a payment, a change of address or a complaint?” and get back “payment, 84% likely”.
It is fast and cheap. Most calls take about a tenth of a second, at $0.042 per million input tokens, with output free (MarkTechPost). These are vendor numbers, and TypeSafe itself says its headline gains sit toward the upper end of what real use will show (Requesty).
What I think I’ve understood
My first read was that Jev lowers token usage when you’re working out user intent. That’s close but not quite right. The saving comes from taking a large language model out of the decision. Many AI-enhanced services ask a chat model to read a message, reason about it and write out a label. You pay for all of that reasoning. Jev skips it and returns the label.
Intent detection and routing are among the uses TypeSafe names directly (TypeSafe docs). For a service handling thousands of web chats, emails or calls a day, cheap and fast routing looks useful. That’s my inference. I haven’t seen a public-sector team write about using it yet.
Where it gets harder for government
Jev gives a probability without a reason. It produces no written explanation for a decision, which matters for audit in regulated settings (DataCamp). If a routing decision sends someone down the wrong path, nobody can read why. A public service has to account for its decisions, so that’s a real gap.
Someone also has to define the answers up front. A chat model lets you skip that step. Jev doesn’t. Teams must choose the labels, set thresholds and decide what happens when confidence is low (Kingy AI). That is product work, and it’s the part we often leave until later.
The evidence is early. TypeSafe’s benchmarks measure agreement with other AI models rather than independently checked correctness. One tester found confidence scores in the middle of the range far less reliable than those near 0 or 1 (LMSpedia). TypeSafe advises testing non-English accuracy separately, which matters for Welsh-language services.
Questions I want to go deeper on
Where does misrouting cost us today: in AI spend, or in staff time untangling cases that went to the wrong place?
What does a good “none of these” option look like, and who owns it?
How would we explain a routing decision to someone who challenges it?
Could a model like this act as a check alongside a chat model rather than replacing one?
What would a service assessment (the review a government service passes before going live) ask of a model that can’t explain itself?
I don’t have answers yet. I think product people should be asking these early, before anyone gets excited about the price.
Further reading
TypeSafe’s launch post: the company’s own case
DataCamp’s explainer: a plain introduction
Simon Willison on Jev: a respected independent developer’s take
Kingy AI’s review: the best critique of the benchmarks
LMSpedia on calibration and audit: why confidence scores need testing
Every on intent-based software: the optimistic view
A warning: several lookalike “Jev” sites are not TypeSafe. Use typesafe.ai.
Personal views, not those of any client or department.


