HunterAlphaHub
OpenRouter model reference Facts from the public catalogue, dated and labelled
Union Alpha revealed no live codename Verified
2026-09-22

Jev · compared

Jev is not a smaller LLM

The sentence everyone writes is "it does not generate text". That is true and it is not the useful part. The useful part is what changes in your code when the answer arrives in a shape you chose before you asked — and what you give up.

An engraving: two machines side by side on a workbench — a press unspooling a long ribbon of dense handwriting, and a shallow brass tray of identical stamped discs while a mechanical finger lifts one out.

In short

  • One pass vs one token at a time. Jev produces every answer in parallel; an LLM conditions each token on the last.
  • The answer shape is yours. A choice from a list you wrote, a number on a scale you wrote — not prose you then parse.
  • Output tokens are the variable cost of an LLM and about five times its input price; Jev's output is free, in the vendor's words.
  • Our twenty identical calls: the label never moved (20/20), the confidence did — 0.38 to 0.58 on the same request.
  • They compose. The interesting architecture is not either/or: it is Jev choosing and an LLM writing.

What a chat model actually returns

Ask a frontier model to classify a support ticket and you get a paragraph. It will be a good paragraph, and writing it cost you output tokens at roughly five times the input rate. To use it in code you then need a parser, a prompt that asks for JSON, a schema check, and an answer for the day the model invents a category you never defined.

Two ways to get a decision: an LLM generates prose token by token which your code must parse, or a System One model returns a fixed-shape answer in one pass. CHAT MODEL your state tokens, one by one prose you parse ~5× input price, per token SYSTEM ONE your state all options at once a label you defined output free, no parser The bottom row is faster and cheaper — but it can only answer questions you put a shape around.
Follow the third box in each row. One of them is something a program has to read, and the step that makes it readable is the one Jev moves out of the loop entirely.

The four differences, and which one actually bites

Chat modelJevWhich one bites in production
Generationone token at a time, conditioned on the last every answer in one parallel pass latency, and the bill: you pay for the tokens you never needed
Answer shapeprose, by default fixed before the call: an option, a point on your scale, a probability this one. A schema you enforce in the prompt is a promise; a schema in the model is a property
When it is unsuresays so in sentences, or does not returns a calibrated probability you can route on the threshold you set becomes the correctness argument
What it does wellanything with words in it one decision from a closed set, under a clock the moment you want a summary, you want a different tool

The third row is the one teams get wrong, in both directions. A confidence between 0.4 and 0.6 is not a decision, it is a coin you can see; if your code treats it as a label you have built a silent failure. We measured the size of that window on 20 identical requests:

SignalLowestHighestStandard deviation
Noul — P(urgency) 0.980 0.980 0.000
Score — frustration level 1.030 1.040 0.005
Choice — P(technical) 0.59 0.73 0.03
Choice — confidence 0.38 0.58 0.05

The label never changed — technical, 20 times out of 20. The number attached to it moved by a fifth of its range. Read the label as the answer and the score as a dial, not as a second answer.

They are not alternatives, they are two halves

The projects we have read mostly do not replace one model with the other; they put the decision in the middle of a loop that still uses an LLM for the parts that need words. Three shapes recur:

  • Jev takes the cheap rung, the LLM keeps the expensive one. A ten-step write-up about putting Jev where an LLM was doing the cheap work inside an agent loop — Jev Engineering in ten steps. It is the same shape our builds column keeps finding, and it is the reason the "either/or" framing is wrong.
  • Jev guards the loop and the LLM does the work. A Claude plugin that trims bulky tool results before they fill the context — the  review pass takes about a second and took a session from nearly a million tokens to 86K.
  • Jev throttles what the LLM is allowed to do. The browser agent that indexes a page and asks which element to act on, so the model never sees free-form coordinates — browser-use, 7.1 seconds for a flight search, per its README.

In all three the LLM is still there. What changed is that the part of the loop that runs hundreds of times is now a decision, and the part that runs once is still a sentence.

When an LLM is simply the right answer

Three ways the projects wire a decision model into a loop that still contains an LLM: the decision guards the loop, the decision takes the cheap rung, and the decision throttles what the model may do. THREE SHAPES WE HAVE READ, NOT THREE OPINIONS 1 · The decision guards the loop trim the tool result before it reaches the context ~1 s, 1M → 86K tokens 2 · The decision takes the cheap rung the repeated choice is a decision, the one-off is a sentence ten steps, one article 3 · The decision throttles the model pick from an indexed space; never free-form coordinates 7.1 s for a flight search
Read the right-hand column first: one number per shape, and each number is what a project measured about itself rather than anything measured here.

If the output is read by a human, if the categories are not known in advance, if the task is to explain or rewrite or translate, if you need the model to notice a category that does not exist yet — Jev is the wrong tool and the vendor says so themselves: strings are general, and general is what you want when the problem is open.

The honest version of the comparison: a chat model is a consultant you ask, and Jev is a switchboard operator. The switchboard is faster and cheaper and never improvises. It is also useless if the thing you needed was advice.

What this page cannot tell you

It cannot tell you which is more accurate on your task, because accuracy is a property of a prompt and an option set, not of a model family — and nobody has published a head-to-head on a workload you would recognise. The vendor's 40–200× speed claim is theirs, run on their machines; our median wall time of 783 ms includes a network from Asia and is not a rebuttal. And the confidence figures above are from one state, three questions and 20 calls: enough to show the band is real, not enough to tell you where your threshold belongs — that you measure yourself, on your own traffic.

Is Jev an LLM?

No. It is a System One model: it returns a choice from a fixed option set plus calibrated probabilities, in a single parallel pass, instead of generating text one token at a time. TypeSafe's own framing is that strings are general and expensive while decisions are narrow and cheap.

Can an LLM do what Jev does?

Yes, and most teams start there. The cost is structural rather than in quality: you get prose back, so you write a parser, you maintain a schema prompt, and occasionally the model invents an option. We measured the other side of that trade below.

What does Jev not do?

It does not write, summarise, translate or explain. If the answer is a paragraph a human will read, Jev is the wrong tool — the pattern is to let it choose and let an LLM write, which is what several of the projects we read do.

Which is faster in production?

For the shape it is built for, Jev, by the vendor's figures: 70–500 ms against 3–329 seconds for frontier models. Our own calls had a median wall time of 783 ms from one machine in Asia, which is network and TLS on top of their number, not a contradiction of it.

Source our own calls + typesafe.ai Verified 2026-09-23 Our 20 identical calls and the adversarial probe: /typesafe-jev/statisticsVendor figures are quoted from their launch post and dated; the token counts and spreads are ours.