Jev Is Not a Breakthrough

The company behind Jev says that it makes decisions about as well as an LLM does, only 193x faster and 445x cheaper.

That alone would make Jev a breakthrough. But once you read past the launch post and into the docs and evals, that claim gets a lot weaker.

Jev is fast and cheap because it does less work per decision. That’s a trade you can make with the LLM you already use. (No waitlist required.)

Read on as we break down what Jev really is, and how you can build your own.

What Is Jev (Really)?

Jev is a model from TypeSafe AI, a San Francisco startup that came out of stealth on September 15. Its CEO, Diogo Almeida, spent four years at OpenAI working on RLHF and ChatGPT.

Jev doesn’t write text. You send it some state, like a support ticket or a log line, plus a list of questions. It sends back typed answers with probabilities attached.

There are three kinds of questions:

• Choice picks one option from a list you define.
• Score rates something on a scale, like “calm”, “frustrated”, or “very angry”.
• Noul answers a yes-or-no question with a probability. Ask “is this urgent?”, and 0.9 means a 90% chance that it is.

For example, if you ask Jev which team should handle a ticket about a failing Stripe payment, you can expect something like this back:

{
  "choice": "technical",
  "confidence": 0.78,
  "probabilities": { "technical": 0.85, "billing": 0.15, "sales": 0.0 }
}

TypeSafe calls Jev a “System One” model, meaning it makes quick decisions without reasoning through them step by step.

That’s a reasonable product idea. The trouble starts with how it’s being sold.

”Calibrated” Probabilities

TypeSafe says Jev’s probabilities are “calibrated.” In simple terms, that means the numbers should match how often Jev is actually right.

If Jev says it is 80% sure about 100 different answers, you would expect around 80 of them to be correct.

Think of a weather forecast. If it says there is an 80% chance of rain on 100 similar days, it should rain on roughly 80 of them. But that does not tell you whether it will rain on any one particular day.

That is the first catch. Calibration only works across a large number of predictions. It does not tell you whether the answer in front of you is right. Jev’s own docs make the same point.

The second catch is that TypeSafe has not published any results showing how well calibrated Jev actually is. For now, you have to take the claim on trust.

The third catch is more fundamental. To train a model to give accurate probabilities, you need real outcomes to compare those probabilities against.

For a narrow task, that is possible. If you have thousands of past support tickets, for example, you can see how many actually turned out to be billing issues.

But Jev is meant to answer almost any question you give it. For questions like “should I sell this stock?” or “should I put my left sock on first?”, there is no dataset containing the true probability of “yes.” So there is nothing clear to calibrate against.

”It Can’t Hallucinate”

TypeSafe says Jev can’t hallucinate because it can only return the types you define. If the options are billing, technical, or sales, it cannot suddenly answer “marketing.”

That is true, but it only controls the format of the answer. It does not make the answer correct. Jev can still choose the wrong option and be highly confident about it.

The format thing is not unique to Jev either. Most LLM APIs can already be forced to return answers in a fixed structure or schema.

”A New Kind of Model”

TypeSafe describes Jev as a new architecture. But there is no paper, no public weights, and no technical details you can verify. Some observers suspect it’s built on an open-weight LLM.

So… there’s that.

The Speed and Accuracy Tradeoff

Speed is Jev’s biggest selling point, but to understand that claim, it helps to look at what an LLM is actually doing when it answers.

An LLM response has two parts. First, the model reads and processes your prompt. Then it starts generating the answer, one token at a time.

The time spent on that first part is what you feel as the delay before the answer begins. It is usually measured as “time to first token.”

Now imagine the task only needs a one-word answer, such as “billing” or “technical.” In that case, the first token is basically the answer. There is no long response left to generate.

This is important because Jev is built for exactly these short decisions. It reads the input and returns the result, without generating paragraphs of text afterward.

So simply saying Jev is faster than an LLM does not tell us much. The useful comparison is how quickly Jev returns its decision versus how quickly an LLM can produce its first token on the same task.

If Jev is still much faster on the same task, it has to be doing less work. Either the model is smaller, or it spends less computing power on each question.

And less work makes Jev gets fast and cheap, but it can also make its decisions worse.

What “193x Faster” Actually Measures

So where does the “193x faster” claim come from?

In TypeSafe’s evals, the LLMs were run with their default reasoning settings. Opus 5 took 37.8 seconds per case. Jev took 0.4 seconds.

But Opus was spending much of that time reasoning. Jev does not do that.

A better comparison would be to turn reasoning off and measure how quickly the LLM gives its first answer. TypeSafe did something similar in one demo, and the speed difference was much smaller.

And What About Accuracy?

On the same evals, Jev scored 67.8% on average. Here’s how that compares:

Jev ties Sonnet 5 and trails the top models by about six points.

How to Build Your Own Jev

An LLM with thinking turned off, asked for a single token, is already a System One model. You just need to set it up right.

1. Write One Prompt per Option

Start with the same prompt for each option, changing only the final word:

Why not ask about all three teams in one prompt? You could. But splitting them up gets you the answer faster. You’ll see why in the next steps.

2. Let the Cache Do the Heavy Lifting

Most LLM providers can cache the beginning of a prompt they have already processed. Since these three prompts are identical until the final word, the shared part only needs to be processed once.

After that, each request adds one new word and generates one digit. That keeps the work very small.

3. Send Them in Parallel

Send all three requests at the same time and limit each one to a single output token. Instead of waiting for three separate responses, you get all three scores in roughly the time it takes to get one.

4. Turn the Digits Into Probabilities

Suppose the model gives billing a 6, technical an 8, and sales a 2.

You can run those scores through softmax, a standard formula that converts them into probabilities that add up to 100%:

• Technical: 87.9%
• Billing: 11.9%
• Sales: 0.2%

That is close to what Jev returned for the same ticket.

Here is the full setup in about 25 lines of Python. It works with any OpenAI-compatible endpoint. Just use a model with thinking turned off.

import asyncio, math
from openai import AsyncOpenAI

client = AsyncOpenAI()

TICKET = "My Stripe payment keeps failing at checkout. Please help ASAP."
TEAMS = ["billing", "technical", "sales"]

PREFIX = (
    f'Support message: "{TICKET}" '
    "Reply with one digit from 0 to 9 for how likely it is that "
    "this message belongs to the team named here: "
)

async def rate(team):
    resp = await client.chat.completions.create(
        model="your-model",
        messages=[{"role": "user", "content": PREFIX + team}],
        max_tokens=1,
    )
    return int(resp.choices[0].message.content.strip())

async def main():
    scores = await asyncio.gather(*(rate(t) for t in TEAMS))
    exps = [math.exp(s) for s in scores]
    print({t: round(e / sum(exps), 3) for t, e in zip(TEAMS, exps)})

asyncio.run(main())

When the Decision Matters, Let It Think

This is something Jev does not give you control over because it has no reasoning setting.

With your own setup, you can choose. Leave thinking off for simple, low-stakes decisions where speed matters. Turn it on when the decision needs more careful reasoning, accepting that the answer will take longer.

You can also improve the probabilities using your own data. Fine-tune the model on past predictions and what actually happened. That gives it real outcomes to learn from, rather than trying to estimate probabilities in the abstract.

Wrapping Up

Jev is fast and cheap, and for a lot of simple routing and filtering jobs, that may be all you need.

But it isn’t smarter than an LLM, it isn’t calibrated in any way you can check, and it isn’t faster than an LLM set up to do the same job. It’s a well-packaged classifier with a very good launch campaign.