DeepSeek Search API for LLM Agents: What $0.75 per 1,000 Requests Buys

If your agent fires a thousand searches and only 400 come back with results, DeepSeek charges you for the 400 (DeepSeek API documentation). That is the entire pitch of the new Search and Fetch APIs: $0.75 per 1,000 successful requests, where “successful” has a precise contractual meaning, and failures, timeouts, and empty results cost nothing. Whether that beats a flat-rate search API depends on your empty-result rate, which your own logs have to supply.

What DeepSeek is actually selling

These are not model features or a search toggle on a chat completion. According to DeepSeek’s API documentation, Search and Fetch are raw JSON endpoints sitting at https://api.deepseek.com, authenticated with the same bearer token as the rest of the DeepSeek API. Search returns a results array; Fetch returns page content for a URL. You can call them directly from your own pipeline, or let an agent harness call them as tools.

Both APIs are priced identically: $0.75 per 1,000 successful requests (DeepSeek API docs). The distinction between Search and Fetch matters for architecture, not price. Search is the discovery step (find candidate pages), Fetch is the retrieval step (pull the content of one page). A typical agent loop uses both, and DeepSeek meters them as separate products with separate rate limits, which matters later.

The immediate reason this choice is in front of more teams now is distribution: Vercel’s AI Gateway changelog lists DeepSeek Search and Fetch as gateway tools at the same $0.75 per 1,000 billable requests, with no charge for failures, timeouts, or empty results. If your model traffic already flows through the gateway, the search-backend decision is now a line-item decision in the same bill. One caveat from the changelog itself: “Model tokens are billed separately.” So $0.75/1k is the tool cost, not the cost of the agent loop around it.

The billing rule that changes the math

The headline number is not the interesting part. The billing trigger is. DeepSeek’s docs state it exactly:

A request is billable only when it returns HTTP 200 and produces a result (Search must return a non-empty results array, and Fetch must return page content). Failed requests, empty search results, and timeouts are not billed.

Two things follow from that definition, and both cut in different directions.

First, the risk of empty lookups shifts from you to the vendor. With a flat per-request API, every query your agent fires costs money whether or not it returns anything useful. Agentic workloads are unusually prone to speculative, redundant, and dead-end queries: a retry loop, a reformulated query after a bad first attempt, a fetch of a URL that 404s or returns a login wall. Under per-success billing, those dead ends are free. The vendor absorbs the cost of queries that produce nothing.

Second, “successful” is a syntactic criterion, not a quality criterion. A Search call that returns a non-empty array of irrelevant, stale, or junk results still bills. The contract guarantees you something, not something good. This is the gap between the marketing-friendly reading of “pay only for success” and the operational one. Per-success pricing protects you against empty results and infrastructure failures. It does not protect you against a bad index. Nor is the structure unique to DeepSeek: the community comparison notes that ScraperAPI uses “a pay-per-successful-request model”, so the choice in this market is often per-success versus per-request pricing rather than one vendor’s novelty.

The break-even arithmetic

Here is the decision model, stated as arithmetic rather than measurement. Let s be your success rate: the fraction of requests that return HTTP 200 with a non-empty result. DeepSeek’s cost per 1,000 requests sent is $0.75 × s. A flat-rate competitor’s cost per 1,000 requests sent is simply its price.

The comparison set, with sourcing caveats attached:

The two community-maintained GitHub repos are not vendor rate cards; re-verify both price points before committing budget to this comparison. With that flagged, the arithmetic:

• Against SerpAPI’s $15/1k: DeepSeek wins at any success rate, by an order of magnitude or more. Even a 100% success rate costs $0.75.
• Against Serper’s ~$1.00/1k entry tier: DeepSeek wins at every success rate up to and including 100%. At full success it costs $0.75/1k against ~$1.00/1k, roughly 25% less, with the margin narrowing as the success rate rises. Success-only billing is strictly better when the flat price exceeds $0.75.
• Against Serper’s ~$0.30/1k volume tier: the break-even is exactly a 40% success rate ($0.75 × 0.40 = $0.30). Above 40%, flat-rate wins. Below 40%, DeepSeek wins.

So the question “is DeepSeek Search cheap?” has no fixed answer. It is cheap when your workload is failure-heavy and expensive when it is clean, relative to the cheapest flat-rate tier you qualify for. A research agent doing speculative exploration, where half the queries return nothing, is the ideal customer. A monitoring pipeline issuing the same well-formed queries against well-indexed terms every hour, with a 95% hit rate, would pay $0.71 per 1,000 sent for something Serper’s volume tier prices at $0.30.

The uncomfortable part is that DeepSeek’s documentation gives no typical empty-result rate to plug in. You have to measure s on your own query mix. That is not a hard measurement: log HTTP 200 responses with empty result arrays for a week on your current provider, and you have the number that decides this.

Watch the definition of success in your own logs. Your break-even rate should count a request as successful only when it returns results your pipeline actually uses, not merely a non-empty array. DeepSeek bills on the array; your economics should be modeled on usefulness. The two numbers can diverge, and when they do, your effective per-useful-result cost is higher than $0.75/1k.

Throughput ceilings may bind before price does

DeepSeek sets account-level QPS limits of 100 for Search and 25 for Fetch, pooled independently (DeepSeek API docs). The docs are explicit that “traffic to one does not consume the other’s quota.”

For a single-threaded agent doing a handful of lookups per task, these ceilings are irrelevant. For a fleet of agents, or a fan-out pipeline where one user query spawns parallel sub-agents that each fetch candidate pages, the Fetch ceiling of 25 requests per second is the number to check first. It is four times tighter than Search’s, and fetch-heavy loops hit it sooner. Fetch also carries a second constraint the docs do state: “In addition to the account-level limit, Fetch is also subject to a per-domain QPS limit,” and requests above either limit return HTTP 429. That per-domain cap is the one a fan-out pipeline is most likely to trip, because sub-agents working from one result page tend to fetch many URLs from the same site. The docs do not state whether the limits are raised on request or what burst behavior is tolerated, so bursty workloads should treat 100/25 as hard walls and budget client-side queuing accordingly.

Agents in harnesses bill the same way

A natural assumption would be that tool-triggered searches from an agent harness get billed differently, either bundled into model usage or metered at a different rate. DeepSeek forecloses that reading directly:

Search and Fetch calls triggered by tools when using the DeepSeek API through DeepSeek Harness, Claude Code, or Codex, including Codex Alpha Search, are also billed per successful request.

The same success-only rule applies whether your code calls the endpoint or a coding agent calls it as a tool on your behalf. Combined with the Vercel gateway path, the practical implication is that billing semantics are now stable across three integration surfaces: direct API, agent harnesses, and the gateway. Your cost model does not need a special case for agent-triggered calls, but your observability does: a harness can fire searches you never wrote, and each successful one bills.

What DeepSeek says about quality, and what that is worth

DeepSeek’s Search response includes two vendor-defined quality signals. The docs describe a rerank_score from 0 to 3 that combines signals such as relevance, authority, and freshness, with 1.5 or above considered high-quality, and an authority field from 0 to 4 (with -1 meaning unknown), where 3 or above indicates a highly authoritative source.

These are useful for routing: you can filter results below a rerank threshold before spending fetch calls and model tokens on them. But grade them for what they are. A rerank score assigned by the vendor’s own ranker is a self-assessment. It tells you what DeepSeek’s pipeline thinks of its own output, which is not the same as an independent measurement of result quality against Google-SERP rivals. Nothing in DeepSeek’s documentation reports precision, recall, coverage, or index freshness against any external baseline. The absence of that data is uncertainty, not evidence of parity or inferiority. It simply means the quality axis is ungraded, and any pilot should include a side-by-side comparison on your own queries before migration.

Freshness and latency: what rivals pledge and DeepSeek doesn’t

Two axes where competitors are on the record and DeepSeek is silent:

Freshness. Serper.live makes an explicit live-results pledge: “On every request Serper.live opens Google for the market and device you choose and returns what is on the page at that moment. Nothing is served from a cache or an archive.” (Note that serper.live and the serper.dev pricing tiers above are different properties; do not conflate the freshness pledge with the pricing.) DeepSeek’s rerank_score claims to incorporate freshness as a component, but the docs make no statement about cache behavior, crawl cadence, or index age. For time-sensitive workloads such as news monitoring or price tracking, that silence is itself a decision factor.

Latency. A benchmark cited in the community comparison measured ScraperAPI’s average SERP response time around 11 seconds against Serper’s 2 to 3 seconds. That figure is community-sourced and unverified, and it amounts to one measurement of two vendors roughly four times apart rather than a survey of the market. DeepSeek’s documentation includes no latency figure. In an agent loop, search latency compounds: an agent that chains five lookups per task turns a 3-second API into 15 seconds of wall time. Until independent measurements of DeepSeek Search surface, latency is another open question to answer in a pilot.

This comparison does not cover Tavily or Brave, both common picks for agent search backends.

When $0.75 per 1,000 buys the better deal

I would route agent lookups through DeepSeek Search under a specific, testable condition: your measured success rate sits low enough that success-only billing undercuts the flat-rate tier you would otherwise buy. Failure-heavy workloads (exploratory research agents, broad query fan-out, aggressive retry loops) are where the risk shift pays you.

I would stay on a flat-rate competitor when the opposite holds: a high hit rate on well-formed queries, volume-tier pricing already secured, a hard freshness requirement that needs a no-cache pledge on paper, or a latency budget that an unmeasured API cannot yet be trusted with.

Whichever way you lean, three things should happen before a migration, not after:

1. Measure your empty-result rate on current traffic. It is the single input the entire cost model hangs on, and it comes from your logs, not a rate card.
2. Re-verify competitor pricing against vendor rate cards. The Serper and SerpAPI figures here come from community-maintained repos, and rate cards drift. The $0.75/1k DeepSeek figure and the gateway terms come from vendor documentation, but those drift too.
3. Run a quality and latency pilot on your own query mix. DeepSeek’s rerank_score and authority fields are the vendor grading its own homework. They are fine as routing signals inside your pipeline, but they are not a substitute for comparing result quality against your incumbent on queries you care about.

The durable takeaway is not the $0.75 figure, which is a rate-card item that will change. It is the billing-semantics framework: per-success pricing reallocates the cost of failed lookups from buyer to vendor, and whether that reallocation favors you is a function of your own failure rate. Any search API that adopts success-only billing, and any agent team evaluating one, can reuse the break-even formula: vendor price × success rate, compared against the flat rate you actually qualify for. The 40% line will move as prices do. The method will not.

Frequently Asked Questions

What counts as a billable request in the DeepSeek Search API?

A request is billable only when it returns HTTP 200 and produces a result (Search must return a non-empty results array, and Fetch must return page content). Failed requests, empty search results, and timeouts are not billed.

What are the rate limits for DeepSeek Search and Fetch?

DeepSeek sets account-level QPS limits of 100 for Search and 25 for Fetch, pooled independently (DeepSeek API docs). The docs are explicit that “traffic to one does not consume the other’s quota.”

Are searches triggered by agent harnesses billed differently?

Search and Fetch calls triggered by tools when using the DeepSeek API through DeepSeek Harness, Claude Code, or Codex, including Codex Alpha Search, are also billed per successful request.