DeepSeek Puts a Price on Web Tools: Search and Fetch Billing Starts Nov. 1
DeepSeek will begin per-request billing for its Search and Fetch APIs at 00:00 Beijing time on November 1, 2026. Each endpoint will cost $0.75 per 1,000 calls. Calls remain free of charge until that cutoff. DeepSeek announcement DeepSeek pricing
The Search API finds web pages for a query and returns structured results. The Fetch API retrieves a single web page and returns its content as Markdown. The two capabilities are exposed as separate tool endpoints. DeepSeek API Docs
Search runs at POST https://api.deepseek.com/v1/tools/search. Fetch runs at POST https://api.deepseek.com/v1/tools/fetch. The split is clean. One call discovers candidates. Another call materializes content.
Both endpoints use the same bearer authentication as the DeepSeek API. No separate credential system is required. Existing key management, rotation, and proxy controls carry over directly.
Search is powered by DeepSeek's in-house search engine. That engine serves hundreds of millions of requests daily worldwide, according to the company. For API consumers, the practical point is vertical integration. Retrieval and generation come from the same provider, with tool latency and availability tied to one stack rather than a third-party search dependency.
Billing applies only when a request returns HTTP 200 and produces a result. Failed calls, transport errors, and empty results are not billable. That condition matters for retry logic. Clients can retry on non-200 responses or network timeouts without incurring a charge for the failed attempt, though they will still pay for the eventual successful call.
The broader context here is cost predictability for retrieval-augmented pipelines and agent loops. Per-call pricing decouples web access cost from token accounting. At $0.00075 per successful call, budgeting becomes a function of tool-call frequency rather than retrieved page length or model context consumption. Teams running broad crawls, verification passes, or multi-hop research agents can model spend from logs of search and fetch invocations alone.
In my view, the separation of search and fetch is the more interesting design choice for expert users. It forces explicit control over recall versus precision costs. Search calls stay cheap when tuning queries, reranking, or filtering domains client-side. Fetch costs accrue only when a document is judged worth converting to Markdown. That structure rewards selective fetching and caching, and it penalizes naive patterns that fetch every search hit.
Looking at what this means for implementation, three details deserve attention. First, Markdown normalization shifts parsing burden off the client, but it also means downstream chunking and citation logic must trust the provider's HTML-to-text conversion. Second, success-based billing simplifies accounting but requires careful client-side logging, since HTTP status and presence of a result now determine spend. Third, shared bearer auth lowers integration friction, but it also concentrates quota and abuse controls on a single key. Scope that key narrowly if search agents run in untrusted loops.
