Jev looked like a new kind of model. Then someone rebuilt a surprising amount of the experience with Qwen in a few hours.
That doesn’t make Jev less interesting.
It makes the interesting part much clearer.
Jev and RLCD, in 60 seconds
TypeSafe recently introduced Jev, what they call a System One model.
The basic thesis is simple.
Most software doesn’t actually need an AI to write an essay.
It needs answers to questions like:
- Is this transaction fraudulent?
- Which queue should this ticket go to?
- How severe is this incident?
- Does this output violate policy?
Today we often solve this by asking an LLM to generate text or JSON:
context
↓
LLM
↓
generate tokens sequentially
↓
JSON
↓
parse + validate
↓
decision
Jev proposes something much closer to:
context
↓
semantic judgment
↓
typed value + probability
Instead of asking for prose, you define a finite decision:
LOW | MEDIUM | HIGH
and get something like:
LOW 0.04
MEDIUM 0.17
HIGH 0.79
That’s a much more natural primitive for software.
TypeSafe pairs this with a new training objective they call RLCD: Reinforcement Learning for Calibrated Decisions.
The important word is calibrated.
If a model says “80%” a thousand times, roughly 800 of those predictions should actually be correct.
So the ambition isn’t merely:
return probabilities.
It is:
return probabilities we can actually trust.
That distinction becomes important in a minute.
Then Harsha Gundal did something fun
Shortly after Jev launched, Harsha Gundal published an experiment built on top of Qwen 2.5 1.5B.
His joke was essentially:
They built in stealth for two years. I built in stealth for two hours.
At first glance, his system looks surprisingly Jev-like.
It takes ordinary Qwen and produces:
- typed decisions
- probabilities
- multiple decisions in parallel
- significantly lower latency than generating equivalent JSON
And crucially:
There is no new training.
No RLCD.
No new model weights.
Just a different way of using an existing autoregressive model.
So what did he actually do?
Trick #1: stop generating JSON
Imagine we want:
{
"risk": "HIGH",
"block": true,
"action": "MFA"
}
A normal LLM generates this one token at a time.
{
"
risk
"
:
"
HIGH
"
...
That is useful if your output can be arbitrary language.
But absurdly wasteful if you already know that risk can only be:
LOW
MEDIUM
HIGH
So instead of generating the answer, Harsha asks Qwen to score the legal answers directly.
Qwen already has logits representing its preference for possible next tokens.
Restrict them to:
LOW 7.4
MEDIUM 9.1
HIGH 12.7
Softmax them:
LOW 0.005
MEDIUM 0.026
HIGH 0.969
Done.
No JSON generation.
No parser.
No invalid value.
No dozens of decoding steps.
Trick #2: reuse the expensive part
Suppose we want four judgments about the same transaction:
fraud risk?
account takeover?
block transaction?
recommended action?
The expensive part is reading and understanding the transaction context.
An LLM processes that context into its KV cache.
Harsha does that once.
Then he reuses that cached representation across all four questions and evaluates them as a batch.
Conceptually:
transaction context
│
Qwen
│
KV cache
│
┌─────────────┼─────────────┐
↓ ↓ ↓
fraud? block? action?
That makes the workload highly parallel.
And GPUs really like parallel.
His reported benchmarks show roughly 5–7× latency improvements over generating equivalent structured JSON on his setup.
The exact benchmark is less interesting to me than the mechanism.
Because the mechanism is completely believable.
And suddenly Qwen starts looking a lot like Jev
This is the fascinating part.
We normally treat an LLM like this:
semantic understanding
↓
convert understanding into words
↓
generate words sequentially
↓
parse words back into structured values
Harsha effectively skips the round trip:
semantic understanding
↓
score candidate decisions directly
Which raises an obvious question:
How much of the Jev experience requires a new model at all?
At least some surprisingly large pieces apparently don't.
An ordinary transformer already contains something resembling a very powerful:
SEMANTIC_JUDGE(context, choices)
primitive.
We've simply spent years accessing it through the interface of text generation.
But this is NOT RLCD
This is where the distinction matters.
Harsha's output contains numbers that look like:
fraud = 0.92
But a softmax probability is not automatically a calibrated probability.
A normal model can say:
confidence = 99%
and still only be correct 80% of the time when it says 99%.
The scores are internally normalized.
That doesn't mean they correspond to real-world frequencies.
This is exactly the problem RLCD claims to address.
Harsha has shown:
typed outputs ✓
restricted choices ✓
parallel decisions ✓
fast inference ✓
probability-shaped output ✓
He has not shown:
true calibration ?
RLCD training ✗
Jev architecture ✗
Jev-level task quality ?
So I wouldn't describe his project as an RLCD reproduction.
It is much closer to a Jev-like sampler built on ordinary Qwen.
And in some ways that is more interesting.
It recalibrates how I look at Jev
Before seeing Harsha's experiment, several ideas in TypeSafe's launch appeared bundled together:
new architecture
+
parallel sampling
+
typed decisions
+
probabilities
+
RLCD
+
extreme latency/cost gains
Now I'd separate them.
Typed outputs are probably commoditizable
Constrained decoding already exists, and Harsha demonstrates how far you can push it.
I don't think this will remain a meaningful moat.
Parallel semantic decisions are probably commoditizable too
This pattern is too useful and too straightforward once seen:
prefill once
→ reuse KV cache
→ batch independent judgments
I would expect inference engines and model-serving stacks to adopt increasingly sophisticated versions of this.
Large speedups are therefore not surprising
If you replace 100-token generation with a handful of candidate-scoring operations, of course you can get dramatically faster.
The exact TypeSafe numbers still need independent validation, but the general direction is clearly real.
Which leaves the genuinely hard part
Calibration.
Suppose two systems return:
fraud probability = 0.81
One simply took an ordinary model's logits and softmaxed them.
The other was explicitly trained so that:
among decisions assigned ~81% probability, approximately 81% are actually correct.
Those are completely different systems.
The second one lets me build things like:
if fraud_probability > 0.995:
block()
elif fraud_probability > 0.80:
require_mfa()
else:
allow()
with some statistical meaning behind those thresholds.
That is enormously valuable.
Especially in systems where policy remains deterministic and AI supplies only judgment.
Which brings me back to the part of Jev I find most exciting
It isn't really “an LLM that doesn't generate text.”
It is the possibility of a new software primitive:
SEMANTIC_JUDGE(state, choices) → calibrated distribution
Computers already give us primitives like:
COMPARE
SORT
HASH
REGEX
But enormous amounts of real-world software depend on fuzzy judgments:
Is this suspicious?
Does this message sound abusive?
Does this invoice match the contract?
Is this support response actually resolving the issue?
Does this incident resemble a credential compromise?
Traditionally we had three options:
- encode brittle rules,
- train a task-specific classifier,
- call a general-purpose LLM.
A cheap, fast, general-purpose semantic decision primitive would sit somewhere new between all three.
That feels genuinely important.
So Harsha hasn't punctured the TypeSafe thesis
He has done something more useful.
He has stripped away some of the things that looked novel but may soon become standard infrastructure.
typed decisions → reproducible
parallel evaluation → reproducible
fast constrained output → reproducible
probability scores → reproducible
Which exposes where TypeSafe's real moat has to be:
actual calibration
+
decision quality
+
training objective
+
architecture/economics at scale
If Jev's real advantage turns out to be merely:
“we don't generate JSON token by token”
then that advantage will disappear quickly.
Harsha's experiment already shows why.
But if RLCD genuinely produces models whose uncertainty is substantially more trustworthy than ordinary LLM logits, while retaining strong semantic judgment at a fraction of the cost,
that is the part worth paying very close attention to.
Because the big idea may not be a better chatbot.
It may be that AI becomes another primitive inside ordinary software:
if semantic_probability("this is fraud") > 0.95:
...
And once you see that abstraction, it is hard to unsee it.