On October 17, DeepSeek opened two new APIs to all developers: Search and Fetch. They find pages on the web with an in-house search engine and pull a page's body back as Markdown.

The interesting part is not performance. It is the billing model. Both APIs charge per request, not per token: $0.75 per 1,000 successful searches and $0.75 per 1,000 successful fetches. Searches with no results and failed requests are not billed.

Giving agents live web access has been awkward. You attach a search API, manage a crawler, parse the body, and try to estimate the cost. DeepSeek has collapsed that front end into a single price sheet.

What the two APIs do

From the official docs:

[Search API]
POST https://api.deepseek.com/v1/tools/search

- The in-house engine finds pages for a query and returns structured results
- Each result carries title, URL, summary, publish date, site, authority tier

[Fetch API]
POST https://api.deepseek.com/v1/tools/fetch

- Fetches a single page and returns its title and body as Markdown
- Subject to the target site's availability and access policies

[Both]
- Bearer auth (the same DeepSeek API key)
- Raw JSON, read-only

A Search request uses these fields.

Field Required Default Description
query Yes — 1 to 128 chars. Supports operators
count No 10 1 to 50 results. Does not affect price
ori_question No — The user's original question, to improve query understanding
localization No "" An IP address to localize results
need_content No false When true, content includes the page body

The response is a results array. Its per-item fields matter in practice.

rerank_score : 0 to 3, combining relevance, authority and freshness
               (1.5 or above counts as high quality)
title        : result title
url          : result URL
snippet      : short summary for display (typically 100-200 chars)
summary      : long summary for a model to read (typically 600-800 chars)
content      : page body (empty when need_content is false)
site_name    : site name, or null
date         : publish time in RFC 3339, or null
authority    : authority tier 0 to 4 (-1 unknown; 3+ is highly authoritative)

Two fields stand out: summary and authority. The summary is a 600-800 character digest written for a model, not a person, so token counts stay predictable when you drop results straight into a prompt. authority lets you filter sources in code — you can enforce a rule like "cite only tier 3 or above."

Query operators are supported too.

site:github.com      restrict to a site
-site:example.com    exclude a site
"exact phrase"       match an exact phrase
-"release notes"     exclude an exact phrase
lang:zh,en           restrict by language
after:2025-01-01     published after a date
before:2026-06-01    published before a date

Example combination:
"DeepSeek site:github.com OR site:huggingface.co lang:en after:2025"

Fetch is simple: give it a url and get back title and content (Markdown). The URL must be at most 8,192 characters, HTTP or HTTPS with a host, and must not contain a username or password.

The pipeline: RAG without a vector database

Wiring the two together gives you the simplest form of retrieval-augmented generation.

[user question]
     |
1. [Search API]  query + ori_question
     |
   result list (title, summary, URL, authority, rerank_score)
     |
2. if needed, [Fetch API] the top pages for their bodies
     |
3. pass to the LLM with sources attached (URL, date, authority)
     |
4. generate an answer with citations

The obvious advantage: no pre-embedding, no index to keep fresh. Every question searches the live web, which is strong for queries like "the release announced yesterday," where answers depend on index timing. For the contrast with classic RAG, see From Classic RAG to Agentic RAG.

Doing the cost math

This is the heart of the API. Get the unit right.

[Search]  $0.75 per 1,000 successful requests
[Fetch]   $0.75 per 1,000 successful requests

Billable when
- HTTP 200 and a result is produced
  - Search: the results array is non-empty
  - Fetch: page content is returned

Not billed
- failed requests
- searches with no matches (empty array)
- timeouts

count (number of results) does not affect price. Five results or fifty, one request is one request. So fetching 50 and filtering afterward can be the sensible move.

Here is the cost of handling one question.

[assume an agent makes 3 tool calls per question]

2 searches -> $0.75 x 2 / 1,000 = $0.0015
3 fetches  -> $0.75 x 3 / 1,000 = $0.00225
                                 ---------
tool subtotal                    about $0.00375

+ LLM token cost (calculated separately)

Tool cost is under a cent per question. No matter how many searches you run, the tool bill stays nearly flat; the real cost is the LLM tokens behind it. That is the point of the design. Pre-cleaning the text you feed the prompt — summarizing, extracting only the body — saves expensive tokens.

One important exception is spelled out in the docs.

When you use the DeepSeek API through DeepSeek Harness, Claude Code or Codex,
server-side tool calls already hit Search and Fetch.
Those calls are currently free of charge;
per-request billing starts at 00:00 Beijing time on November 1, 2026.

Where it bites in practice

Listing only the upside would be unbalanced. Here are the constraints you will meet.

First, rate limits. Per account, Search and Fetch are each capped at 5 QPS, calculated at the account level regardless of which key you use, and separate from model concurrency. Fetch also has a per-domain QPS limit. So a plan to grab many pages from one site quickly will hit 429.

Second, retry rules. The docs say:

408, 429, 5xx  -> wait and retry
402            -> top up your account, then retry
other 4xx       -> do not retry without changing the request
403            -> Fetch was rejected by the security policy
404            -> no usable page content could be retrieved

Third, Fetch depends on the site. A 404 can mean "no such URL," but also "blocked by site policy," "unsupported content type," or "no extractable Markdown." Assuming extraction succeeds because search did is unsafe.

Fourth, quality judgment is yours. rerank_score and authority are signals, not verdicts. An empty result set is not billed, but that just means "nothing found for this query" — so a strategy of rephrasing and retrying queries matters.

Conclusion: a mini search-pipeline protocol

The briefing's action, turned into an experiment:

[Search -> Fetch -> verify sources -> summarize, a mini protocol]

1. Set a tool budget
   [ ] at most N searches and M fetches per question
   [ ] queue so you stay under 5 QPS

2. Filter search results by rule
   [ ] rerank_score >= 1.5
   [ ] authority >= 3 (citable sources)
   [ ] publish date within the required window

3. Fetch only the pages you need
   [ ] the top 1-2 results
   [ ] on 404, skip quietly and move on

4. Force sources into the answer
   [ ] attach URL and date to each claim
   [ ] mark low-authority sources as "needs verification"

5. Record three things
   [ ] tool cost (requests x $0.00075)
   [ ] LLM token cost
   [ ] search accuracy (share of sources the answer actually used)

One line captures it.

When search and extraction bill by request,
the cost driver is not how many searches you run
but the tokens you attach to them.

Read this API as "a cheap way to source material for expensive tokens," not as "a cheap way to search." Build the pipeline, then measure both cost per request and search accuracy, and the feel for wiring the web into agents arrives fast. For the fundamentals, see What Is RAG? and Document RAG and OCR Pipelines.

Further reading

References

Go deeper with a course

Wiring search and extraction yourself is best learned by building a RAG pipeline by hand. Take retrieval, chunking, citation and evaluation as one flow, and you start to see where quality breaks.