I have wired enough RAG and agent pipelines to know that web search is the most annoying dependency in the stack. You either pay a specialist vendor per call, scrape pages yourself and babysit the parsers, or hand a search tool to the model and hope the provider does not move the goalposts. DeepSeek just made that decision cheaper, and it made it official by turning search into a metered line item that sits next to your token bill.
The announcement landed on October 17 alongside DeepSeek-V4.1-Flash-1017, and the Hacker News thread titled it plainly: DeepSeek search and fetch, $0.75 per 1000 successful requests. That number is the part everyone quoted. It is also the least interesting part of the release.
📰 What DeepSeek Actually Shipped
Two endpoints, both raw JSON, both using the same bearer authentication as the chat API. There is no second key to provision:
- Search:
POST https://api.deepseek.com/v1/tools/search - Fetch:
POST https://api.deepseek.com/v1/tools/fetch
Search takes a query of 1 to 128 Unicode characters, returns 10 results by default, and accepts a count between 1 and 50. The query syntax is forwarded intact, so the usual operators work: site:, -site:, exact phrases in quotes, term exclusion, lang:zh,en, and the date filters after: and before:. Each result carries a title, URL, a short snippet of roughly 100 to 200 characters meant for display, a longer summary of roughly 600 to 800 characters meant for a model to read, an optional full content field when you set need_content to true, a rerank_score from 0 to 3, an authority tier from 0 to 4, and a publication date.
Fetch takes a URL and returns the page title plus the content as Markdown, which is the shape language models handle best.
Then the billing rules, which are the real design decision here. Search and Fetch are billed per successful request, not per token and not per returned result, at $0.75 per 1,000 requests on each endpoint. A request only counts if it returns HTTP 200 with a non-empty results array for search, or actual page content for fetch. Failed requests, empty result sets, and timeouts are free. Asking for 50 results costs exactly the same as asking for one.
💸 The Price Is Real, the Comparison Is Not
$0.75 per 1,000 calls works out to $0.00075 per lookup. Startup Fortune published a launch-day comparison against the specialist search APIs: about $5 per 1,000 for Brave, $4 to $7 for Exa, $1 to $5 for Perplexity, and $8 to $16 for Tavily. Taken at face value, DeepSeek is five to twenty times cheaper.
Take those loosely. The comparison comes from a single outlet’s snapshot, the products are not equivalent, and index quality, freshness, and crawl policy are the things you actually pay for. DeepSeek has also revised its own API pricing repeatedly this year, including an August peak and off-peak restructure followed by a large cut to Flash pricing weeks later.
The bigger gap is that nobody has published an independent evaluation of the index. authority and rerank_score are DeepSeek’s own signals, and there is no third-party data yet on how often a search returns the page you wanted versus a plausible near miss. Cheap retrieval that hands your model the wrong source is not cheap, it is expensive in a way that shows up weeks later in a bad answer.
The pricing shape does get one thing right: your cost scales with the number of lookups your agent makes, a number you control, instead of with the size of the pages it swallows. That cuts the other way too. A hundred narrow calls cost the same as one call that returns everything, so the firehose pattern is the expensive one, not the broad query.
🚧 The 5 QPS Ceiling Is the Real Constraint
Here is the number that will actually reshape your architecture. Both endpoints are capped at 5 requests per second, and the limits are calculated at the account level regardless of how many API keys you mint. Search and Fetch have separate quotas, so traffic to one does not eat the other’s budget, and the QPS limits are separate again from your model concurrency limits. Fetch adds a second, undisclosed constraint: a per-domain QPS limit DeepSeek does not publish. Exceed either one and you get HTTP 429.
Sit with the arithmetic. Five requests per second is 300 search requests per minute for an entire account. Agent frameworks love to fan out. A planner that issues twenty searches to cross-check a claim, three parallel research subagents, an ingestion job walking a few thousand documentation URLs. Any of those designs can saturate a 5 QPS account in the first burst, and 10,000 fetched pages is a thirty minute floor before you account for a single retry.
The docs say to wait and retry on 408, 429, and 5xx. They do not say which limit you tripped, whether a Retry-After header comes back, or how tight the per-domain cap is. So your client has to carry a token bucket, its own backoff, and enough logging to work out later which ceiling you hit.
One detail that is easy to miss: an empty result set is not billed, but it still consumes a quota slot. Sloppy query construction costs you capacity while costing you nothing on the invoice, which makes a 429 harder to explain when you are only watching spend.
🌏 The Free Window, and the Data Question
Search requests made through Claude Code’s built-in Web Search tool or Codex’s web_search feature do not incur Search API request fees for the first two weeks after launch, and the docs say billing starts on a date to be announced separately. Outlets covering the pricing change give that date as 16:00 UTC on October 31, 2026, which DeepSeek’s documentation converts to 00:00 Beijing time on November 1. Note the difference in what each source commits to: the guide states the two-week window and defers the date, while November 1 comes from coverage rather than the page itself. The math is consistent either way, since two weeks from the mid-October launch lands on the same weekend.
Be precise about the free part, because it is widely misread. It is free for developers who point those tools at the DeepSeek API. It is not free web search for Claude Code or Codex users in general. The docs name Claude Code and Codex; Startup Fortune also lists DeepSeek Harness in the same sentence.
Then the trade-off that decides whether any of this is usable for you. Your queries and the URLs you fetch go to DeepSeek’s hosted service. According to Startup Fortune’s reading of the terms, DeepSeek’s privacy policy says it collects, processes and stores personal data in the People’s Republic of China, its platform terms are governed by Chinese law, and the API terms do not clearly state whether API inputs are used for training. Regulators in Italy and Germany have already taken action against DeepSeek over data transfers to China. DeepSeek’s own search guide says nothing about retention or region. If your queries carry customer data, internal URLs, or anything under an NDA, this is a hard no until someone signs off on it in writing.
🛠️ What I Would Check Before the Meter Starts
A few things worth doing while the meter still reads zero.
Measure your real lookup rate per task instead of inferring it from token counts. If a typical research task fires thirty searches, you are at about two cents per task, which is fine. If it fires two thousand, you have a design problem that was previously hidden behind someone else’s flat fee.
Stress the 429 path on purpose. A client pool of six workers against a 5 QPS account cap is a guaranteed rate limit under load, and an agent that reads a 429 as “the source does not exist” will invent citations.
Cache aggressively. Identical queries do not change minute to minute, so a short TTL on hot queries buys real headroom and relieves the per-domain Fetch cap at the same time.
Keep 403 and 404 distinct in your wrapper. A 403 means DeepSeek’s security policy rejected the fetch, and a 404 covers everything from an unavailable URL to a site policy block to a page with no extractable Markdown. Neither means the page is gone, and an agent that reads them that way will quietly drop good sources.
Pin the price as an assumption, not a fact, in your cost model. One pricing change every eleven days is not a stable foundation for a three year plan.
🧠 Final Thoughts
The headline is that web search got boringly cheap, and that is genuinely good news for anyone building agents or RAG systems, because cost should never be the reason you skimp on retrieval. The real constraints are the ones nobody quotes: 5 requests per second per account, a per-domain Fetch cap that is not documented, and data terms that put your queries in China unless you check otherwise.
The pricing shape is right, because per-request billing lines the invoice up with the thing you control. That also means search is now a line item you have to budget, monitor, rate limit, and cache, exactly the way you already treat tokens.
So do the useful thing while the meter is free. Take one eval set from your own pipeline, run the same queries through DeepSeek Search, and look at whether the top results are the pages you would have cited. If they are, you have a cheap retrieval tier and a capacity problem you can plan for. If they are not, the price was never the point.
Thanks for reading.