By TheGitReporter · September 22, 2026
A support message can belong to two departments. A model that returns only “billing” hides the runner-up. A model that returns a distribution gives the application another possibility: route the ticket, copy a second team, or ask someone to check. The difference is what the surrounding software gets to know before it acts.
That is the useful proposition behind Jev. TypeSafe founder Diogo Almeida introduced it on September 15 as an early-access model for structured decisions, using parallel outputs and a training approach the company calls Reinforcement Learning for Calibrated Decisions. Those are TypeSafe's architectural claims, not independently reproduced findings. The launch announcement frames probabilities as part of the product.
For developers drawn to fast, small, local models, Jev raises a good question: how much useful intelligence can fit into a narrow decision? But the evidence changes two assumptions behind that question. Jev's documented access is a hosted API; the reviewed materials do not establish downloadable weights, a parameter count or local inference. And Ollama has already delivered the token-probability feature users spent years requesting. The remaining problem is making the numbers mean what an application thinks they mean.
The Ollama request has an answer
In February 2024, issue #2415 asked Ollama to expose logits or logprobs. The request captured a practical frustration: an application could receive generated text without the information needed to inspect alternatives. The thread eventually became a record of delivery. It closed as completed on November 13, 2025, with a link to the release.
The decisive implementation was baptistejamin's PR #12899, merged November 11. The following day's v0.12.11 release announced logprobs for both Ollama's native API and its OpenAI-compatible API. The earlier BruceMacD proposal, #9282, described restructuring runner responses so they could carry metadata beyond text; it closed without merging. It is useful background, but it is not the shipping change.
The implementation is more than a request flag. The merged diff adds probability fields to requests and responses and wires them through the compatibility layer. At the September 19 revision inspected for this article, request conversion still forwards logprobs and top_logprobs; response conversion carries the results back. Server handlers validate the requested number of alternatives and collect probabilities for non-streaming responses. This establishes an implemented path, not a fresh runtime test.
Even a newer complaint can mislead. In May 2026, issue #16117 alleged that the compatibility endpoint dropped logprobs. A reply showed them being returned. The issue's author acknowledged that the failure was downstream in their own integration. Reading the opening report alone would reverse the finding.
The related request, #3795, remains open, but asks for logit_bias. That is a control for changing which tokens are favored, not a request to observe their likelihoods. An unresolved control feature does not mean the observation feature is absent. Nor should local support be silently extended to cloud service: in a January 2026 reply, Ollama said logprobs were supported only for local models. This investigation did not retest cloud behavior.
Odds over words, odds over decisions
A logit is a model score before conversion into a probability. A logprob is the logarithm of a probability. Exponentiating it recovers the probability; it does not turn that number into a guarantee that the answer is right. In a text model, the immediate event being scored is a token appearing after the preceding context. Ollama's release notes describe that conditional meaning.
This distinction matters even in a tiny classifier. Imagine a local model instructed to emit one label for an incoming message: A for billing, B for delivery, C for a return. If the label is genuinely one token under that model's tokenizer and prompt, its probability can be a useful classification signal. But a system must still account for other possible output tokens, ambiguous messages and categories it forgot to include.
Ollama's API types specify up to 20 top alternatives. Its request validation enforces that range. A desired label outside that list is unobserved, not necessarily impossible. Renormalizing only the labels you received changes the question to a conditional comparison among those labels; it does not recover missing probability mass.
Jev's Choice interface starts from the declared options themselves. It returns the chosen option and a distribution across all options, with up to 255 choices. The developer supplies descriptions that distinguish the options. The documentation recommends including an escape option when the list may be incomplete. This is a different interface from a shortlist drawn from a text model's vocabulary.
Its other primitives cover a rubric-based score and a truth-oriented value called Noul. TypeSafe recommends splitting complicated judgments into narrow questions, evaluating them against the same state and combining their results in ordinary code. That is the consequential design choice: the developer owns the rules connecting judgments. TypeSafe's introduction describes this decomposition.
Calling Jev simply a “logprob model” therefore loses the distinction that makes it interesting. Its public interface supplies decision probabilities; it does not expose itself as a one-token language-model endpoint. Nothing inspected here establishes that Jev is a small local model in disguise.
The confidence number needs a job description
TypeSafe's confidence documentation separates two fields that are easy to conflate. The probabilities describe the options. For Choice and Score, the confidence value is computed from the distribution's shape: concentrated answers receive higher confidence than spread-out answers. Noul does not carry that additional field. A confidence value of 0.9 should not casually be read as an independently established 90 percent chance of success.
Calibration is the harder promise. Among many comparable predictions assigned an 80 percent probability, roughly 80 percent should be correct. TypeSafe's training primer explicitly describes this as a property of groups of predictions, not certainty about one answer. The broader problem predates Jev: Guo and colleagues' 2017 calibration research showed that modern neural networks could produce poorly calibrated confidence estimates.
For the ticket router, the practical test is whether its declared probabilities track outcomes on representative tickets. A concentrated distribution can still pick the wrong department. A schema-valid answer can still misunderstand a customer. Restricting a model to legal actions removes one class of failure; it cannot prove that the selected action suits the situation.
This is also the limit of TypeSafe's launch language about eliminating hallucinations. The announcement grounds its zero-error figure in guaranteed schema matching, rather than an empirical measurement of every kind of factual or decision error. It reports 70–500 millisecond end-to-end responses and notes favorable geography and workload choices in its demonstrations. These are vendor reports, not timings measured here. The company's own caveats belong beside the promise.
The published workflow evaluation also has a specific target. It compares four structured workflows against reference answers derived from two large models, while assuming the workflow code is correct. Agreement with those references is informative, but it is not an audit against real-world outcomes. A correctly executed policy can still encode the wrong policy.
There is another revealing receipt in TypeSafe's public comparison adapter. Its schema construction can ask an LLM to generate a numerical probability for each label; its configuration supports probability and discrete-answer modes. Those generated numbers are not the model's next-token logprobs. The comparison supports examining whole decision interfaces. It does not establish that Jev beats every purpose-built local classifier using token scores.
OptiLLM shows why access below the answer matters
The local branch of this story is already concrete. The codelion/optillm repository now resolves to algorithmicsuperintelligence/optillm. In Ollama's original discussion, codelion pointed readers toward OptiLLM. A reply clarified the relationship: it is an alternative inference path, not a way to make Ollama reveal data its API does not return.
Inspecting OptiLLM beyond its README makes that distinction useful. Its entropy decoder computes measures of the token distribution and uses them to switch among greedy selection and different sampling behaviors. Probabilities become inputs to an algorithm controlling the next step. They are doing work that cannot be recovered from the final paragraph alone.
But access inside a runtime and access through an API are separate claims. The inspected Transformers generation path rejects top_logprobs above 20. When probabilities are requested, it performs a further model forward pass over the completed sequence to calculate them. Its MLX path, in the same file, returns no logprob results. These observations do not support describing OptiLLM as a universal, free, full-vocabulary probability endpoint. They expose the engineering choices hidden behind the feature name.
The transferable lesson is to inspect where a probability is computed, which transformations precede it, what gets discarded and how much work obtaining it adds. A compatible request shape does not settle any of those questions.
A useful local experiment is smaller than the promise
For a developer exploring single-token decisions, a sensible first experiment is a reversible routing task with a compact label set and labeled examples. Ollama's native generation API accepts top-level logprobs: true and top_logprobs. A request can limit output through options.num_predict. Limiting output to one token is not itself a classifier: the prompt must define the task, the tokenizer must represent the labels as intended, and the response must actually contain a usable decision.
This is a proposed experiment, not a tested recipe. Record the exact local model and runtime version. Check label tokenization, whitespace and whether a model emits reasoning before its answer. Treat absent scores as missing data. Compare errors and abstentions on held-out examples, then measure latency with realistic input lengths and both warm and cold starts. One emitted token still requires processing the input. The Transformers generation reference also distinguishes output-length controls from sampling controls that alter token selection.
The important number is how many decisions the system can safely handle at an acceptable error rate and response time—not merely how often the winning label gets a large score. Code can reserve an uncertain case for review, request another fact or send it to a stronger model. Those routes should be judged by their observed outcomes, not by a confidence field's reassuring name.
Jev makes that division of labor explicit in its product interface. Ollama and OptiLLM show that local builders already have material to experiment with. A wider era of fast, specialized decision models remains a proposition to test. The next convincing evidence would be independent calibration results, comparisons with lean local classifiers and reproducible end-to-end measurements. The probability is available; the application still has to earn the right to act on it.
Primary Evidence
Evidence Limits
Public sources and repository code were inspected through September 22, 2026. No Jev API inference, local model benchmark, calibration experiment or cloud compatibility test was run for this article. Ollama's sampler tests were read, not executed. Source code establishes implemented behavior and intended checks, not universal support across every backend and model. Jev's training, performance and type-safety assertions remain attributed to TypeSafe. Its reviewed materials do not establish local weights or model size. The routing example is illustrative, and no user identity has been inferred from issue authorship.