Perplexity released Decider v1.3 and Decider Flash v1.3 on November 12, 2026, adding a feature called locate that extracts matching text and its character positions from an input. Both models support text and images, and are available as Apache-licensed open weights on Hugging Face, through OpenRouter, and through the Perplexity Decisions API, according to the company’s release announcement.
The release updates an existing decision-model family. These models take an input, answer questions about it, and return probabilities over specified choices. They target application steps that need a label, score, routing decision, or extracted passage instead of a written response.
The most consequential addition is the combination: one request can now classify a document, score it, and extract relevant spans from the same input. That creates a useful replacement candidate for LLM calls currently prompted to return a few fields of JSON.
When a Decision Model Can Replace a Generative Call
Decider accepts a shared input, called the state, plus questions about it. Its classification question types cover yes/no decisions, multiple-choice labels, and ordered scoring levels. Each question returns a probability distribution over the available answers.
A support system, for example, could submit a customer message and ask which department should handle it, whether it contains sensitive information, and how urgent it appears. The answers come from defined choices instead of generated label strings.
Perplexity describes several intended applications in its technical announcement:
| Application | A suitable decision task | What still needs another component |
|---|---|---|
| Classification and tagging | Assign a topic, intent, or document type | Writing a summary or explanation |
| Model routing | Decide which requests need a more capable model | Producing the eventual answer |
| Moderation and security | Flag harmful content, phishing, or prompt injection | Applying policy, handling appeals, and deciding enforcement |
| Retrieval and ranking | Score candidate results for relevance | Finding the candidate documents |
| Output evaluation | Assess an answer’s faithfulness, quality, or safety | Establishing ground truth and investigating errors |
| Extraction | Locate names, personal information, or answer passages | Normalizing values or synthesizing information absent from the input |
The practical boundary is the required output. If an application needs to choose from known labels or copy an existing passage, Decider is worth evaluating. If it needs to explain a contract, compose a response, or combine several passages into a new answer, a generative model still has work to do.
I’d start with classification calls that already return tiny, rigid outputs. Asking a generative LLM to emit one category inside a JSON object adds a text-generation and parsing step to a decision problem. Decider’s interface fits that task more directly.
That fit is architectural, not proof of better accuracy. This analysis relies on Perplexity’s published documentation, without independent testing; performance improvements described in the announcement are company-reported.
Locate Returns Source Text, Positions, and Scores
A locate question describes what to find in the state. The description can be a short entity label, such as a location, or an instruction specifying the desired passage.
Perplexity says the model returns the exact matching text, start and end character positions, and, according to the API changelog, a score for each span. When it finds no matches, it returns an empty list.
Consider this illustrative input, not an API request or tested result:
Role: Senior analyst. Location: Paris. Required skills: SQL.
An application could ask three questions about that same state:
- Classification: Does the role require senior-level experience?
- Locate: Extract the city where the job is located.
- Locate: Extract the required skills.
For the location question, the relevant source span is Paris. Its positions let application code identify that occurrence in the original text. This matters when a document repeats a name or phrase: returning the string alone may leave the application unsure which occurrence to highlight.
The important distinction is that locate selects text already present in the state. It is suited to named-entity recognition, identifying personally identifiable information, and extractive question answering. It cannot supply an answer that requires writing something new.
That boundary also separates extraction from normalization. A pipeline might locate a date written as “next Friday,” but converting that phrase into a calendar date requires reference context and a separate processing step. Likewise, extracting an organization’s name and mapping it to a database identifier are different tasks.
I see the offsets as the most useful application detail. They give software a direct connection between a prediction and its source passage, which can support highlights, review screens, and proposed redactions. The positions help identify what to act on; they do not make the selection automatically correct.
Locate Is Text-Only, Even Though the Models Support Vision
The changelog specifies that locate works on a string state, reads text only, and cannot be combined with web grounding. Only the v1.3 models support it.
An image-classification workflow therefore should not be confused with image-span extraction. To use locate on a scanned document, a developer would first need a separate step to obtain text, then submit that text for extraction. Any returned offsets refer to that text, not page coordinates.
For redaction, I’d validate the returned text against the corresponding source substring before applying changes. Preserve the exact input string, check the API’s offset convention, and test multilingual text and repeated matches. A correct entity prediction can still produce a bad edit if downstream code indexes a modified version of the document.
How Decider Avoids Token-by-Token Answers
Perplexity builds Decider by adapting generative LLM backbones. Its training explanation describes a shared state followed by question blocks containing the question and possible answers.
Each answer option receives a predefined label token. At a special marker position, a learned linear output layer, called a decision head, converts the model’s internal representation into scores for those options. Those scores become probabilities.
Perplexity initializes this head from selected rows of the backbone’s vocabulary output layer and trains it for the decision format. Training examples come from hundreds of public datasets converted into the shared state-and-question structure, the company says.
The consequence is straightforward: classification answers do not require autoregressively generating a response token by token. Multiple questions can share computation over the same state in a single forward pass.
Version 1.3 also uses bidirectional attention in the backbone’s full-attention layers. Causal attention lets a token use itself and earlier tokens; bidirectional attention lets it incorporate context from both directions. That is useful for understanding a complete input before assigning a label.
The changelog adds an important serving detail: each question is isolated from the others. Developers can group questions about one document while keeping the questions from directly influencing one another’s answers.
Shared processing offers an efficiency opportunity, but actual latency and throughput still depend on input length, question count, serving infrastructure, and model choice.
Hugging Face, OpenRouter, and API Deployment Paths
Decider v1.3 has 27 billion parameters, while Decider Flash v1.3 has 4 billion, according to Perplexity’s API documentation. Perplexity describes Flash as a smaller model distilled from the larger Decider.
Both are offered through three distribution paths, with different operational responsibilities:
| Path | What is available | Practical consideration |
|---|---|---|
| Hugging Face | Apache-licensed weights for Decider v1.3 and Flash v1.3 |
Frequently Asked Questions
3 questions
1Can Decider v1.3 Extract Text Directly From Images?
No. Both models accept text and images, but locate reads text only. Image documents need a separate text-extraction step before using that feature.
