Large language models are useful for writing, explaining, and carrying on a conversation. But when an application needs to route a request, choose a tool, or assess urgency, a written response may add little to the task. This is where decision models come in. A decision model evaluates the situation and returns the label, choice, or score the application needs to take the next step.

What is a decision model?

A decision model evaluates context against a defined set of outcomes. You supply the information it should consider and the question it needs to answer, along with permitted choices or a scoring scale.

The output is deliberately bounded: it must come from the outcomes your application defines, such as a label, a yes/no judgment, or a value on a scoring scale. For example, a support application could define billing, technical support, and sales as the possible destinations for a request. The model would return its chosen destination and a probability for each option. Your application can use those values to route the request, apply a confidence threshold, or send an uncertain case to review.

TypeSafe's Jev introduced the System One API format, which pairs a shared state with named questions. Its three question types are Choice for unordered options, Noul for a binary judgment, and Score for an ordered scale. Our GLiDE API uses the same state and questions format.

Models that accept the same request format can still process it differently. Some use compact encoders to score options, while others use decoder-based architectures or additional reasoning to reach a decision.

How do decision models differ from LLMs?

A general-purpose LLM can also select from predefined options and return structured answers. Decision models focus on scoring the available outcomes and often return probabilities for each option alongside the selected answer. The choice depends on how well each approach handles your task, including accuracy, calibration, latency, and cost.

How do decision models differ from classification models?

A classification model assigns one or more labels to an input, such as its topic or sentiment. A thinking decision model makes an initial assessment, then applies additional reasoning when the answer is uncertain.

These categories overlap: a request router can use any of the three and return a label with probabilities. The output alone does not reveal how the model reached its answer.

To choose between them, start with what the task requires: assigning a category, selecting an action, or using additional reasoning to check a calculation or resolve a policy exception.

Consider a refund workflow. Classification can identify the request's topic; a decision model can choose whether to approve, reject, or escalate it. When the choice depends on a calculation or policy exception, a thinking decision model can spend more computation on the uncertain case. The graphic shows where that extra reasoning enters the process.

Use cases for decision models

An AI workflow can involve several decisions before a user gets a result: which information to retrieve, which tool to call, and whether the answer is ready to send. Decision models can handle these individual steps, giving the application a way to evaluate each choice before moving on.

Here are a few of the ways we're seeing developers put decision models to work:

The versatility of decision models is also encouraging more experimental uses. Our robotic navigation and flight simulation demos show how these ideas can extend into simulated environments, while community projects are exploring decision models that select a robot arm's next action.

Top decision models in 2026

The main options range from compact text classifiers to larger multimodal models and hosted decision APIs. This overview, as of October 13, 2026, compares their task focus and access.

Other approaches include adapters such as Bespoke-Nimble-9B-v2, which adds learned decision parameters to a separate base model. For adapters, evaluate the adapter and its required base checkpoint together.

Independent evaluations offer another way to compare the models. In the October 13, 2026 snapshot of the Artificial Analysis Decision Index, GLiDE appears second among the decision models shown, with a displayed score of 54, behind Jev 1.13 at 58. This index combines evaluations of knowledge and hallucination, reasoning, tool calling, and safety classification.

Source: Artificial Analysis, October 13, 2026. Scores are rounded in the chart; Microsoft-Decision-1 also displays 54.

The separate, community-maintained Decision Index 0.3.2 text board adds a broad capability comparison across 160 models. On October 13, vLLM-SR d3 (27B) led with a Full score of 66.26. Fastino GLiDE's no-thinking variant scored 60.21, Jev 1.13.0 60.11, and GLiNER2.5-Decide 9.24.

The Full score combines public benchmarks (20%), private tests of the same skills (50%), and private tasks from new domains (30%). It is an index score, not an accuracy percentage. The GLiDE entry does not evaluate adaptive reasoning, and Decide's result covers a broader task mix than our classification-focused Fast Decisions dataset.

How Fastino's models fit into a workflow

Our model family covers both finding information in an input and using it to decide what happens next. The distinction becomes clearer when you follow a request through the workflow.

Extract and classify with GLiNER

GLiNER2.5 extracts entities, relationships, and structured records, and classifies text. Its Multi variant supports multilingual tasks and combines extraction with classification.

In a refund workflow, extraction can identify a purchase date and requested amount. Your application can verify those values against an order record before evaluating the policy. If the verified facts and rules are fully structured, ordinary code may handle the final decision.

This flexibility predates the recent decision-model launches. The original GLiNER paper introduced entity extraction with types supplied at inference time; GLiNER2 expanded the approach to classification and structured extraction.

Classify and route with GLiNER2.5-Decide

GLiNER2.5-Decide focuses on English classification, including single-label and multi-label decisions with labels supplied at request time.

In a refund workflow, extraction can identify a purchase date and requested amount. Your application can verify those values against an order record before evaluating the policy. If the verified facts and rules are fully structured, ordinary code may handle the final decision.

This flexibility predates the recent decision-model launches. The original GLiNER paper introduced entity extraction with types supplied at inference time; GLiNER2 expanded the approach to classification and structured extraction.

Add reasoning with GLiDE

With GLiDE, short for Generalized Lightweight Decision Engine, we made additional reasoning conditional on uncertainty. It first estimates probabilities for the supplied outcomes. When the initial assessment is confident, it can return that result without further reasoning. When the result is uncertain, GLiDE reasons further and incorporates that reasoning into the final probabilities.

We designed this approach for tasks that require advanced multi-hop reasoning, such as interpreting policy exceptions and evaluating code behavior. It gives difficult cases more computation while keeping the answer in the same structured format.

Inference and fine-tune open weight models

Inference and fine-tune language and decision models, all via one API.

Get started

How to choose a decision model

Start with the decision your application needs to make, then compare models on how well they handle it.

1. Define the possible answers. Decide whether the task needs one choice, several labels, or a score. A message can be both a complaint and a refund request, so those labels should not compete as if only one can be true. GLiDE's Choice questions select one outcome; Decide also supports multi-label classification. Include an option such as other or review for cases that do not fit.

2. Shortlist models that fit the task. Check input types, language support, and reasoning needs against the model overview. For benchmark evidence, Decision Index measures broad decision-making, while our Fast Decisions evaluation focuses on classification. Look for strong results on tasks similar to yours, then test the shortlisted models on your own examples.

3. Compare them on the same examples. Use requests with known correct outcomes, including ambiguous inputs and cases that should go to review. Count consequential errors, such as false approvals, alongside overall accuracy. Measure response time and cost on those same requests. For a thinking model, check whether extra reasoning improves difficult cases enough to justify the added time and expense.

4. Decide when the application should act or ask for review. Check what each model's confidence value means before setting a threshold. For GLiDE Choice questions, confidence is the probability gap between the first and second options. For example, probabilities of 0.70, 0.20, and 0.10 give a margin of 0.50; that does not mean a 50% chance of being correct. Use your evaluation results to choose a threshold, then check how often it accepts a wrong answer or escalates a correct one.

When should you choose open-weight or trainable decision models?

Open weight decision models make trained parameters available under a stated license. Trainable decision models also provide a path to adapting weights with task-specific examples. These are separate capabilities: changing labels at request time does not update the model, and a weight release does not automatically include a complete training workflow.

For enterprise and AI-native teams that want to own more of their intelligence, that control can matter. Our GLiNER2.5-Decide provides Apache 2.0 weights and a documented classification training path. By contrast, Jev's customers customize context and rules in requests, rather than fine-tuning per-account weights.

Consider fine-tuning when the original checkpoint makes recurring domain-specific errors and you have consistently labeled examples. Compare the original and adapted models on held-out cases, including calibration and review decisions. Our training data guide defines the inputs, labels, and correct answers used for classification training.

Open weights also do not automatically mean open-source AI. The Open Source AI Definition requires code and information about training data as well as parameters.

To see these patterns in practice, explore the full Fastino demo library or try the API. If you want to adapt a classifier to your own domain, start with the GLiNER2.5-Decide checkpoint and training materials.