DeepSeek to Start Charging for Search and Fetch API Calls on 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, a plain-text format that keeps headings and links readable. 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. One call discovers candidates, like a catalog lookup. Another call materializes content, like pulling the book from the shelf.

Both endpoints use the same bearer authentication as the DeepSeek API, the API key sent with each request. 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, 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, the standard success code, and produces a result. Failed calls, transport errors, and empty results are not billable. 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. Retrieval-augmented pipelines are AI systems that pull web facts into answers. Agent loops are AI programs that make repeated tool calls to finish a task. 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, or broad searching versus careful reading. Search calls stay cheap when tuning queries, reranking, or filtering domains client-side. Reranking means reordering results by relevance. 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. Chunking is splitting text for AI processing. 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.