DeepSeek Search API Pricing Breakdown: The Hidden Costs Behind Per-Successful-Request Billing

DeepSeek^Ad has launched search and web scraping capabilities in its API, quickly hitting the Hacker News front page with a price of $0.75 per 1,000 successful requests. But there are plenty of details worth scrutinizing in that "successful request" billing unit — the original author dissected the pricing page line by line like reading a contract, and probed the boundaries of error handling without an API key.

What the Billing Rules Actually Mean

Both endpoints live under the standard DeepSeek base URL: /v1/tools/search and /v1/tools/fetch. The official documentation states that only requests returning HTTP 200 with results are billed: search returning an empty results array isn't billed, fetching with no content isn't billed, and failures and timeouts likewise aren't billed. The count parameter doesn't affect price.

Combined, these three rules produce three corollaries that aren't written in the headline.

Per-Result Cost Can Vary by 50x

A single request costs a flat $0.00075, whether it returns 1 result or 50. At count=50, each result costs $0.000015, i.e., 1.5 cents per thousand; at count=1, the same inventory is 50 times more expensive. This means the default value of 10 isn't the cost-optimal choice — how you set it depends on how many results your agent actually needs.

Empty Results Are Free, So Existence Checks Cost Nothing

Queries like "does information about X exist" only incur a charge when the answer exists. This characteristic is quite friendly for building exploratory agents — probing searches won't burn money just because you search a lot.

Exploratory agent refers to intelligent agents that frequently issue tentative queries during task execution, operating primarily in a "query first, then decide" mode — for example, first confirming whether a certain entity or fact exists, then deciding whether to scrape deeper or call other tools. A significant proportion of such an agent's queries may return empty results. If empty results were also billed, probing behavior would become a continuous money-draining burden. By excluding "returning an empty results array" from billing, DeepSeek effectively reduces the marginal cost of existence checks to zero, allowing agents to probe more aggressively for coverage. Note, however, that the free tier only applies to the search endpoint returning an empty array; if the agent subsequently fetches hit results or injects summaries into context, scraping fees or model token fees still apply — so "free probing" doesn't mean "zero-cost probing."

The Real Bill Is in the Context

This is the most easily overlooked point. 50 results, each with a summary of 600–800 characters, totals 30,000–40,000 characters, not counting snippets. DeepSeek charges you $0.00075 to complete the search, but your model's token cost for reading that content is separate. The search fee is a rounding error; the reading fee is the bulk.

The documentation also specifies rate limits: 5 QPS each for search and fetch, calculated independently. Running at full speed for a day allows at most 432,000 successful requests, capping daily spend at $324 per endpoint and $648 for both. This number itself is the spending ceiling for a runaway loop — rare controllability for an agent tool. Additionally, calls made through DeepSeek Harness, Claude Code, or Codex as server-side tools are currently free, with per-request billing starting November 1, 2026 (Beijing time) — there's a window where the billing meter is installed but not yet activated.

QPS (Queries Per Second) is a common metric for how many requests per second an API endpoint can accept, typically enforced server-side per account or per key within a time window. In this article, "5 QPS each for search and fetch, calculated independently" means the two endpoints' quotas don't affect each other, and rate limiting is generally implemented with a sliding window or token bucket: short bursts may be allowed, but sustained full-load requests will trigger 429 responses. For agents, QPS combined with per-request price allows estimating a hard spending ceiling: 5 × 86400 × 0.00075 ≈ $324/day/endpoint, or $648 for both. This ceiling doesn't account for retries and concurrency jitter, nor does it include the token cost of the model reading search results, so it's only a hard cap on search fees, not an upper bound on overall agent operating costs.

Keyless Probing: Authentication Before Everything

The original author doesn't have a DeepSeek key, but that's exactly enough to test the error surface. The documentation says invalid requests return 400 and invalid keys return 401, but doesn't specify the order. So the author constructed "double-error" requests — bad key plus bad body — to see which error triggers first.

Eight tests, eight 401s:

search, no key                          -> 401  1.11s
search, fake key                        -> 401  0.82s
search, fake key + count=999            -> 401  0.78s
search, fake key + empty query          -> 401  0.57s
fetch,  fake key                        -> 401  0.63s
fetch,  fake key + url="not-a-url"      -> 401  0.53s
search, fake key + malformed JSON body  -> 401  0.53s
fetch,  no key                          -> 401  0.55s

count=999 (documented range 1–50), empty query, a non-URL URL, and even a non-JSON body all return the same 401. The middleware puts authentication first, and that order itself is correct — the shape of validation errors is information, and there's no need to leak it to strangers. But the cost is that the 400 examples in the docs are simply unreachable until you provide a valid key. The documentation describes the API from a paying user's perspective; everyone else sees an API with only one repeating error.

Contradictory Fields in the Error Response

That 401 response body has a notable flaw: the type field is authentication_error, but the code field is invalid_request_error. Two fields, one error, contradictory labels. If your client branches on code, an authentication failure gets classified as a request error. The documentation does warn that param is always null, and indeed it was null in all eight responses — that part of the contract is fulfilled accurately.

One more detail: the error message echoes a masked fragment of the submitted key (e.g., ****-000, the last three digits of the fake key). Harmless for a fake key, but if a logging pipeline captures error messages containing real keys, the mask only preserves the tail — and the tail is precisely what people use to distinguish keys.

The semantic difference between 401 and 400 is clearly delineated in the HTTP spec: 401 Unauthorized means the request lacks valid credentials and the client should re-authenticate; 400 Bad Request means the request itself has a format or parameter error, unrelated to identity. When a server places authentication middleware before parameter validation, any request failing authentication — even if the body isn't valid JSON, count is out of range, or url isn't a URL — gets a 401 first, without exposing the specific parameter validation rules. This design is reasonable from a security standpoint because it avoids leaking internal validation logic and error shapes to unauthenticated parties; the cost is that the 400 examples described in public documentation can only be reproduced by paying users holding valid keys. For client developers, this means you can't rely on 400 to debug request formats in a keyless state — you must first resolve authentication to see parameter-level feedback.

Integration Advice

The pricing model itself is reasonable: you only pay for 200s that return results, failures and empty results are free, price is decoupled from count, and rate limits double as a spending ceiling. Before integrating with an agent, what needs modeling isn't $0.75 but the 30,000–40,000-character summary a fully configured call injects into context, plus the window where calls through the harness are completely free until November 1. When integrating, match error handling on type rather than code — the original author verified that code lies.

One-line Summary

DeepSeek Search API bills per successful request; the search fee is a rounding error, while the context reading cost is the bulk.