Choosing a deep research API: depth, speed, cost and citations

A deep research API takes a question and returns a researched report. Behind the call, the service plans, searches, reads many sources and writes up what it found, with citations. Several model providers and search companies offer one, and they differ less in whether they can do this than in how they balance depth against speed and cost, how they structure the output, and how far their citations can be trusted. This guide works through those trade-offs and gives you a way to evaluate candidates on your own questions. If the concept is new, start with what deep research is; if you are still deciding whether to buy at all, see build a research agent or buy deep research.

What you are actually buying

Every deep research service runs some version of the same loop: split the question into sub-questions, search, read, decide what is still missing, search again, then synthesize. What you pay for is how well that loop is tuned, which sources it can reach and how the result is packaged. Vendors that offer deep research through an API include OpenAI, Perplexity and Exa, among others; check each vendor's documentation for the current endpoints and options, because this category changes quickly.

Two things are rarely visible from outside, and both deserve a direct question. First, which sources the service can and cannot reach: paywalled content, PDFs, sites in languages other than English, pages that need a login. Second, whether you can restrict the run to sources you choose, for example a list of official domains for a regulatory question.

Depth, speed and cost pull against each other

More depth means more searches, more pages read and more reasoning, and therefore more time and more cost. Services usually expose this as a mode or effort setting, or as separate products for quick and thorough research.

More depth is not automatically better. For a narrow factual question, a deep run can add length without adding accuracy, and a longer report takes longer to review. Match the setting to the cost of being wrong and to the time a reader will actually spend checking.

Pricing models vary: per request, per token consumed, per search performed, or a mix. Because the internal work of a deep run is variable, two identical requests can cost different amounts. Price the question types you really run, not a single sample, and set a spending ceiling per run so a runaway loop stops; put a ceiling on agent spend explains the reasoning.

When you need deep research fast

Agents often need research inside a loop, where a long wait for a report blocks everything downstream. Speed comes from a handful of levers, and each one costs something:

• Fewer rounds. The service stops earlier and may miss a source a deeper run would have found.
• Narrower sources. Restricting the run to known domains saves search time and also reduces coverage.
• Asynchronous jobs. You submit the question and collect the result later, by polling or through a webhook, while the agent carries on with other work. This is often a better answer to “too slow” than a shallower mode.
• Streamed progress. Some services stream intermediate steps. That helps a user interface feel responsive but does not make the final report arrive sooner.
• Splitting the question. Several smaller research calls on sub-questions can finish sooner than one large call, provided your agent can merge the results sensibly.

Measure speed the way your agent experiences it: time from request to a usable result, including retries and failures, on your own questions and from your own infrastructure. Times quoted by a vendor come from someone else's workload. If what you need is quick retrieval rather than research, see search for latency-sensitive applications.

Report structure you can use

A report can read well and still be awkward to use. Decide what your application does with the output, then check whether the service can deliver it:

• Structured output. Can you request a schema, such as named sections, fields or a table, instead of free prose, so downstream code can consume it?
• Claim-level citations. Each claim should point to its own source, not to a reference list at the end.
• Findings kept apart from gaps. A good report says what it could not establish. A report that fills every section with confident text is hiding something.
• Source list with metadata. URLs, titles and dates for every source consulted, ideally including sources read but not cited.
• A visible trail. Can you see the plan or the steps the service took? When a result is questioned months later, that trail is what you will need.

Citation quality is the real test

Deep research reports are long and assured, which makes weak citations easy to miss. Look for three failure patterns:

• The cited page exists but does not say what the claim says.
• The citation points to a secondary source summarising a primary one that you would rather cite directly.
• The citation is invented or malformed: a plausible URL that does not resolve, or a footnote with no matching source.

A citation points to evidence; it does not prove anything by itself. Your evaluation should open sources and check support, at least for a sample of claims in every report. Citations that hold up describes what that check involves.

Where GoCux fits

GoCux is not a deep research API and does not read the open web, so it is not a candidate in this comparison. Its research runs from a plan made of a question, ordered steps and a source allowlist. Creating the plan only records a draft; someone approves it before it runs, and the run cannot reach past what was approved. An empty allowlist permits no source at all, and when the question changes, the right response is a revised plan rather than a quietly widened run, as a changed question needs a new plan explains.

Findings supported by a quotation are kept separate from questions for which no source turned up, and a generated URL or tidy footnote never counts as evidence. Work orders also carry bounds on wall time and tool calls, which makes the depth-versus-speed decision from this guide explicit and recorded instead of buried in a setting.

Run your own evaluation

1. Collect 15 to 30 real questions across your use cases, including a few where the honest answer is that evidence is thin or missing.
2. For each, note what a good answer must contain and which sources a careful analyst would expect to see cited.
3. Run every candidate at the settings you would use in production, and keep the raw outputs.
4. Grade blind on correctness of key claims, coverage of the expected points, citation support checked against a sample of sources, honesty about gaps, and how usable the structure is.
5. Record time to a usable result and cost per question from your own runs.
6. Repeat a subset later; research results drift as the web and the services change.

Set the weights before you look at results. The service that writes the most impressive prose is not necessarily the one whose claims survive checking. Evaluate the work, not just the answer applies the same principle to agent work in general, and for enterprise concerns such as data handling and access control, see deep research tools for enterprise use.

Checklist before you commit

• The depth setting was chosen by the cost of being wrong, not left at the default.
• Speed was measured as time to a usable result on your questions, from your infrastructure.
• Long jobs run asynchronously so they do not block your agent.
• The output structure fits what your code and your reviewers need.
• Citations are claim-level, and you checked a sample against the sources.
• Reports say what they could not find.
• You can restrict sources when a question calls for it.
• Spend per run has a ceiling, and cost was priced on your real mix of questions.
• The terms cover storage of reports and what happens to the questions you send.