Jev vs. GPT: What Changes When You Stop Generating Text

Most people arrive at Jev with a GPT-shaped mental model. You have a prompt, you get a string back, you parse it. The question is whether the new thing is a drop-in replacement, a different tool entirely, or marketing.

It is the middle one. Jev and GPT models overlap on exactly one job — turning unstructured input into a decision — and diverge on everything else. If that one job is what you are doing in a loop, the difference matters a great deal. If you need anything else, Jev cannot help you at all.

Here is the comparison, without the launch-week framing.

The one architectural difference everything else follows from

GPT models are autoregressive. They generate a token, condition on it, generate the next, and repeat. That loop is the source of their flexibility and of nearly every constraint you work around.

Jev does not have that loop. It evaluates typed questions against a state and computes every output in a single pass. TypeSafe calls this a System One model, after Kahneman's fast, automatic thinking, as opposed to the slow deliberate kind.

Four consequences drop out of that, and they are the entire story:

Latency stops scaling with output length. A GPT model answering at length takes proportionally longer. Jev returns the same shape of answer whether you asked one question or ten, because they are computed together rather than in sequence.

Output tokens cost nothing. There is no generation loop to bill for. Jev is $0.042 per Mtok on input and free on output. That is not a discount, it is the absence of a cost.

Invalid outputs become unrepresentable. Not unlikely. A Choice over three options returns one of those three keys, because there is no mechanism by which it could return anything else.

Text generation becomes impossible. Same reason. There is no loop to generate with.

What you actually get back

This is the part that changes how you write code.

Ask a GPT model to classify a support ticket and you get a string. Maybe billing. Maybe Billing. Maybe Based on the content, this appears to be a billing issue. You handle all three, plus the case where it invents a fourth category you never offered.

# The GPT shape: hope, then parse, then validate.
response = client.chat.completions.create(
    model="gpt-5.6",
    messages=[{"role": "user", "content": f"Classify this ticket as billing, technical, or sales:\n\n{ticket}"}],
)
raw = response.choices[0].message.content.strip().lower()
if raw not in {"billing", "technical", "sales"}:
    raw = "unknown"  # now what?

Ask Jev the same thing and you get the answer plus the distribution that produced it.

from typesafe_sdk import Choice, TypeSafeClient
 
client = TypeSafeClient()
 
response = client.system_one(
    state=ticket,
    questions={
        "category": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Charges, invoices, refunds, subscriptions",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
    },
)
 
answer = response.answers["category"]
answer.choice         # "technical"
answer.confidence     # 0.78
answer.probabilities  # {"technical": 0.85, "billing": 0.15, "sales": 0.0}

The probabilities field is the real difference, and it is easy to skim past. A GPT model that says technical and a GPT model that would have said technical by a hair look identical in the response. Jev tells you which one you got. That single number is what lets you route a 0.98 straight through and send a 0.42 to a human, instead of treating every answer as equally trustworthy.

Structured outputs get you partway, and the founder's argument against them

The obvious objection: GPT models already have structured output modes and JSON schemas. Why not use those?

They do help, and for many jobs they are enough. But they solve a different problem. Constrained decoding guarantees the shape of the output by masking invalid tokens during generation. You still pay for the generation, you still wait for it, and you do not get a calibrated distribution over the alternatives.

Diogo Almeida, TypeSafe's founder, made a sharper argument on Hacker News:

constrained decoding (OpenAI-style structured outputs) make models dumber unfortunately — the short+dense version is that simply masking logits is insufficient because if ever a model was assigning probability to an invalid token, the model is by definition confused. you'd be better off erroring IMO

Take that as a claim rather than a finding — it is the vendor's position and the mechanism is not published. But the narrower point stands on its own: masking a token you did not want is not the same as never having been able to produce it.

Cost and latency, with the honest numbers

TypeSafe's launch materials advertise 193.6x faster and 444.6x cheaper. Those come from vendor-run benchmarks on workflows their own team wrote, and they represent, in TypeSafe's own words, the higher end of real-world gains.

Community members who measured their own workloads report medians closer to 7x on speed and 30x on cost. Both sets of numbers are real. The gap is mostly that the headline figures compare against an LLM doing more work than the task strictly requires.

Even at the conservative end, 7x and 30x change what is architecturally possible. A classifier you can afford to run on every row of a table is a different tool from one you invoke selectively.

The concrete figures, which do not depend on anyone's benchmark:

TypeSafe notes the rate limits can change without notice while they scale.

Jev is not smarter, and TypeSafe does not claim it is

This is the number that gets lost in the launch coverage, and it is the one that should shape your expectations.

On TypeSafe's own four-workflow benchmark:

Jev ties the weaker GPT configuration and sits several points below the stronger frontier models. The pitch is parity at two orders of magnitude less cost, not superiority. Anyone telling you Jev outperforms GPT on judgment is selling something.

What Jev does have is calibration. An independent evaluation by Emil Lindfors on Norwegian policy documents found that when Jev reported 0.9 or higher confidence, it was correct 94% of the time. That is the property that makes confidence-gated routing work, and it is not something you get from a GPT model's self-reported certainty.

What GPT does that Jev cannot

Not "does better." Cannot do:

• Generate text. No summaries, no drafts, no explanations, no rewriting. TypeSafe's docs are blunt: if you need to generate, use a generative model.
• Count or do arithmetic. Jev recognizes the shape of an answer rather than tallying, and the error grows with the size of the thing being counted.
• Compare dates. It reads dates as text, not ordered quantities. Which of two dates comes first is unreliable.
• Multi-hop reasoning. Questions that require several inferential steps cost accuracy. One snap judgment per question is the design.
• Explain itself. You get a distribution, not a rationale. In a regulated setting where you must justify a decision, that is a real gap — though it is worth asking how much an LLM's post-hoc explanation is actually worth as an audit trail.

There is also no image, audio, or video input. State is text or JSON, full stop.

The mental model that makes this easy

Almeida's own framing on Hacker News is the clearest one available:

choice maps to 'match' statement, 'score' maps to sorting, 'noul' short for bernoulli maps to if-statements

That is the whole thing. GPT is a tool for producing language. Jev is a tool for making the branching decisions your code was already going to make, except now those branches can depend on meaning rather than on regular expressions.

Once you see it that way, the question stops being which one is better and becomes which part of your system you are looking at.

So which should you use

Use a GPT model when the output is text a human will read, when the task needs several reasoning steps, when you need arithmetic or dates handled, or when you need the model to explain itself.

Use Jev when the output is a decision your code will branch on: routing, classification, ranking, scoring, tool selection, guardrails, filtering. Especially when it runs in a loop, on every row, or inside a latency budget that a multi-second LLM call would blow.

Use both when a cheap classifier in front of an expensive model saves you from sending everything to the expensive model. This is the documented intent routing pattern, and it is probably the most common production shape: Jev decides what kind of request this is, and a GPT model handles the ones that genuinely need prose.

One last thing, because it is the claim most likely to mislead you. TypeSafe leads with "can't hallucinate," and the guarantee is narrower than it sounds: schema conformance, not correctness. A confidently wrong answer is still perfectly type-safe. Almeida concedes the point himself — "because these models are probabilistic, it's also possible to be confidently wrong." Treat Jev's output as a well-calibrated guess with a number attached, not as ground truth, and the calibration becomes genuinely useful rather than a trap.