Performance and reliability issues with Agent API

General
1

Hello!
I have started migrating some of my workloads to Agent API as per Perplexity recommendation I received in the email (Subject: "Your Sonar workload runs better on Agent API").

I have couple of use cases on Finance Search and Web Search with Agent API and my observations after first two days of usage are:

  1. Agent API is much slower than Sonar API, one roundtrip takes easily 12 - 15 seconds with API preset “low”.
  2. During the U.S. business hours, I am frequently facing timeouts on my HTTP POST requests with 30 seconds time-out. Most of the time, I get the HTTP 200 response within the preset 3 retries, but sometimes even 3 retries won’t cut it and the API call fails.

Are there any options to speed things up and make them more reliable?

I have a relatively large number of investment instruments (stocks, bonds) where I am using finance search (for stocks) and web search (for bonds) to retrieve some metadata. With 5000 instruments on the list, full run (single threaded) would take approximately 22 hours (!).

2

Hi YardaG, thanks for the detailed report.

We’ll be glad to look into this and provide fixes and/or recommendations. Could you please send a sample of request ID’s as well as request bodies to api@perplexity.ai? This will allow us to look at exactly what is going on.

I will revert with the solutions in this thread for full visibility.

3

Albert, thank you for a prompt response!
I just sent the requested log to api@perplexity.ai few minutes ago.
Please let me know whether you have everything you need for the investigation.

4

Hi @YardaG — following up as promised, with the resolution plus some general guidance for anyone moving from Sonar to the Agent API.

What we found

We ran your exact payloads against the live API. The latency traced back to reasoning effort: presets set both a model tier and a default reasoning effort, and the low preset’s default was spending reasoning tokens on every step. For a deterministic task like yours — classifying instruments into a fixed taxonomy under a strict JSON schema — that effort doesn’t improve the output. Add 1–4 tool invocations per request and round-trips ended up straddling your 30s client timeout.

What changed

We’ve updated the low preset so it now defaults to minimal reasoning. So no code change is needed on your side, you should be set to retest.

Re-running your six instruments (3x each, 18 calls total) on the updated preset: median round-trip ~9s, all calls between ~5s and ~21s, 18/18 successful with zero timeouts and no retries. Before, 9 of 14 attempts timed out and the successes were landing at 18–26s.

If you want to pin the behavior explicitly rather than rely on the preset default, you can set it per request:

{ "preset": "low", "reasoning": { "effort": "minimal" } }

preset: "fast" is also a fine option and benchmarks similarly, with slightly more variability on ambiguous issuers.

Sonar → Agent API: a mental model

  • Sonar is built for single-pass, search-grounded answers: query → search → answer. It’s optimized for exactly that shape of task. The fast and low presets can emulate this behavior.
  • The Agent API is a loop: the model can plan, call tools (web_search, finance_search, …), evaluate results, iterate, then emit output conforming to your schema. You control how much of that machinery each request uses.
  • Presets are effort tiers: fast → xhigh trade latency and cost for depth. Pick the lowest tier that solves your task, then tune from there.
  • Reasoning effort is an independent knob. You can keep a preset and dial reasoning separately. Rule of thumb: extraction and classification → minimal; multi-hop research and synthesis → the default or higher.
  • Latency scales with what the loop does. Tool invocations, reasoning effort, and output size each add time. A request that retrieves, reasons, and validates is doing more than one that only generates.

Over to you

Building on the Agent API? Share what you’re working on in the thread — questions, setups, edge cases, all are welcome.

5

Hi @albert_pplx , thank you very much for your response and investigation!

Couple of related things I would still like to clarify and figure out:

  1. Am I using the right API for my use case? I mean, is Agent API the right choice or should I stick to Sonar API for this simple instrument enrichment task?

  2. If Agent API is the right choice, am I using it correctly? I saw the payloads and they seem to be quite an overkill for the few bits of information I do extract at the end.

  3. Would it be more efficient to implement some batching, e.g. sending multiple instruments in one request? For example, I keep sending quite a massive system prompt outlining the Yahoo Finance sector/industry taxonomy with every request. Is there a way to reuse that across Agent API calls?

Essentially, I am looking for some best practices on how to use the Perplexity APIs.
I did use Perplexity Computer to implement the client on my end, so I hope it is following best practices, but I can’t be sure.

Thank you in advance!

Jaroslav

6

Hi @YardaG, taking your three questions in order.

1) Sonar or Agent API for this task?

Agent API is great for this task. Your task needs two things: live retrieval (finance_search for stocks, web_search for bonds) and output that follows a JSON schema. The Agent API is built for that combination. Sonar is a good fit for single-pass, search-grounded answers in chat format, but your task does not need anything from it that the Agent API lacks. With low + minimal reasoning, your payloads ran well within your 30-second timeout in our test runs. The general rule: pick the API by what the request has to do, then pick the preset that solves the task at your needed level of speed, cost, depth.

2) Is the payload overkill?

The payload isn’t overkill. The structure is right: preset, tools, response_format with a strict schema, capped max_output_tokens. Three things worth testing:

  • Send only the tool each request needs. Stocks get finance_search, bonds get web_search. Fewer tools means fewer decisions in the loop.

  • Move the taxonomy into the schema. If sector and industry are enum values in response_format, the model cannot return an invalid pair, and the prose taxonomy in your system prompt can shrink.

  • Set reasoning to minimal explicitly if you want it pinned. The updated low preset already defaults there.

3) Batching and reusing the system prompt

Prompt reuse: caching already does this for you. On supported models, repeated identical prompt prefixes are billed at the model’s cache-read rate (per-model rates are on the models page). Keep the taxonomy identical at the start of instructions and put the per-instrument content at the end. Check usage.cache_read_input_tokens in the response to confirm cache hits.

Multiple instruments per request: usually slower, not faster. Each instrument still needs its own searches. A 10-instrument request runs all of those tool calls one after another inside a single response, and if the request fails, you lose all 10 results.

For throughput, run requests in parallel instead. About 10 concurrent workers, with backoff on 429s, brings your 5,000-instrument run from ~22 hours down to roughly an hour. Another option is "background": true: the API returns immediately, you poll GET /v1/responses/{id}, and client timeouts stop mattering.

From what we saw in your payloads, the client got the fundamentals right: strict schema, retries, sensible token caps. Happy to look at the revised setup or answer any further questions