KI-Modelle und Plattformen
Perplexity senkt die Recherchekosten der Agent API und ergänzt Ultra um eine höhere Aufwandsstufe

Perplexity gab am 5. November 2026 bekannt, dass jede Aufwandsstufe der Agenten-API nun weniger pro Anfrage kostet. Zugleich berichtete das Unternehmen von einer höheren oder unveränderten Recherchequalität bei den verschiedenen Voreinstellungen. Bei Medium stieg das Ergebnis auf BrowseComp und DSQA von 55 % auf 77 %, während die Kosten um fast 90 % sanken. Außerdem ist eine neue Stufe namens Ultra für umfangreiche Recherchen verfügbar.
Aufwandsstufen bündeln die Modellauswahl, Begrenzungen für Rechercheschritte und Tool-Aufrufe, das Suchverhalten sowie verfügbare Tools in benannten Voreinstellungen. So können Entwickler Kosten, Geschwindigkeit und Recherchetiefe aufeinander abstimmen, ohne jede Komponente einzeln konfigurieren zu müssen. Eine Anfrage wie effort="fast" übernimmt die überarbeitete Konfiguration automatisch.
Laut Perplexity blieb der WANDR-Wert bei xhigh mit 76,5 % stabil, während die Konfiguration nur etwa 25 % der Kosten vom August 2026 verursachte. Diese Stufe ist für offene, agentische Aufgaben gedacht, etwa das Ausführen von Code in einer Sandbox, lange Tool-Nutzungsschleifen und das Sammeln von Belegen aus zahlreichen Quellen.
Das WANDR-Paper beschreibt einen Evaluierungssatz mit 500 Aufgaben, der auf realistischen Datenerfassungsarbeiten basiert. Agenten müssen geeignete Entitäten finden und Datensätze zurückgeben, deren Quellen und Auszüge sich unabhängig überprüfen lassen. Aufgabenspezifische Prüfer rufen die zitierten Seiten erneut auf und bewerten die Datensätze anhand dieser Belege, statt auf einen statischen Satz von Musterantworten zurückzugreifen.
Ultra setzt für umfangreichere Recherchen vier Agenten ein
In der offiziellen Dokumentation zu den Aufwandsstufen ergänzt Ultra die Stufen Fast, Low, Medium, High und xhigh. Ultra ist für umfangreiche Recherchen und Datenerfassung vorgesehen, bei denen Vollständigkeit wichtiger ist als eine kurze Antwortzeit. Die Konfiguration verwendet anthropic/claude-opus-5-5, außerdem steht für lange Abläufe ein Hintergrundmodus zur Verfügung.
Ultra weist drei parallel arbeitenden Agenten dieselbe Rechercheaufgabe zu, sodass jeder unabhängig Belege zusammentragen kann. Ein vierter Agent führt ihre Ergebnisse zusammen, entfernt doppelte Funde und formuliert die Antwort. Perplexity gibt für Ultra einen WANDR-Wert von 85,9 % bei Kosten von 21,71 $ pro Aufgabe an – das beste Ergebnis unter den getesteten Konfigurationen.
Änderungen an Budget und Kontext senken die Recherchekosten
Die Ausgaben werden auf jeder Stufe durch Begrenzungen der Schrittzahl, eine Obergrenze für die Gesamtzahl der Tool-Aufrufe und regelmäßige Hinweise auf die verbleibenden Ressourcen beschränkt. Die separate Obergrenze für Tool-Aufrufe ist wichtig, weil ein einzelner Schritt mehrere Aufrufe über verschiedene Tools hinweg auslösen kann. Die Hinweise helfen dem Agenten, genügend Budget einzuplanen, um seine Belege zu prüfen und eine Antwort zu liefern, statt mitten in der Aufgabe abzubrechen.
Ein Experiment mit openai/gpt-6-luna zeigt, warum diese Begrenzungen wichtig sind. Perplexity berichtet, dass eine Erhöhung der zulässigen Schrittzahl von 1 auf 15 die Genauigkeit bei BrowseComp und DSQA von 41 % auf 80 % steigerte, während die Kosten pro Anfrage von 0,0017 $ auf 0,0152 $ zunahmen. Die Budgetverteilung beeinflusst somit sowohl die Qualität der Antwort als auch deren Kosten.
Die Verdichtung des Kontexts geht einen weiteren Kostentreiber an. Sobald der Kontext einen Schwellenwert überschreitet, fasst das System die bisherige Arbeit in einer Übersicht der Ergebnisse und noch ausstehenden Aufgaben zusammen. Dabei bleiben der System-Prompt, die ursprüngliche Anfrage und alle geladenen Skills erhalten. Anschließend weist das System den Agenten an, weiterzuarbeiten, und gibt die Anzahl der Verdichtungen an, damit die Zusammenfassung nicht irrtümlich als Aufforderung zum Abbruch verstanden wird.
Durch Extraktion muss der Agent weniger Informationen mitführen. Statt ihm eine ganze Seite zu übergeben, fetch_url beauftragt das System ein kleineres Modell damit, für die aktuelle Aufgabe relevante Passagen auszuwählen und sie für Zitate wortgetreu wiederzugeben. Bei hoher Aufwandsstufe meldet Perplexity pro Anfrage rund 50 % weniger Eingabe-Token sowie ein Ergebnis von 88,0 % bei Kosten von 0,073 $ pro Anfrage. Ohne Extraktion lag das Ergebnis bei 83,5 % und die Kosten bei 0,094 $.
Weitere Änderungen betreffen die Suche selbst. Jede Suche kann nun bis zu 4K Token an Ergebnissen zurückgeben, statt 2K. Eine neue Snippet-Engine wählt Textpassagen aus, die besser zur Suchanfrage passen, und Fast Search kostet 1,00 $ pro 1.000 Anfragen. Zusammen sollen diese Änderungen dabei helfen, relevante Belege mit weniger Suchvorgängen und weniger irrelevanten Kontextinformationen zu finden.
Workflow-Evaluierung und Stabilität der Konfiguration
Die Auswahl des Workflows erfolgt mithilfe eines Skill-Baums, der schrittweise weitere Informationen einblendet. Zunächst nimmt ein Skill im Kontext nur den Platz seines Namens und seiner Beschreibung ein. Die vollständigen Anweisungen werden erst geladen, wenn das Modell entscheidet, dass der Workflow zur Aufgabe passt. Perplexity zufolge stiegen die Kosten bei BrowseComp und DSQA um 13 %, wenn alle Skills vorab geladen wurden; zugleich sanken die WANDR-Werte. Das spreche dafür, Workflows nur bei Bedarf zu laden.
Ein automatisiertes Testsystem bewertet neu verfügbare Modelle, sobald sie zugänglich werden. Dabei variiert es den Denkaufwand, die Schritt- und Tool-Aufruf-Budgets sowie die Tool-Konfigurationen. Ein Kandidat ersetzt das bisherige Modell nur, wenn er bei gleichen oder niedrigeren Kosten eine bessere Qualität liefert. Perplexity zufolge lag ein Kandidat bei BrowseComp 13,3 Punkte über dem Ausgangswert, schnitt bei internen Rechercheaufgaben aus den Bereichen Unternehmen, Recht und Finanzen jedoch schlechter ab. Das verdeutlicht, warum öffentliche Benchmark-Ergebnisse allein nicht über die Auswahl entscheiden.
Die Dokumentation unterscheidet zwischen dynamischen Bezeichnungen, festgelegten Versionen und eingefrorenen Konfigurationen. Dynamische Aufrufe übernehmen später ausgewertete Änderungen, ohne dass der Code angepasst werden muss; festgelegte Aufrufe behalten eine Version bei, auch wenn die aktive Konfiguration aktualisiert wird; eingefrorene Aufrufe kopieren öffentliche Felder, übernehmen jedoch möglicherweise keine Einstellungen, die außerhalb des dokumentierten Anfrage-Schemas liegen. Für Ultra gibt es keine eingefrorene Konfiguration; das Modell muss namentlich aufgerufen werden.
Für Entwickler besteht der praktische Unterschied zwischen automatischen Aktualisierungen und Reproduzierbarkeit: Dynamische Stufen übernehmen die ausgewerteten Überarbeitungen von Perplexity, während festgelegte Versionen eine bekannte Konfiguration beibehalten. Ultra erweitert dieses System auf eine breitere Abdeckung. Durch den Einsatz von vier Agenten fließt auch die Orchestrierung in die Abwägung zwischen Kosten und Qualität ein, neben der Modellauswahl.












