Verbeteringen voor elk inspanningsniveau van de Agent API

Met inspanningsniveaus in de Perplexity Agent API kiezen ontwikkelaars de balans tussen kosten, snelheid en onderzoeksdiepte voor elke taak. Vanaf vandaag kost elk inspanningsniveau minder per query, met een onderzoekskwaliteit die hoger of gelijk is. Een nieuw ultra-niveau is beschikbaar voor het meest omvattende en uitgebreide onderzoek. Elk verzoek dat het niveau bij naam selecteert, zoals effort="fast", krijgt automatisch de bijgewerkte configuratie.

Bij het bouwen van een onderzoeksagent draait het om de juiste balans tussen kosten, snelheid en diepgang voor elke taak. Inspanningsniveaus in de Agent API nemen die beslissing voor de gebruiker. Elk niveau is een gebundelde configuratie die het model, het stappenbudget, de zoekinstellingen en de tools voor een specifiek taaktype vastlegt. Perplexity evalueert en actualiseert elk niveau in de loop van de tijd om het beste onderzoek te leveren tegen de huidige kosten van dat niveau, of lager.

Deze verbeteringen kwamen voort uit twee soorten wijzigingen. Budgetten, contextbeheer en extractie verlaagden de kosten van elke run, en skills, modelselectie en parallelle agents verhoogden of behielden de kwaliteit van het antwoord.

De prestaties van medium verbeterden van 55% naar 77% op BrowseComp en DSQA, terwijl de kosten met bijna 90% daalden. BrowseComp en DSQA zijn openbare onderzoeksbenchmarks; WANDR is de benchmark van Perplexity voor lange onderzoekstaken met meerdere entiteiten. xhigh voert agentisch werk uit, zoals code uitvoeren in een sandbox, lange loops van toolgebruik volhouden en met veel bronnen tegelijk werken. xhigh hield zijn WANDR-score op 76,5% en draaide daarbij tegen ongeveer 25% van de kosten van de configuratie van augustus 2026.

Een verzoek voor Diepgaand onderzoek kan tientallen zoekopdrachten uitvoeren, honderden pagina's lezen en bewijs controleren voordat er een antwoord komt. Elk van die acties voegt tokens toe aan de context en dollars aan de rekening. Zonder limieten blijft een agent acties ondernemen die de kosten verhogen en de context vullen zonder het antwoord te verbeteren. Vijf factoren bepalen het grootste deel van die kosten:

Budgettoewijzing. Agents met een vast budget kunnen zonder stappen komen te zitten en hun run voortijdig beëindigen voordat ze hun taak hebben afgerond. Agents zonder vast budget kunnen daarentegen blijven doorgaan en kosten maken zonder het uiteindelijke antwoord te verbeteren.
Contextoverhead. Zoekresultaten en opgehaalde pagina's bevatten het bewijs, maar zonder controle kan het contextvenster snel vollopen met irrelevante informatie. Contextvensters brengen van stap tot stap kosten met zich mee en overvolle vensters kunnen de prestaties van de agent verminderen.
Workflowselectie. Verschillende taken vragen om verschillende benaderingen. Het opzoeken van één feit, een vraag met meerdere stappen en een breed overzicht van bronnen vereisen elk een andere workflow. Als een model zelf mag kiezen, kiest het vaak een inefficiënte. Elke beschikbare strategie uitgebreid beschrijven in de prompt van de agent lost dit niet op. De extra instructies worden bij elke stap als tokens meegenomen en het model volgt ze na verloop van tijd steeds minder betrouwbaar op.
Modelselectie. Overstappen op een groter model levert mogelijk geen prestatieverbetering op die in verhouding staat tot de extra kosten. Nieuwe modellen verschijnen met veel ophef en gepubliceerde benchmarkscores. Benchmarkwinst kan echter vertekend zijn of wijzen op overfitting van het model. Zonder evaluatie op echte taken kan een modelwissel de kosten verhogen zonder dat de kwaliteit stijgt.
Schalen met meerdere agents. Eén agent kan per run maar een beperkt aantal bronnen doorzoeken, lezen en doordenken. Meerdere agents parallel laten werken verbetert de kwaliteit bij de meest veeleisende taken, maar verhoogt ook de kosten en maakt het geheel complexer als het niet goed wordt aangepakt.

Door elk van deze uitdagingen op te lossen, daalden de kosten voor elk inspanningsniveau zonder dat de prestaties afnamen.

Elk inspanningsniveau heeft een vast onderzoeksbudget met drie componenten:

Stappenlimieten: het aantal beurten dat de agent kan nemen
Toolaanroepen: een limiet op het totale aantal toolaanroepen in een verzoek. Eén stap kan tegelijk meerdere aanroepen naar meerdere tools doen, dus een stappenlimiet alleen bepaalt niet hoeveel acties er binnen een stap plaatsvinden.
Budgetherinneringen: periodieke meldingen van hoeveel stappen er nog over zijn, zodat de agent kan prioriteren en ruimte overhoudt om het antwoord te schrijven in plaats van halverwege de taak zonder budget te komen zitten.

Budget is de centrale afweging: meer stappen betekenen betere antwoorden, en elke stap brengt kosten met zich mee. Bij openai/gpt-6-luna stijgt de nauwkeurigheid op BrowseComp + DSQA van 41% naar 80% als de stappenlimiet van 1 naar 15 wordt verhoogd, terwijl de kosten per query stijgen van $ 0,0017 naar $ 0,0152: ongeveer 9x de kosten voor ongeveer 2x de score.

Een stappenlimiet alleen bepaalt de onderzoekskosten niet. Met hetzelfde budget van vijf stappen doet openai/gpt-6.1-terra meer toolaanroepen dan openai/gpt-6-luna, omdat capabelere modellen vaak meerdere aanroepen in één stap doen. Inspanningsniveaus begrenzen zowel toolaanroepen als stappen. Voor deze modellen is de limiet op toolaanroepen net zo belangrijk als de stappenlimiet.

Elk inspanningsniveau stemt deze limieten af, maar de agent moet ook weten hoeveel stappen en acties hij nog over heeft om het verzoek af te handelen. Zonder die informatie kunnen zijn stappen of acties opraken en moet hij antwoorden voordat het onderzoek klaar is. Het budget wordt aan het begin van de run vermeld en er komen herinneringen binnen naarmate de agent zijn limieten nadert, zodat er ruimte blijft om de resultaten te verifiëren en te leveren. Bij high gelden de herinneringen zowel voor het stappenbudget als voor het budget voor toolaanroepen.

Twee agents, één met een budgetherinnering en één zonder, werden getest op een BrowseComp-taak waarin ze een tv-serie uit de jaren negentig moesten identificeren aan de hand van drie biografieën van castleden. De agent met een herinnering vond het juiste antwoord met 13 van de 40 stappen in het budget. De agent zonder budgetherinnering gebruikte alle 40 stappen en vond het juiste antwoord niet. De loop van die agent eindigde onverwacht en het model was zich niet bewust van het resterende onderzoeksbudget. Herinneringen houden agents gefocust en helpen ze de resterende middelen effectief te prioriteren.

Langlopende onderzoekstaken vullen het contextvenster van het model met zoekresultaten, opgehaalde pagina's en tussentijdse notities. Zodra het vol is, moet de agent stoppen met werken.

Compactie zorgt ervoor dat lange runs blijven werken zonder dat het contextvenster volloopt. Wanneer de context een drempelwaarde overschrijdt, vervangt de agent het werk tot dan toe door een kortere samenvatting van wat hij heeft gevonden en wat er nog resteert, en gaat daarna verder.

Bij compactie blijven altijd drie dingen in de context behouden: de systeemprompt, het oorspronkelijke verzoek en alle skills die de agent al heeft geladen. Na elke compactie ontvangt de agent twee korte instructies. De eerste instructie luidt: ‘Ga door tot de taak klaar is.’ Zo behandelt de agent de samenvatting niet als eindpunt. De tweede instructie vertelt de agent hoeveel compacties er hebben plaatsgevonden, zodat hij zijn resterende onderzoekstaken kan plannen. Lange runs houden het oorspronkelijke doel en plan in beeld, en de kosten van lange loops dalen zonder kwaliteitsverlies.

Elke pagina die de agent leest, wordt aan zijn context toegevoegd, en de agent draagt die bij elke volgende stap mee. Een webpagina bevat informatie die niets met de vraag te maken heeft, zoals navigatie, standaardtekst en andere content.

In plaats van de agent een hele pagina te geven, voert fetch_url eerst een extractiestap uit. De paginatekst wordt samen met de huidige taak van de agent naar een kleiner model gestuurd. Het model geeft alleen de relevante passages terug, letterlijk geciteerd zodat de agent ernaar kan verwijzen. Tijdens een evaluatie werd een pagina van 5.561 tokens teruggebracht tot 293 tokens, waardoor er ruimte vrijkwam voor extra relevante context.

Het gebruik van fetch_url met extractie op het inspanningsniveau high verminderde het aantal invoertokens per query met ongeveer 50%. Extractie verbeterde ook de benchmarkprestaties: 88,0% bij $ 0,073 per query, vergeleken met 83,5% bij $ 0,094 zonder extractie.

Zoeken op het web staat centraal in elk onderzoeksverzoek van een agent. Er zijn drie wijzigingen doorgevoerd in de manier waarop agents zoeken:

Meer context per zoekopdracht: Elke zoekopdracht levert nu tot 4K tokens aan resultaten op in plaats van 2K. De agent vindt sneller wat hij nodig heeft, wat leidt tot minder zoekopdrachten en lagere kosten.

Een nieuwe snippet-engine: Zoekresultaten krijgen snippets die beter aansluiten bij de query, zodat de agent niet wordt overladen met irrelevante tekst.
Fast Search: Voor $ 1,00 per 1K verzoeken verlaagt Fast Search zowel de kosten als de latentie van elke zoekaanroep.

Het Perplexity Search-team verbetert voortdurend de kwaliteit van het ophalen van informatie voor een breed scala aan taken. Recente updates leverden verbeteringen op voor code, ontwikkelaarsdocumentatie, referentiepagina's en juridische en regelgevende content.

Sommige taken vereisen veel zoekopdrachten die parallel worden uitgevoerd; andere vragen om het nauwkeurig lezen van een paar lange documenten.

Maar elke workflow in de systeemprompt van de agent laden zorgt voor contextoverhead en kan ertoe leiden dat het model ondermaats presteert bij eenvoudige taken. In plaats daarvan zijn skills georganiseerd in een boomstructuur met stapsgewijze ontsluiting. Het model laadt relevante skills en instructies terwijl het werkt en laat niet-gerelateerde informatie buiten zijn context. Elke skill kost alleen zijn naam en beschrijving totdat het model besluit dat die bij de taak past en de skill laadt, waarna de volledige instructies aan de context worden toegevoegd en het model de voorgeschreven workflow volgt.

Om te meten wat individuele skills bijdragen, wordt elke skill één voor één verwijderd om kwaliteit en kosten te vergelijken op taken waarbij de baseline-agent die skill had geladen. Deze ablaties laten zien welke workflows de agent helpen en hoe ze de onderzoeksefficiëntie beïnvloeden.

De onderstaande WANDR-benchmarkruns laten zien hoe agents de juiste workflows kiezen voor specifieke taken. Richtlijnen voor wide-search en fanout werden voor elke taak geladen, omdat er telkens meerdere entiteiten onderzocht moesten worden. People-search werd voor slechts 6% van de taken geladen, en alleen wanneer de vragen over personen gingen.

Bij het testen van een andere WANDR-taak laadde de agent de skill people-search met een fanout-patroon om inference engineers in Londen te vinden. Hij breidde 39 functietermen uit tot 117 query's en voegde de resultaten van de eerste ronde vervolgens samen tot 43 unieke profielen voor verdere screening. De skill people-search begeleidde de agent bij deze uitbreiding zonder irrelevante context toe te voegen. Het onderstaande fragment is aangepast uit het script van de agent; de namen van helpers zijn ter illustratie.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

Checkpointing is een andere workflow die agents helpt bij langlopende taken. Het checkpointing-patroon komt uit batchprogrammering. Wanneer een script een lange lijst verwerkt, schrijft het elk resultaat naar schijf zodra het beschikbaar is, in plaats van alles tot het einde in het geheugen te houden. Als het script halverwege crasht of op fouten stuit, gaat er niets verloren: de volgende run leest wat al was opgeslagen en gaat verder waar hij was gebleven, waarbij alleen de mislukte items opnieuw worden geprobeerd.

In een andere WANDR-taak moest de agent de profielen van 188 engineers screenen. Hij laadde het checkpoint-patroon om elk resultaat tijdens het werk vast te leggen. De eerste ronde extraheerde 160 profielen, maar mislukte bij 28. Toen de agent het script opnieuw uitvoerde, sloeg hij de profielen over die al waren vastgelegd en probeerde hij alleen de resterende 28 opnieuw. Zonder het checkpoint zou één slecht record betekenen dat alle 188 opnieuw moesten worden opgehaald.Aangepast Python-fragment; invoerpagina's, screeningsinstructie, schema en imports weggelaten; de namen van helpers zijn ter illustratie.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

Het checkpoint legt geslaagde resultaten vast; het start geen nieuwe pogingen. Doordat de instructie en het schema in de sleutel zijn opgenomen, leiden gewijzigde screeningscriteria tot een nieuwe verwerking.

Niet elke test leverde winst op in kwaliteit en efficiëntie. Er werd geëvalueerd wat er gebeurt als alle skills vooraf in de agent worden geladen voordat die aan zijn taak begint. Op BrowseComp en DSQA verhoogde vooraf laden de kosten met 13%. Op WANDR, waar langere onderzoekstrajecten ervoor zorgen dat opgehaalde content een groter deel van de invoertokens uitmaakt, verlaagt vooraf laden ook de scores. Deze resultaten onderbouwden het blijvende gebruik van stapsgewijze ontsluiting.

Naarmate de mogelijkheden van modellen toenemen, verandert ook het beste model voor elk inspanningsniveau. Perplexity gebruikt een geautomatiseerde onderzoeksloop die aankondigingen en beschikbaarheid van nieuwe modellen bijhoudt. Evaluaties worden gestart zodra een model toegankelijk is.

Wanneer er een nieuw model uitkomt, haalt een geautomatiseerde agent het door de evaluatie-harness. Die varieert de redeneerinspanning, de budgetten voor stappen en toolaanroepen en de toolconfiguraties, en beoordeelt elke run op kwaliteit en kosten ten opzichte van de huidige inspanningsniveaus. Als een run achteruitgaat, onderzoekt de agent waarom, past hij de instellingen aan en voert hij de evaluatie opnieuw uit. Een kandidaat vervangt het huidige model alleen als die beter scoort op kwaliteit tegen dezelfde of lagere kosten.

Openbare benchmarks zijn nuttig, maar hun scores vertalen zich niet altijd naar taken in de praktijk. De onderstaande grafiek toont bijvoorbeeld een kandidaatmodel dat op BrowseComp 13,3 punten boven de baseline scoorde, maar ruim onder de bijbehorende baselines bleef bij interne zakelijke, juridische en financiële onderzoekstaken.

Eén agent kan in één loop maar een beperkt aantal bronnen bestrijken. Bij complexe taken werken meerdere agents parallel, die elk een ander deel van het probleem coördineren.

De primaire agent is de orchestrator. Deze roept spawn_agent aan om onderliggende agents te maken en wijst elk ervan een specifieke, gerichte taak toe. Elke onderliggende agent voert een eigen onderzoeksloop uit met een aparte context en gebruikt een eigen model, eigen tools en een eigen stappenbudget. De onderliggende agents rapporteren hun resultaten aan de bovenliggende agent, die een onderliggende agent een vervolgopdracht kan geven of de voortgang ervan kan controleren. De orchestrator en zijn onderliggende agents wisselen berichten uit om bewijs te delen, blokkades te melden en volgende stappen bij te stellen. Naarmate er nieuwe informatie binnenkomt, verfijnt de orchestrator de opdrachten en voegt hij, wanneer het werk klaar is, de resultaten samen tot één antwoord.

De Agent API ondersteunt vooraf gedefinieerde agentrollen en de orchestrator kan onderliggende agents met aangepaste instructies maken.

Het inspanningsniveau ultra zet drie agents parallel op een taak. Elke agent onderzoekt zelfstandig de hele taak, wat verschillend bewijs oplevert. Een vierde agent voegt hun bevindingen samen, verwijdert dubbele informatie en schrijft het uiteindelijke antwoord.

Op WANDR scoort ultra 85,9% bij $ 21,71 per taak. Dat is de hoogste score van alle geteste configuraties.

Inspanningsniveaus worden voortdurend geëvalueerd en verbeterd. Het niveau dat gebruikers kiezen, bepaalt hoeveel onderzoek een taak krijgt en hoeveel die gaat kosten. Budgetten voor stappen en toolaanroepen, met herinneringen naarmate ze opraken, houden verzoeken binnen het budget. Compactie, extractie en betere snippets houden de context gericht op bewijs. Skills stemmen de workflow af op de taak, en parallelle agents breiden uit wat één loop kan bestrijken. Een geautomatiseerde evaluatieloop laat een nieuw model alleen toe wanneer het de onderzoekskwaliteit verbetert tegen dezelfde kosten.

Elk inspanningsniveau blijft zich ontwikkelen naarmate nieuwe modellen en configuraties zich in evaluaties bewijzen. Wie een niveau bij naam aanroept, krijgt die verbeteringen automatisch; wie een versie vastzet, houdt een configuratie ongewijzigd.

Probeer de Agent API en vergelijk inspanningsniveaus op je eigen workloads. Je vindt details over de inspanningsniveaus in onze documentatie over inspanning in de Agent API.

De kosten van onderzoek

Het onderzoeksbudget beheersen

Context beheren

Compactie

Alleen ophalen wat ertoe doet

Gericht zoeken op het web

De juiste workflow kiezen

Modelselectie

Schalen met meerdere agents

Wat komt er hierna