DEV Community

TuringCorp
TuringCorp

Posted on

A model that refuses to write: Jev, decision models, and the other end of the same trade

A model that refuses to write: Jev, decision models, and the other end of the same trade

For the past two weeks the most interesting thing about Jev is what it won't do.

Ask it a question and you get no sentence. No paragraph, no JSON you have to parse, no apology, no "here's my reasoning". You get one value out of a set you defined yourself, plus a probability, plus a confidence number. That's it. That's the whole product.

TypeSafe AI shipped it on September 15 with a $40M seed round, and developers did something unusual: they got excited about a model that produces less. Within a week it was in Spring AI, Vercel's AI Gateway, Langfuse, OpenRouter's Decisions API, and two different awesome-lists. Someone on the internet called it "an LLM without the LL", which is about as good a one-liner as the thing is going to get.

I think the excitement is justified, and I also think most of the coverage has missed what actually changed. So here is what Jev is, why the shape of its output matters more than its benchmark scores, and — since we build something at the opposite end of the same idea — what that comparison is good for.

What Jev actually returns

You send state (text) and one or more typed questions. There are three question types:

  • choice — pick one option from a set you define, with probabilities for every option and a confidence value.
  • score — place the text on ordered levels you describe; you get a probability-weighted score plus the per-level distribution.
  • noul — the probability that a yes/no proposition holds. One number, no separate confidence field.

Here is a real response from a published OpenRouter run, trimmed to the parts that matter:

{
  "answers": {
    "intent": {
      "type": "choice",
      "choice": "billing_dispute",
      "confidence": 1,
      "probabilities": { "billing_dispute": 1, "order_status": 0, "other": 0 }
    },
    "escalate": { "type": "noul", "noul": 0.04 }
  },
  "usage": { "cost": 0.000016002, "inputTokens": 381, "outputTokens": 62 }
}
Enter fullscreen mode Exit fullscreen mode

Notice what is missing. There is no rationale. No chain of thought. No explanation of why the intent is billing rather than account access. TypeSafe is explicit that confidence measures how concentrated the distribution is, not whether the answer is right. Accuracy is aggregate: when Jev says 0.8 it is right about that class of answer roughly 80% of the time, averaged over many cases. Any single answer can still be wrong.

That last point is not a footnote. It is the whole reason the output shape is useful.

Why this is more than a fast classifier

1. The output type changed. Almost everything we call "AI" these days generates text and then we try to make it behave like a value: JSON schemas, constrained decoding, retries, parsers, validators. Jev inverts that. The value is the native output; language is not involved at all. There is nothing to parse and — in the strict sense — nothing to hallucinate, because there is no free-form surface to hallucinate on.

2. Confidence became an API surface, not a metric. This is the part I find genuinely new. Because every answer comes with a distribution, you can write policy in ordinary code: act above one threshold, ask for confirmation in the middle band, route to a human below another. The published triage example does exactly this — intent confidence under 0.8 goes to a person, escalation probability over 0.5 goes to a person, everything else is handled deterministically or handed to a language model to write the reply. That is not "AI in the loop". It is a decision with a dial on it, wired into a switch statement.

3. The economics at volume are real. OpenRouter ran 60 support tickets through Jev, GPT Luna and Claude Opus with the same definitions:

Jev 1.13 GPT Luna Claude Opus
Intent accuracy 59/60 (98.3%) 59/60 (98.3%) 60/60 (100%)
Median latency 194 ms 1,106 ms 1,957 ms
Cost per 1,000 tickets $0.0248 $0.0921 $2.8802

Accuracy is a wash; the cost and latency are not. A second run screening 40 messages for prompt injection went 40/40, with injections scoring 0.86–0.99 and ordinary messages 0.01–0.20. Jev is priced at $0.042 per million input tokens with output free — under $20 to triage a million tickets.

4. The ecosystem signal matters more than the numbers. When gateways, frameworks and observability tools all add support for the same primitive within days, that primitive is becoming infrastructure. We watched this happen with embeddings, then with tool-calling. "Return a decision with a calibrated probability" is the next one, and Jev is the cleanest implementation of it so far.

What it gives up — and the skepticism is partly right

Jev does not explain itself. There is no rationale to log, show a user, or attach to an audit trail; the advice from its own docs is to log the request ID, the questions, the probabilities and the threshold you applied. For high-volume, code-actionable decisions that is fine. For a decision a human has to own, it is a real gap.

It is also narrower than the hype suggests. Text only — no images, audio or PDFs. It loses accuracy when the state carries irrelevant detail. It is unreliable at arithmetic, counting and date comparison, so you compute those yourself and hand it the semantic part. It is proprietary: no weights, no paper, hosted only.

And the counter-argument deserves airtime. Redis's creator publicly pushed back on the Jev enthusiasm, arguing that most developers do not actually have the problem Jev solves. Independent reproductions suggest the capability is less exotic than the marketing: one group reproduced fast decisions with a 9B-class model at 79 ms. That is a compliment to the engineering, not a refutation of it — but it does mean "200× faster" is a statement about where you put the compute, not a new kind of intelligence.

The other end of the same trade

Here is where we come in, briefly, because the comparison is the interesting part.

We also ship decisions with calibrated confidence. The difference is that we deliberately kept the thing Jev threw away: the written reasoning. Our product, Decider, takes two candidate answers to one hard question and returns which one is stronger, how confident that call is, and a 900–1,700 character argument for it.

That choice costs us exactly what it costs Jev to skip it: instead of ~200 milliseconds we take tens of seconds, and instead of fractions of a cent we charge real money per decision. We are not competing with Jev on triage. We are on the other end of the same trade — the end where the decision is genuinely ambiguous, where two options are both defensible, and where the person who has to live with the call needs to see why and how sure before they commit.

On accuracy we make no claim over direct model baselines, and we say so on our own pages: on JudgeBench we measured 92.5% (620 judgments, 6 failures disclosed) against 92.2% for a plain direct baseline. The differentiation is not "we are more accurate". It is that the confidence is calibrated and the reasoning is published: in our recorded runs, calls reported at 90%+ confidence were right 99.6% of the time, and 80–90% confidence right 94.0% — note the method, the benchmark and the failures are disclosed, and the raw judgements are public. The paper is here.

So the two systems are not rivals. They are the two ends of the same design decision — one strips language out to buy speed and determinism, the other keeps language in and pays for it, because for a hard human decision the explanation is part of the deliverable.

A decision model (Jev) A deliberative judge (Decider)
Output Typed value + probability Choice + calibrated confidence + written reasoning
Latency ~200 ms Tens of seconds
Cost ~$0.02–0.04 per 1,000 Per-decision pricing
Use when The answer is one of N and code acts on it The answer is contestable and a human owns it
Reasoning Deliberately absent The point

Two ways to try ours

We are early, and we would rather hear that our confidence bins are wrong than hear nothing. If you build with either end of this trade — Jev's or ours — I would like to know where the boundary actually sits in your system. That is a genuinely open question right now, and it is a more interesting one than another leaderboard.

Top comments (0)