DeepSeek Search and Fetch billing is scheduled to start for server-side tool calls through DeepSeek Harness, Claude Code and Codex on October 31, 2026, at 16:00 UTC. That is 23:00 WIB on October 31 and midnight in Beijing on November 1. At our October 31 documentation check, shortly after 17:00 WIB, that deadline was still ahead. This is a notice about an approaching billing change, not confirmation that the first charges have appeared.
The published rate is $0.75 per 1,000 successful Search requests and another $0.75 per 1,000 successful Fetch requests. For developers running web-enabled agents, the useful question is how many retrieval operations a task produces, rather than how many prompts someone types. A single answer can require several searches and several page reads.
DeepSeek announced the deadline in its October 17 release notice for DeepSeek-V4.1-Flash-1017. The model announcement is two weeks old; the fresh operational event is today’s scheduled end of the free server-side tool-call period. The current pricing page and Search & Fetch documentation agree on the cutoff.
What changes tonight, and what the notice does not say
The exemption described by DeepSeek applies to Search and Fetch calls made through server-side tools in the three named clients when using the DeepSeek API. It should not be expanded into a claim that every form of web access has been free. The standalone endpoints already have published request prices, and the wording does not establish a blanket free period for direct API consumers.
Likewise, a familiar client name does not identify the company charging for every operation. A developer can use a coding assistant with DeepSeek as its model backend. This announcement concerns that DeepSeek API route. It is not an announcement about changes to Anthropic or OpenAI subscription prices.
DeepSeek’s Models & Pricing page separates token charges from Search and Fetch charges. It also says fees are deducted from topped-up or granted balances, with granted balance used first when both are available. An application budget based only on input and output tokens therefore misses a separately priced operation.
DeepSeek Search and Fetch billing follows requests, not results
The Search & Fetch guide defines a billable request as HTTP 200 with usable output: a non-empty results array for Search, or returned page content for Fetch. Failed requests, empty searches and timeouts are not billed. Increasing the requested result count does not increase the endpoint fee for that one search.
Both services use the same price, but their calls accumulate separately. The following examples are arithmetic on the published US-dollar list price, not measured invoices. They exclude all model-token charges, taxes and any other service costs.
| Successful Search calls | Successful Fetch calls | Retrieval charge |
|---|---|---|
| 1,000 | 0 | $0.75 |
| 0 | 1,000 | $0.75 |
| 10,000 | 30,000 | $30.00 |
| 40,000 | 120,000 | $120.00 |
Consider a hypothetical documentation assistant that performs one successful search and reads three pages for each completed task. Across 10,000 such tasks, its retrieval bill would be $30.00. If it repeats the same work unnecessarily, the extra successful requests cost money even when the final answer barely changes. This example describes a workload assumption, not an observed DeepSeek usage pattern.
Search summaries and full-page retrieval serve different jobs
The Search API reference describes a structured response with titles, URLs, snippets, longer summaries and optional content. A query must contain between 1 and 128 Unicode characters. The count field accepts 1 to 50 results and defaults to 10. The need_content field defaults to false, so an integration should not assume every search already includes complete page text.
For application design, that distinction suggests a sensible sequence: use the search response to select likely sources, then retrieve the pages that matter. Fetch is a separate operation, not another name for receiving a search snippet. Its API reference takes one HTTP or HTTPS URL and returns a title and Markdown content. The URL cannot contain a username or password.
As an implementation recommendation, choose the smallest useful evidence set rather than automatically fetching every result. A routine question may be answerable from one authoritative page; a disputed claim may require several independent documents. Those are editorial and engineering decisions. The endpoint price alone cannot establish how much evidence a particular answer needs.
Returning more search results has no extra per-request charge, but passing more text to the model can still change token consumption. Developers should measure retrieval calls and model input separately before deciding that a larger result set is effectively free.
The client and provider settings determine the cost path
DeepSeek Harness provides a useful example of why a product name is not enough to forecast usage. The project’s direct Search and Fetch plugin documentation describes separate providers called deepseek-search-api and deepseek-fetch-api. Its documented switch, Use the new Web Search API, selects both providers after saving. The same document says the shipped profiles select Messages search and local HTTP fetch.
This is a configuration warning, not a reason to assume an exemption from the vendor’s billing notice. Check the installed version, selected provider and actual request route. The repository’s description of a particular provider path does not prove which path every deployed Harness session takes.
The direct Search provider’s published implementation sends need_content as false and maps the returned title, URL, snippet, summary and publication date into its shared result structure. Its behavior is narrower than the complete standalone API schema. Developers comparing documentation with a client display should allow for that mapping instead of treating every absent field as a service failure.
Claude Code and Codex need separate checks
DeepSeek’s Claude Code integration guide explicitly says web searches use DeepSeek’s search API when the model decides a question requires web information. It also warns that summarizing retrieved material creates additional model requests and token costs. For that route, counting only the search fee understates the documented work.
The Codex integration guide describes a different constraint: built-in web search is available with deepseek-v4-pro, while the setup example using deepseek-flash disables it. The page says the setup script also writes web_search as disabled. Switching a backend and enabling built-in web search are therefore separate choices in this documented integration.
For teams administering several clients, record the configuration alongside a cost sample. A usage comparison without the selected model, web-search setting and provider route can mix unlike workloads. This article reports the vendor’s integration documentation; it does not claim that we installed either client, executed a search through them or observed an invoice.
Read the current limits rather than copying an older report
There is a visible discrepancy between current documentation and an early report. TokenPost’s October 17 article listed five requests per second for each endpoint. The guide checked for this article instead lists account-level limits of 100 requests per second for Search and 25 for Fetch, independently calculated, plus a per-domain limit for Fetch. The current primary documentation is the appropriate reference for those figures.
DeepSeek’s separate Rate Limit & Isolation page defines model concurrency as connections lasting until model responses complete. That is a different measure from requests per second for retrieval. Adding API keys should not be treated as a way to create independent account capacity: the documented model limits are account-level too.
For an operator, the practical response is to keep the dimensions separate in monitoring. Record the endpoint involved when a request fails, rather than collecting every HTTP 429 under one undifferentiated model error. A search-heavy batch and a long-running generation batch can stress different limits even if they belong to the same application.
Do not confuse a successful retrieval with verified evidence
The Harness Fetch provider implementation returns the requested URL, Markdown and a statusCode of 200 after decoding a successful service response. Its source comments explain that the API supplies neither the target website’s status nor its final redirected URL. An application should not present that status as proof that its own client directly inspected the original server response.
More generally, a successful retrieval is a billing and transport outcome, not a guarantee that a page supports the answer. An agent still needs to check dates, identify the publisher and distinguish a source’s claim from independently established evidence. Search summaries can help select documents, but a summary that sounds relevant may omit the qualification that changes a recommendation.
Failure handling needs a similar distinction. DeepSeek documents HTTP 402 as insufficient balance, 403 as a Fetch security-policy rejection and 404 as inability to retrieve usable page content. Retrying those conditions blindly is poor operational practice. Its guide recommends waiting before retrying 408, 429 and server errors; other client errors require a changed request, while a balance failure needs funding before another attempt.
For a production workflow, record the failure class and stop when a retry cannot change it. These are application-design recommendations, not a claim that every listed client automatically provides those safeguards. They also should not become instructions to bypass a publisher’s access restrictions: the Fetch documentation explicitly makes retrieval subject to the target site’s availability and access policies.
Prepare a budget that can be reconciled after the cutoff
Before 23:00 WIB, inspect a representative sample of completed tasks and establish how many successful searches and page fetches each actually needs. Keep that baseline next to token usage. A task-level record is more useful than a daily aggregate when the cause of a cost increase is one agent repeatedly revisiting sources.
A useful internal record would include a task identifier, retrieval provider, requested operation, success state and number of usable results. Avoid storing sensitive queries or full retrieved pages merely to count charges. Retention requirements should follow the application’s privacy needs, not an assumption that more logging is always better.
Set task-level retrieval budgets before increasing concurrency. For repeated questions, evaluate whether previously retrieved evidence is still current enough to reuse. Reuse is an engineering option, not a DeepSeek billing feature claimed here, and it needs an expiry policy: an old price page or outdated security advisory can make a cheap answer wrong.
After the scheduled start, compare actual usage records with the estimate before making broader claims about the change’s impact. We have verified the published policy, its timing and the relevant documentation, but have not submitted paid API calls. The first production bill remains a separate verification step. Until then, the defensible forecast is successful Search calls plus successful Fetch calls, priced separately from the model work required to read them.
Sources
- DeepSeek’s October 17 release announcement and billing deadline
- DeepSeek Search & Fetch guide
- DeepSeek Models & Pricing
- Search API schema and Fetch API schema
- DeepSeek Harness direct retrieval plugin documentation
- Claude Code integration and Codex integration
- TokenPost’s October 17 coverage, used for the historical rate-limit comparison