Your research agent checks ten competitors every morning. It searches the web, opens several pages, and asks a model to summarize what changed. A token-only budget misses part of the bill: DeepSeek now documents Search and Fetch as billable calls. Its documentation says server-side calls made through DeepSeek Harness, Claude Code, or Codex began per-request billing at midnight Beijing time on November 1, 2026. The useful question for a founder is how often each task actually searches and fetches.
The billable event is a successful call with a result
Search returns web results for a query; Fetch retrieves a single page as Markdown. On the official pricing page, checked November 3, 2026, each API costs USD 0.75 per 1,000 successful requests, or USD 0.00075 per successful call. The price is per call, not per returned result or token. Asking one Search call for ten results does not make it ten Search charges. Model tokens are a separate line item, with rates depending on the model, caching, and time of day.
DeepSeek says a request is billable only when it returns HTTP 200 and produces a result: Search needs a nonempty results array, and Fetch needs page content. Empty searches, failed requests, and timeouts do not incur this Search/Fetch request charge. A sloppy retry loop can still add successful calls later, so logging matters even when many attempts fail.

Estimate a real workflow, not a headline price
Imagine 100 successful searches and 200 successful fetches per day for 30 days. That is 3,000 Search calls and 6,000 Fetch calls: 9,000 successful requests in total. At USD 0.75 per thousand, the tool portion is USD 6.75 per month. The arithmetic is (3000 + 6000) / 1000 × 0.75 = 6.75. Add five more fetched pages per topic and the number changes. This estimate excludes model tokens, storage, other APIs, and applicable tax.
For your own app, log search_ok, fetch_ok, model_input_tokens, and model_output_tokens per task. Count only successful Search/Fetch requests with a result for this tool-cost formula, then reconcile against the provider's usage and invoice. Multiply the observed calls per task by daily task volume. If an integration invokes Search/Fetch internally but does not expose a call count, run a deliberately small workload and inspect usage before setting a public per-customer price.
Three design decisions to make this week
- Set a task budget. Start with a maximum number of searches and fetched pages per research job, then adjust based on the evidence a useful answer requires. There is no universal correct cap.
- Reuse retrieved pages with timestamps. Save the URL and retrieval time when a topic repeats. Refresh it when freshness matters; a cached page from last week is not proof of today's product announcement.
- Report tools and tokens separately. The per-request web charge is only one component. Long retrieved pages can also increase the text your model processes, so track both.
The tariff is published in DeepSeek's own documentation, and I checked the example arithmetic. I did not make paid calls against a DeepSeek account or measure hidden calls from a live agent. USD 6.75 is a scenario, not a prediction of your invoice. Recheck the pricing page before deploying a production budget; DeepSeek says prices may change.
