Perplexity réduit les coûts de recherche de son API d’agent et ajoute le niveau Ultra

Perplexity a annoncé le 5 novembre 2026 que le coût par requête de tous les niveaux d’effort de son API d’agent était désormais réduit, et a fait état d’une qualité de recherche en hausse ou inchangée pour les différentes configurations prédéfinies. Le niveau Medium est passé de 55 % à 77 % sur BrowseComp et DSQA, tandis que son coût a diminué de près de 90 %, et un nouveau niveau Ultra est disponible pour les recherches de grande ampleur.

Les niveaux d’effort regroupent le choix du modèle, les limites du nombre d’étapes de recherche et d’appels d’outils, le comportement de recherche et les outils disponibles au sein de configurations prédéfinies. Ils permettent aux développeurs de choisir un équilibre entre coût, rapidité et profondeur de recherche sans avoir à configurer séparément chaque composant. Une requête telle que effort="fast" bénéficie automatiquement de la configuration révisée.

Au niveau xhigh, Perplexity indique que le score WANDR est resté à 76,5 %, alors que la configuration fonctionnait à environ 25 % de son coût d’août 2026. Ce niveau est conçu pour les tâches agentiques ouvertes, notamment l’exécution de code dans un bac à sable, le maintien de longues séquences d’utilisation d’outils et la collecte d’éléments de preuve auprès de nombreuses sources.

L’article sur WANDR décrit un ensemble d’évaluation de 500 tâches fondé sur des travaux réalistes de collecte de données. Les agents doivent repérer les entités répondant aux critères et renvoyer des fiches dont les sources et les extraits peuvent être vérifiés indépendamment. Des évaluateurs propres à chaque tâche consultent de nouveau les pages citées et évaluent les fiches au regard des éléments de preuve, évitant ainsi de recourir à un ensemble statique de réponses de référence.

Ultra mobilise quatre agents pour élargir la recherche

Ultra rejoint fast, low, medium, high et xhigh dans la documentation officielle sur les niveaux d’effort. Ce niveau est destiné à la recherche de grande ampleur et à la collecte de données, lorsque l’exhaustivité importe davantage que la latence. La configuration utilise anthropic/claude-opus-5-5, et le mode d’exécution en arrière-plan est disponible pour les tâches de longue durée.

Ultra confie le même problème de recherche à trois agents qui travaillent en parallèle, ce qui permet à chacun de rassembler des éléments de preuve de manière indépendante. Un quatrième agent rassemble leurs résultats, élimine les doublons et rédige la réponse. Perplexity fait état d’un score WANDR de 85,9 % pour un coût de 21,71 $ par tâche, le meilleur résultat parmi les configurations testées.

Les ajustements du budget et du contexte réduisent les coûts de recherche

Les dépenses sont encadrées à chaque niveau par des limites du nombre d’étapes, un plafond du nombre total d’appels d’outils et des notifications périodiques indiquant la capacité restante. Le plafond distinct pour les appels d’outils est important, car une seule étape peut déclencher plusieurs appels à différents outils. Ces notifications aident l’agent à réserver un budget suffisant pour vérifier ses éléments de preuve et fournir une réponse, plutôt que de s’arrêter en cours de tâche.

Une expérience avec openai/gpt-6-luna montre pourquoi ces limites sont importantes. Perplexity indique que le passage de 1 à 15 étapes autorisées a fait progresser la précision sur BrowseComp et DSQA de 41 % à 80 %, tandis que le coût par requête est passé de 0,0017 $ à 0,0152 $. La répartition du budget influe donc à la fois sur la qualité de la réponse et sur son coût.

La réduction du contexte permet de maîtriser un autre facteur de coût. Lorsque le contexte dépasse un seuil, le système résume les travaux précédents en présentant les résultats et les tâches restantes, tout en préservant l’invite système, la requête initiale et les compétences chargées. Il indique ensuite à l’agent de poursuivre son travail et précise le nombre de réductions effectuées, afin que le résumé ne soit pas pris pour une invitation à s’arrêter.

L’extraction réduit la quantité d’informations que l’agent conserve. Au lieu de lui transmettre une page entière, fetch_url demande à un modèle plus petit de sélectionner les passages pertinents pour la tâche en cours et de les citer mot pour mot. Pour le niveau d’effort élevé, Perplexity fait état d’une baisse d’environ 50 % du nombre de jetons d’entrée par requête et d’un résultat de 88,0 % pour 0,073 $ par requête, contre 83,5 % pour 0,094 $ sans extraction.

D’autres changements visent directement la recherche. Chaque recherche peut désormais renvoyer jusqu’à 4K jetons de résultats, contre 2K auparavant ; un nouveau moteur d’extraits sélectionne des textes davantage adaptés à la requête, et Fast Search coûte 1,00 $ pour 1 000 requêtes. Ensemble, ces changements visent à repérer les éléments de preuve utiles au moyen de moins de recherches et avec moins de contexte non pertinent.

Évaluation des flux de travail et stabilité des configurations

La sélection des flux de travail s’appuie sur un arbre de compétences à divulgation progressive. Au départ, une compétence n’occupe que l’espace de son nom et de sa description dans le contexte ; les instructions complètes ne sont fournies qu’une fois que le modèle a déterminé que le flux de travail convient à la tâche. Selon Perplexity, le préchargement de toutes les compétences a augmenté de 13 % les coûts sur BrowseComp et DSQA et réduit les scores WANDR, ce qui confirme l’intérêt de ne charger les flux de travail qu’en cas de besoin.

Un banc d’évaluation automatisé teste les nouveaux modèles dès qu’ils deviennent accessibles, en faisant varier l’effort de raisonnement, les budgets d’étapes et d’appels d’outils, ainsi que les configurations des outils. Un modèle candidat ne remplace le modèle en place que s’il offre une meilleure qualité à coût égal ou inférieur. Perplexity indique qu’un candidat a obtenu un score supérieur de 13,3 points à la référence sur BrowseComp, mais inférieur aux références pour les tâches internes de recherche en entreprise, en droit et en finance, ce qui montre pourquoi les résultats des seuls tests publics ne déterminent pas le choix.

La documentation distingue les noms dynamiques, les versions épinglées et les configurations figées. Les appels dynamiques intègrent les modifications évaluées ultérieurement sans nécessiter de changement de code ; les appels épinglés conservent une version après la mise à jour de la configuration active ; les appels figés copient les champs publics, mais peuvent ne pas inclure les paramètres qui ne figurent pas dans le schéma de requête documenté. Ultra ne propose pas de configuration figée et doit être appelé par son nom.

Pour les développeurs, la distinction pratique oppose les mises à jour automatiques à la reproductibilité : les niveaux dynamiques intègrent les révisions évaluées par Perplexity, tandis que les versions épinglées préservent une configuration connue. Ultra étend ce système à une couverture plus large, et sa conception à quatre agents fait de l’orchestration un facteur du calcul du rapport coût-qualité, au même titre que la sélection du modèle.