TypeSafe's Jev Costs 400x Less Than an LLM. These 25 Lines of Python Do the Same Job for Free.

TypeSafe AI's Jev model returns typed probabilistic decisions instead of generated text, claiming up to 200x faster inference and 400x lower cost than comparable LLMs on classification tasks. A parody blog post from NobodyWho then reproduced the core trick in 25 lines of Python using a 0.6B-parameter Qwen model run locally through llama.cpp, producing a calibrated phishing classification (Phishing 0.885) with no API call, sparking debate over what Jev actually offers.

Your agent loop has a dirty secret: most of what it does all day is make tiny decisions. Is this input spam? Is this tool call dangerous? Should this ticket go to billing or support? And for every one of those coin-flip decisions, your harness fires up a full frontier LLM, generates a paragraph of reasoning, and charges you for the privilege. A startup called TypeSafe AI built a whole product around that observation. Their model, Jev, skips text generation entirely and returns typed decisions with probabilities attached. The company reports up to 200x faster inference and 400x lower cost than comparable LLMs on classification tasks. The launch hit the front page of Hacker News, LangChain shipped an integration within days, and the usual hype cycle spun up. Then a group called NobodyWho published a blog post with a title designed to start fights: "Jev in 25 lines of Python." It rebuilds the core trick with a 0.6-billion-parameter Qwen model running locally through llama.cpp. That post also went viral, sitting near the top of Hacker News with over 450 points, and the comment section turned into a genuine argument about what Jev actually is. I have not called the Jev API myself. Everything below comes from TypeSafe's announcements, the LangChain writeup, the parody post, and two independent critiques that stress-tested the calibration claims. But the comparison between the two approaches is the most useful 30 minutes you can spend if you build anything with agents, because it exposes a decision you will have to make sooner or later: pay for fast decisions, or build your own. Traditional LLMs are text generators. You prompt, they generate tokens until they decide to stop. Jev is what TypeSafe calls a System One model. It does not generate text at all. You hand it a state, you define the set of possible answers in advance, and it returns each answer with a probability attached. Their framing: a frontier-intelligence function call. Unstructured state in, typed probabilistic decisions out. The training story matters to their pitch. TypeSafe says Jev was trained with reinforcement learning for calibrated decisions RLCD , meaning the training signal rewards not just picking the right answer but attaching honest probabilities to it. That is the "calibrated" part of the marketing: if Jev says 0.7, they claim you can treat that as a real 70 percent chance rather than a vibes-based score. Why would anyone want this? Three use cases keep coming up: On paper it is compelling. The question the internet asked within hours was whether there is actually a there there. The NobodyWho post is labeled a parody, but the code is real, it runs, and it demonstrates something important. Here is their core example, from their public blog post: python import numpy from llama cpp import Llama model = Llama.from pretrained repo id="Qwen/Qwen3-0.6B-GGUF", filename="Qwen3-0.6B-Q8 0.gguf", n ctx=512, logits all=True, verbose=False, labels = "A", "B", "C" choices = "Legitimate", "Spam", "Phishing" email = "Payroll asks for your password on a non-company sign-in page." options = "\n".join f"{label}. {choice}" for label, choice in zip labels, choices, strict=True prompt = f"""<|im start| system Choose one option.<|im end| <|im start| user Email: {email} {options}<|im end| <|im start| assistant <think </think """ model.eval tokens=model.tokenize text=prompt.encode , add bos=False, special=True logits = model.scores model.n tokens - 1 token ids = model.tokenize text=label.encode , add bos=False 0 for label in labels choice logits = numpy.asarray logits token id for token id in token ids logprobs = choice logits - numpy.logaddexp.reduce choice logits probabilities = numpy.exp logprobs For their sample phishing email, the output was: Legitimate 0.031, Spam 0.084, Phishing 0.885. A correct answer with a confidence score, from a model small enough to run on a laptop, with no API call and no data leaving the machine. What the post is really arguing is an architecture claim, not a product claim. The trick Jev performs, reading probabilities directly off the logits for a fixed set of choice tokens instead of generating text, is a well-known technique. Constrain the output space, read the distribution, skip the generation. You can do it with any instruct model that exposes logits, which is most of them. The parody authors are upfront about what they did not replicate: no System One branding, no RLCD training run, no calibration fine-tuning. Their point is narrower and sharper. The primitive, fast local classification with probabilities, is not proprietary. Whether you need TypeSafe's trained version depends on how much you trust its numbers and how much value you place on not running your own inference. There are also serious open implementations now. OpenJev maintains an open reimplementation, there is an sglang-based variant, and DataCamp's roundup of alternatives counts at least seven open-source Jev-style options. The ecosystem voted with its feet within two weeks. Here is where it gets uncomfortable, and where the two most useful critiques landed. Alex Molas, in a post titled "Jev can't be calibrated," makes a statistical argument that deserves to be quoted in spirit: calibration is not just a property of a model. It is a property of a model on a data distribution. A model is calibrated when, across all cases where it predicts 70 percent, roughly 70 percent of them turn out true. But your production data distribution is not TypeSafe's training distribution. Two companies can define spam identically and still see very different traffic. Jev will return the same probability to both for the same input, and it cannot be calibrated for both unless their distributions happen to match. Even if the RLCD training worked perfectly, the calibration guarantee does not transfer to you. He also found sharper evidence. Prompted about a fair coin, Jev reportedly said heads comes up with probability 0.92. That is not a distribution shift problem. A fair coin has one right answer, and 0.92 is nowhere near it. Arcturus Labs ran the systematic version of that test. They swept the stated bias of a coin from 0 to 100 percent in steps of a quarter point, 401 requests in all, and plotted Jev's stated probability against the true one. The result showed the outputs tracking the ideal line poorly across large stretches of the range. Their practical conclusion matches Molas': treat Jev's outputs as scores for ranking and thresholding, not as probabilities you can multiply against dollar amounts. To be fair to TypeSafe, this critique applies to their marketing claim, not to the product's usefulness. Molas himself concedes the core value proposition: if you do not have labeled training data, Jev gives you a universal classifier on day one, where a fine-tuned BERT needs a dataset before it does anything. That is real. But it means the honest way to use Jev, or any of its open clones, is with your own validation set and a reliability curve, not with the training-on-paper calibration baked into your risk math. So which one do you reach for? Both routes share the same architecture: constrained decoding over a fixed choice set, logits instead of generated text. The differences are about operations and trust. The general lesson is bigger than this particular spat. When a well-known technique gets repackaged behind an API with a new name, the parody post is not just mockery, it is a price check on the abstraction. Sometimes the product earns its margin with training, serving quality, and ergonomics. Sometimes it is a 25-line script wearing a suit. Both of those things were true here, in different proportions, and the HN argument was people disagreeing about the ratio. If I were wiring a decision gate into an agent pipeline this week, I would start with the local script on real traffic, log the probabilities, and build a labeled set from whatever the pipeline got right and wrong. That costs an afternoon and produces the one artifact that matters: your own calibration curve. If a 0.6B model's curve is good enough, done, and no invoice ever arrives. If it is not, then TypeSafe's version, or one of the larger open reimplementations, has to beat the curve you measured, not the one in the launch blog post. That order, measure first, buy second, inverts the usual demo-driven adoption path, and it works because classification is one of the rare ML problems where ground truth is cheap to collect after the fact. I write about AI infrastructure, agents, and backend engineering every week. Subscribe, it is free. Do you run classification inside an agent loop today? Are you paying an API for it or rolling your own logits-reading trick? Tell me what your thresholds look like in the comments.