Perplexity Decider 1.1: sorting tickets with controllable probabilities and thresholds

Perplexity Decider is a model for typed decisions, such as yes/no, choice between categories and score. In the assistance triage it can help to route a ticket to the appropriate route. It is not a chatbot charged with writing a response to the customer and its probability does not amount to the correctness of the decision.

The Update pplx-decider-v1.1-27b was announced on 6 October 2026 in the official forum. The current quickstart indicates $0.02 per million input tokens, free output and no cost per request. The general changelog retains previous references: for version and price you have to use the updated pages, without mixing information. Perplexity Announcement and quickstart Decisions.

For an SME, the project starts with acceptable categories and errors. An urgent ticket classified as ordinary has different consequences from an ordinary case transferred to a person. Before automating you need to make this difference explicit and define a path to uncertainty.

Why can a marshalling take less than one agent?

An agent can search for data and choose tools to achieve a goal. A fixed-category sorting is often a more restricted task: read the request and propose the route. Entrusting him with the full assistance introduces additional responsibilities, such as responding, promising an intervention or updating a practice.

Decider offers yes/no, choice and score types, according to the quickstart. The shape of the output helps integrate the result into a stream, but does not eliminate semantic errors. A valid category may be the wrong one for the request. Verification must cover the meaning of the decision, not just the format. Documented Behavior.

The Guide to AI Agents for Companies helps distinguish these levels. To begin, a proposed category shown to staff may be enough. Automatic actions come once the business has evidence of behaviour and clear rules for what the system must not decide.

How to define categories that do not overlap?

Categories must be understandable to those who rate tickets. "Commercial" and "information request" may overlap; "technical problem" and "unsatisfied customer" describe different sizes. If operators do not agree on the correct category, the model receives an ambiguous task before it is even used.

It is best to write for each category what it includes, what it excludes and the next path. A request that contains multiple themes may require a main category, multiple labels, or revision. The choice depends on the process. It should not be left implicit just because the API requires a value.

It is useful to keep examples of boundary. A question about the price of a spare may be commercial; a dispute about an already billed price may follow another procedure. The instructions must reflect this distinction. The model should not invent the responsibilities of the department or infer them from the mere similarity of words.

Are confidence and accuracy the same thing?

No. Confidence is information produced by the model about the result, while accuracy is measured by comparing correct decisions and references over a set of cases. A high value doesn't prove that ticket was ranked well. The quickstart recalls this limit and the need to interpret probabilities in context. Indications Perplexity. The same criterion should be reassessed for each model and set of requests: the guide to confidence of JEV and human review links thresholds to observed errors and operational consequences.

The threshold should be chosen on the basis of observed errors and the cost of consequences. A universal threshold is not proposed here: ordinary care and a procedure with critical demands may require different rules. Two categories of the same process can also have asymmetrical risks.

It is also necessary to observe uncertain cases, instead of eliminating them from the evaluation. They are often the ones that show where the categories are unclear or insufficient information. A review path is not a failure of the system: it is an expected part of the service when the automatic decision does not have sufficient evidence.

What outcomes should the flow handle?

The table describes a proposed application design, not functions that the API automatically configures. The external system must record the status of the request and know when a decision is available. A timeout must not make the ticket disappear or generate more independent workings than the same request.

The OpenAI Decisions API face a similar intent with its own characteristics. The useful comparison covers types of output, conditions, quality on business cases and integration. A winner is not declared based on the supplier's price or benchmark, because the behaviour on the Italian process requires specific evidence.

Hypothetical scenario: a distributor sorts the assistance

We imagine a distributor receiving requests about deliveries, returns and technical information. Decider proposes the route, while ordinary rules verify identification of the practice and mandatory data. An operator shall check for doubtful cases and those that may result in commercial commitments.

The team prepares test tickets with different formulations, including messages that contain more problems. Correct answers are defined by the operators before the test. If some examples do not have a shared outcome, the procedure is clarified instead of immediately attributing disagreement to the model.

This is a hypothetical scenario. The useful measure is the correctness by category and the management of cases that require a person. No savings or response times are promised. The pilot must also verify the integration: the correct category must arrive at the right practice and the staff must be able to correct it without losing the context.

Hypothetical scenario: a service company routes contacts

We consider a company that receives requests from the site for quotes, applications and questions from existing customers. The classifier proposes a route, but does not automatically send a bid or decide the commercial value of the contact. A separate rule handles missing data and a person evaluates messages out of perimeter.

The team includes short requests, copied texts, attachments mentioned but missing, and messages that change topic in its tests. A text containing words such as “quote” must not be mechanically classified as a new opportunity if it actually disputes an earlier document. The examples must represent these differences.

This case is also hypothetical. The proposal can be inserted in a stream like that of Zapier Agents and AI by Zapier, but verifying the link actually available. A ready integration is not affirmed here: the point is to separate classification, rules and external actions.

How to prepare an evaluation before automatic sorting?

Open the tab for a classifier test

Define categories, exclusions, and correct outcomes with staff. Prepare representative requests and border cases, without unnecessary personal data. Keep a separate set for verification. It measures errors by category, observes confidence and doubtful cases, then chooses thresholds and human path based on consequences.

It is important to distinguish false routings and excessive revisions. A system can reduce a type of error by sending almost everything to the staff, but this changes the operating value. The evaluation must make the compromise visible, without looking for a single number that hides categories and consequences.

The composition of the test also counts. If it contains above all simple requests, it may suggest a quality that is not found in the real queue. Examples relevant to the company's channels and language are needed. Operator fixes can fuel a later review, keeping separate cases already used to fine-tune instructions.

How to read the API price without stopping at the number?

The current quickstart reports $0.02 per million input tokens, free output and no cost per request. The updated page should be preferred to the general changelog which retains the previous reference to $0.04 and to the initial version. It is a documental discrepancy to be recognized, not a tariff to be freely combined. Price in quickstart.

The total cost includes integration, evaluation, log, overhaul and maintenance. Even a low price per token does not automatically make a system that misclassifies or requires many corrections sustainable. The Guide to AI tokens helps to understand the technical unit, distinct from the cost of the managed practice.

Exemplary invoices or volume estimates are not calculated here. Before adoption you must check the current price list, account availability and applicable conditions. The budget should also consider the alternative route when the service does not respond, because the customer's request remains to be managed.

Do open weights make self-hosting easy?

The model card indicates license Apache 2.0 and requires authenticated Hugging Face access. Report about 49 GiB for weights only: is a reference on the model material, not a complete estimate of the running resources. Memory, runtime and infrastructure should be dimensioned separately. Official Model Card.

Self-hosting can be evaluated when there are requirements and skills that justify it. It involves distributing, updating, monitoring and protecting the service. The weight license does not resolve data rights, personnel access or decision correctness.

For an SME, the API can be an initial path to compare with the internal setup, without assuming that either is always better. The comparison must include data control, maintenance and observed quality. An infrastructure choice makes sense if it supports the process, not just because the model is downloadable.

How to use classification in a voice channel?

A sorting may precede or accompany a conversation, but the voice channel introduces additional ambiguities. A transcript may lose names or denials; the client may correct himself. Before classifying you need to understand which version of the request has been confirmed and what information is missing.

Amazon Nova Sonic concerns voice dialogue and the use of instruments. Decision is about a typed decision. Roles can be designed in the same system, but the link requires testing of its own. It is not enough to transfer the threshold of a set of emails to phone calls with different content.

The Guide to the automation with Zapier shows how a decision can enter an operational path. In any platform, the category must be a controlled data. It should not become an implied permission to send messages, apply discounts, or change conditions without other rules.

What mistakes to avoid with probabilities and thresholds?

The first is to treat confidence and accuracy as synonyms. The second is to choose a threshold because it looks high, without evaluating errors. The third is to force every request into a category. The fourth is to measure only the average result, hiding the behavior on the most delicate requests.

Another mistake is ignoring the change in the process. New products, categories or channels can change the language of tickets. The classifier must be reviewed when the job changes. Staff corrections must be collected by a method that allows to distinguish model error and modified business rule.

Finally, one must not leave the doubtful cases without the owner. A review queue is only useful if someone controls it and knows how to intervene. The system must preserve the state and make visible what remains incomplete. A well-formatted probability does not replace this responsibility.

How to collect corrections without losing the reason?

When an operator changes category, the system should retain the essential pattern. The initial decision could have been wrong, or the ticket could have contained insufficient information. They are different situations and require different interventions: improving instructions, changing the form or providing a request for clarification.

A proportionate register can link proposed category, correct outcome and problem type. You don't have to copy every content in the evaluation track. The team must be able to analyze errors while maintaining control of the data and knowing who can consult the examples.

This review should involve those who know the process. A technician can verify format and API calls, but may not know why a contest follows a particular path. The quality of the classification also depends on this operational knowledge. Making it explicit allows you to fix the system without relying on hidden exceptions in the operators' memory.

Which queue should you start with?

Choose a queue with understandable categories and staff available to define the correct outcomes. Start with proposals visible to operators, observe errors and decide which steps can become automatic. Keep a clear path for ambiguous requests, missing data, and service failures.

If you want to route support requests or contacts without entrusting the entire customer relationship to the model, Giallo can design business automations with categories and revision. The result to be asked is a useful decision in the process, with thresholds motivated by evidence and a person ready to intervene when needed.