A 25-line Python example is circulating as “Jev,” but its publisher explicitly describes the post as a parody. The code demonstrates a general technique: prompt an ordinary GGUF language model with fixed choices, inspect the logits assigned to each choice at the final position, and normalize those scores into probabilities.
import numpy
labels = ["A", "B", "C"]
choices = ["Legitimate", "Spam", "Phishing"]
# The model and prompt have already been evaluated.
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)
values = numpy.round(probabilities.astype(float), 3).tolist()
print(dict(zip(choices, values, strict=True)))In the supplied example, the script loads Qwen3-0.6B, presents three email-classification labels, and reports an 88.5% probability for “Phishing.” That result shows how one model responded to one prompt. It does not establish that the model is accurate, calibrated, or equivalent to a separately trained decision system.
TypeSafe’s own announcement describes Jev more broadly as a System One model optimized for fast, structured, probabilistic decisions. The company says it uses a parallel sampler and a training method called Reinforcement Learning for Calibrated Decisions, and it positions the model for software workflows that classify, route, score, or branch. Those performance and calibration statements are publisher claims; the supplied packet contains no independent head-to-head evaluation.
The central distinction is therefore architectural and evidentiary, not cosmetic. Reading probabilities for a few tokens is reproducible with conventional inference code, while TypeSafe is claiming a dedicated model, sampling stack, and training process. The parody post itself acknowledges that its probabilities are not always correct and points readers toward more complete open implementations.
The practical lesson is that a short script can be useful for experimentation, including local processing that does not send prompt data to an API. It cannot, by itself, validate production reliability. Before treating such scores as software decisions, developers still need task-specific tests of accuracy, output consistency, and whether higher reported confidence corresponds to better results—questions the supplied sources do not resolve.
The article discusses conventional local inference code and the practical possibility of processing prompts without sending them to an API.