Perplexity riduce i costi di ricerca dell’API per agenti e aggiunge il livello Ultra

Perplexity ha annunciato il 5 novembre 2026 che tutti i livelli di impegno dell’API per agenti ora costano meno per query e ha riferito che la qualità della ricerca è migliorata o rimasta invariata in tutti i preset. Il livello Medium è passato dal 55% al 77% su BrowseComp e DSQA, mentre il costo è diminuito di quasi il 90%; inoltre, è disponibile un nuovo livello Ultra per le ricerche ad ampio raggio.

I livelli di impegno riuniscono la scelta del modello, i limiti relativi alle fasi di ricerca e alle chiamate agli strumenti, il comportamento di ricerca e gli strumenti disponibili in preset denominati. Consentono agli sviluppatori di scegliere un equilibrio tra costi, velocità e profondità della ricerca senza dover configurare separatamente ogni componente. Una richiesta come effort="fast" riceve automaticamente la configurazione aggiornata.

Per il livello xhigh, Perplexity afferma che il punteggio WANDR è rimasto al 76,5%, mentre la configurazione operava a circa il 25% del costo sostenuto nell’agosto 2026. Questo livello è pensato per attività agentiche a risposta aperta, tra cui l’esecuzione di codice in un ambiente sandbox, il mantenimento di lunghe sequenze di utilizzo degli strumenti e la raccolta di prove da numerose fonti.

Il documento di WANDR descrive un insieme di valutazione composto da 500 attività, basate su lavori realistici di raccolta dati. Gli agenti devono individuare le entità che soddisfano i criteri e restituire record con fonti ed estratti verificabili in modo indipendente. I valutatori specifici per ciascuna attività recuperano nuovamente le pagine citate e valutano i record sulla base delle prove, evitando di ricorrere a un insieme statico di risposte corrette.

Ultra impiega quattro agenti per ricerche più ampie

Ultra affianca fast, low, medium, high e xhigh nella documentazione ufficiale sui livelli di impegno. È destinato alle ricerche ad ampio raggio e alla raccolta dati, per le quali la completezza conta più della latenza. La configurazione utilizza anthropic/claude-opus-5-5, ed è disponibile la modalità in background per le esecuzioni prolungate.

Ultra assegna lo stesso problema di ricerca a tre agenti che lavorano in parallelo, consentendo a ciascuno di raccogliere prove in modo indipendente. Un quarto agente riunisce i loro risultati, elimina quelli duplicati e redige la risposta. Perplexity riporta un punteggio WANDR dell’85,9% al costo di 21,71 $ per attività, il risultato più alto tra le configurazioni testate.

Modifiche a budget e contesto riducono i costi di ricerca

La spesa è contenuta a ogni livello mediante limiti al numero di passaggi, un tetto massimo alle chiamate complessive agli strumenti e notifiche periodiche sulla capacità residua. Il limite separato alle chiamate agli strumenti è importante perché un singolo passaggio può avviarne diverse usando strumenti differenti. Le notifiche aiutano l’agente a riservare un budget sufficiente per verificare le prove e fornire una risposta, anziché interrompersi a metà attività.

Un esperimento con openai/gpt-6-luna mostra perché questi limiti sono importanti. Perplexity riferisce che aumentare da 1 a 15 il numero di passaggi consentiti ha portato la precisione su BrowseComp e DSQA dal 41% all’80%, mentre il costo per query è salito da 0,0017 $ a 0,0152 $. La ripartizione del budget influenza quindi sia la qualità della risposta sia il costo necessario per ottenerla.

La compattazione del contesto interviene su un altro fattore di costo. Quando il contesto supera una soglia, il sistema sintetizza il lavoro svolto in precedenza, riassumendo i risultati e le attività ancora da completare, ma conservando il prompt di sistema, la richiesta originale e le competenze caricate. Poi indica all’agente di continuare a lavorare e riporta il numero di compattazioni, così che la sintesi non venga scambiata per un segnale di arresto.

L’estrazione riduce la quantità di informazioni che l’agente deve portare con sé. Invece di fornirgli un’intera pagina, fetch_url chiede a un modello più piccolo di selezionare i passaggi pertinenti all’attività in corso e di citarli alla lettera come riferimento. Con un livello di impegno alto, Perplexity riferisce circa il 50% in meno di token in ingresso per query e un risultato dell’88,0% al costo di 0,073 $ per query, rispetto all’83,5% al costo di 0,094 $ senza estrazione.

Altre modifiche riguardano la ricerca stessa. Ogni ricerca può ora restituire fino a 4K token di risultati, anziché 2K; un nuovo motore per gli estratti seleziona testi più pertinenti alla query e Fast Search costa 1,00 $ ogni 1.000 richieste. Nel complesso, queste modifiche mirano a individuare prove utili con meno ricerche e meno contesto irrilevante.

Valutazione dei flussi di lavoro e stabilità della configurazione

La selezione dei flussi di lavoro utilizza un albero delle competenze con divulgazione progressiva. Inizialmente, nel contesto di una competenza compaiono solo il nome e la descrizione; le istruzioni complete vengono caricate quando il modello stabilisce che il flusso di lavoro è adatto all’attività. Perplexity afferma che precaricare tutte le competenze ha aumentato del 13% i costi su BrowseComp e DSQA e ha ridotto i punteggi WANDR, confermando la scelta di caricare i flussi di lavoro solo quando necessario.

Un sistema di valutazione automatizzato esamina i nuovi modelli non appena diventano accessibili, verificando diverse impostazioni dello sforzo di ragionamento, dei budget per passaggi e chiamate agli strumenti e delle configurazioni degli strumenti. Un candidato sostituisce il modello in uso solo se offre una qualità migliore a un costo pari o inferiore. Perplexity afferma che un candidato ha ottenuto su BrowseComp un punteggio superiore di 13,3 punti rispetto al valore di riferimento, ma è risultato al di sotto dei valori di riferimento nelle attività interne di ricerca aziendale, legale e finanziaria: un esempio del perché i soli risultati dei benchmark pubblici non determinino la selezione.

La documentazione distingue tra nomi dinamici, versioni bloccate e configurazioni congelate. Le chiamate dinamiche recepiscono le modifiche valutate in seguito senza richiedere interventi sul codice; le chiamate con versioni bloccate mantengono una singola release anche dopo l’aggiornamento della configurazione attiva; le chiamate con configurazioni congelate copiano i campi pubblici, ma possono non includere impostazioni esterne allo schema documentato della richiesta. Ultra non dispone di una configurazione congelata e deve essere richiamato per nome.

Per gli sviluppatori, la distinzione pratica riguarda gli aggiornamenti automatici e la riproducibilità: i livelli dinamici recepiscono le revisioni valutate di Perplexity, mentre le versioni bloccate mantengono una configurazione nota. Ultra estende questo sistema per offrire una copertura più ampia e la sua architettura a quattro agenti fa sì che l’orchestrazione rientri nel calcolo del rapporto tra costi e qualità, insieme alla selezione del modello.