Key takeaways
Decision models accept evidence and a question, then return a bounded answer or probabilities. Some let applications supply the question and answer categories at runtime.
The interface does not imply one architecture. Specialized encoders, adapted language-model backbones and single-token classifiers can implement related behavior.
A probability estimates an outcome. It does not establish correctness for an individual case, authenticate a requester or authorize an action.
Compare decision models with rules, trained classifiers and constrained generation on the same workload. Count errors, review and maintenance alongside inference.
When software needs a category rather than a written response
Consider a support application routing incoming messages to billing, technical support or cancellation queues. The input is the customer’s message; the output is a category, with an additional route for ambiguous requests. Account lookup, subscription changes and the eventual reply happen later. Generating a paragraph to express the routing choice can add work when the application only needs a label.
Decision models target these bounded judgments. The recent releases are worth examining because repeated classification, relevance and screening calls can consume time and inference budget inside larger AI systems. A model designed for those calls may be a better component than a generator configured to write a tiny JSON object. Equally, an existing classifier or rule may already do the job.
The distinction requires more than a product label. Some offerings change the model’s inference computation; others specialize an existing architecture or expose a different API. This article explains what to inspect, where these models fit, and why their outputs still need a separate policy for taking action.
Runtime-defined questions extend the familiar classifier interface
A conventional classifier learns a mapping to defined targets, such as billing, technical support and cancellation. A decision model may instead receive the question and descriptions of the permitted answers with each request. The application can ask whether a passage answers a question, choose which department should receive a message, or rate a defect against specified severity levels.
The distinction is not whether the output contains numbers. Classifiers already return class probabilities. It is whether the model can apply a supplied question or label meaning without training a new prediction head for every task. That capability still needs evaluation on each task; the ability to accept a new question does not demonstrate that the model answers it accurately.
TypeSafe’s Jev documentation describes choices, scores and yes/no judgments against shared input. OpenAI’s Decisions API, generally available as of October 22, 2026, similarly provides predicate, choice and score outputs. These are documented interfaces, not evidence that the providers perform equally well.
Runtime labels also predate the current releases. The GLiClass paper, published in 2025, describes a classifier that processes text and label representations, with several architectural variants. Its released implementation accepts candidate labels and includes training and serving code. Such models belong in the comparison even if their developers do not use the same branding.
The permitted answer set needs care. If a message involves both cancellation and a disputed charge, choosing one exclusive category discards information. Separate judgments or a multi-label classifier may fit better. Adding an “other” option lets a model select it; that option does not guarantee detection of every unsupported input. Missing evidence needs explicit handling too.
A finite-answer interface can use different inference architectures
Liquid AI’s October 7 open d1 release provides a clear example. The company describes d1-3B as derived from a decoder-only vision-language model and d1-omni-600M as derived from a bidirectional encoder with additional modality encoders. Both return answers in a single forward pass rather than generating text. The omni checkpoint is described as experimental.
Their common interface therefore does not identify a common backbone. Nor does a decoder-derived model have to retain the inference procedure of a chat model. Inspect the prediction head, attention behavior and supported serving implementation rather than assuming that a familiar model name settles the computation.
Salesforce’s HyperClassifier account describes another approach. It trains the model to predict a special token representing a class and caches repeated prompt computations. Salesforce says it uses the specialist for intent and routing inside Agentforce. Its reported speed improvement is a vendor result for its implementation, not a transferable speed ratio for every classifier.
Output length is only part of latency. A model must still process the input, and a hosted call may spend time waiting for service capacity or crossing the network. Compare end-to-end latency at realistic input lengths and concurrency. A comparison against a generator producing an explanation does not establish the same advantage against a cached, one-token classifier.
Constrained generation remains a legitimate alternative. A schema can restrict a generated response to permitted fields or categories while retaining a general model’s other capabilities. Structured-output documentation explicitly warns that schema-conforming outputs can still contain mistakes. A specialized decision endpoint also needs substantive evaluation; a valid category can be the wrong category.
Probabilities, confidence scores and correct answers differ
An answer probability is a model estimate. Calibration asks whether those estimates agree with observed frequencies across cases. Predictions assigned a probability near 0.8 should correspond to the relevant outcome roughly that often in the population being evaluated. A single prediction cannot establish calibration.
Guo and colleagues showed that classification accuracy and calibration can differ and evaluated post-processing calibration methods on image and document classification. Their 2017 study does not determine how well a new decision model is calibrated on your workload. It establishes why accuracy alone is insufficient when software uses probabilities to allocate review or select actions.
API fields named “confidence” require a second check. TypeSafe’s confidence documentation defines its Choice confidence as a transformation of the largest option probability relative to an even distribution. The transformation depends on the number of answer options as well as the largest probability. That statistic summarizes the distribution; it is not an independently observed likelihood of correctness. A threshold expressed in that confidence field is not interchangeable with the same numerical threshold on the selected option’s probability.
With three options and a largest probability of 0.8, the documented Choice formula returns confidence 0.7: (0.8 - 1/3) / (1 - 1/3). Neither number establishes that this particular routing decision is correct. Calibration tests whether the probabilities predict error frequencies on relevant cases.
Validate the estimate that the policy actually uses. Inspect errors among accepted cases, the proportion sent for review and performance on relevant input groups. Keep threshold selection separate from the final evaluation. Calibration or a low accepted-case error rate on yesterday’s documents does not guarantee either property after the workload changes.
A routing decision and a business action need different evidence
Return to the hypothetical cancellation request. A model might identify cancellation correctly even when the sender has not authenticated, the message names the wrong account, or the subscription has already ended. Those facts require application state and checks outside the classification itself.
For the routing task, suppose a wrong assignment incurs $20 of extra handling and a perfect manual routing review costs $2, with all other costs equal. Under these invented assumptions, automatic routing costs less when its error probability is below 10%. At a calibrated error estimate of 5%, expected error cost is $1; at 15%, it is $3. Actual review can also make errors, and delay costs can vary by queue. The comparison must use those costs and the probability of the routing error being priced.
Figure 1. Hypothetical routing costs depend on the probability of a wrong assignment. The break-even error rate is 10% under the stated $20 error cost and $2 perfect-review cost. These are invented inputs, not model measurements or recommended thresholds.
Cancellation execution is a separate operation. It requires an authenticated request, the correct subscription and current application state. A message that also disputes a charge may need a billing handoff; the cancellation label does not authorize a refund. A routing probability cannot be reused as the probability that this entire resolution will be correct.
Repeated judgments also do not automatically constitute an agent. An agent selects actions over time, uses tools and receives new observations. A decision model can classify those observations or help choose a next step, but the surrounding system still defines allowed actions, retains state and checks outcomes.
The system must also handle contradictory judgments. Separately computed yes/no estimates do not establish statistical independence. Overlapping categories can have consistent marginal probabilities, but known implication, exclusion or intersection relations constrain the estimates. For example, under the same evidence, the probability that a request concerns both billing and cancellation cannot exceed the probability that it concerns billing.
Compare specialists where repeated semantic judgments consume work
Decision models deserve a test when a workflow repeatedly needs a bounded interpretation of varied text or images, especially when labeled examples are scarce or category definitions change. Routing, relevance filtering and screening are plausible candidates. Eligibility for automatic handling must be demonstrated, not inferred from those examples.
For a stable target with training data, include a task-trained encoder or another classifier. If the input supplies an explicit category or a fixed rule determines the answer, use ordinary code. If the operation requires new text, field extraction, retrieval or extended reasoning, compare a generator or a larger system that actually performs those operations. Forcing every operation into predefined choices can hide omitted evidence or an inadequate task definition.
Keep the comparison practical. Use the same permitted information and count failures and unresolved cases. Measure accepted-case errors, coverage, latency and review effort. Include training, hosting, integration and maintenance, and inspect the license and data-handling terms before selecting local or hosted deployment. Open weights do not imply identical commercial permissions.
Choose among adequate methods by their complete cost and required outcomes. A decision model can justify replacing a generative call when it reduces total work without worsening the quality the application needs. Start with one repeated judgment, specify what would make its answer wrong, and test the model together with the policy that will consume it.