DeepSeek Search API: how it works, what it costs, and the catches

Why I care about a search API

I build eesel's integrations, the code that pulls help-center articles, macros and tickets into the AI. Most of that job comes down to retrieval, which means finding the right piece of text and then showing where it came from. One hardware support team on an eesel sales call put citations on every answer at the top of their list, and in the same breath asked eesel to crawl a help center that sits behind a login.

That pairing is pretty much the lens I read this launch through. A cheap web search API solves the first half of that problem for public information. For the second half, it does nothing at all. So I went through DeepSeek's docs and billing rules and compared the price against eight other vendors, then also read what developers said in the first two days. I don't have hands-on benchmark numbers of my own, so where I cite speed or quality, it comes from people who measured it.

What is the DeepSeek Search API?

The Search API finds web pages for a query and returns structured results. Its partner, the Fetch API, takes one URL and returns that page as Markdown. DeepSeek's Search & Fetch guide describes both as raw JSON APIs that use the same bearer key as the rest of the DeepSeek API.

It shipped the same day as DeepSeek V4.1 Flash 1017, the model update I reviewed separately. The changelog entry says the engine behind DeepSeek's web and API search already handles "hundreds of millions of search requests" a day, indexes "hundreds of billions of web pages," and filters SEO spam and low-quality AI-generated content. Put simply, it's the same search DeepSeek's chatbot was already using, only now it is sold by the request.

How Search and Fetch work together

The two endpoints map onto the loop most research agents already run: search, pick the promising links, read them, answer. The model itself never touches the web at any point. Your code (or a harness like Claude Code) makes the calls and drops the results into the model's context.

A Search request takes five fields, per the Search API reference:

The query supports the operators you would type into a search box: site: and -site:, exact phrases in quotes, lang:zh,en, and after: / before: dates. That 128-character cap is tight, especially for agents that like pasting the whole question in. ori_question is the workaround: keep the query short and pass the full question separately.

Each result also carries two fields, and I haven't seen them packaged quite this way in other APIs. rerank_score runs from 0 to 3, and DeepSeek says 1.5 or above counts as high quality. authority runs from 0 to 4, with 3 and up meaning a highly authoritative source. There is also a summary of 600 to 800 characters that DeepSeek says is "intended to be read by a model." For a RAG pipeline, that means you can drop junk pages and feed summaries to the model before you pay to fetch anything. One caveat from an early builder: across 60 results, they found rerank_score ranged from 0.03 to 2.32 and "barely changes between different queries," which reads more like a page-quality score than a relevance score. My own use for it would be dropping low-quality pages, not ranking answers.

The Fetch API is simpler: send a URL (up to 8,192 characters), get back title and content. If the page can't be read, because the site blocks it or there is nothing to extract, you get a 404. A 403 means DeepSeek's own security policy rejected the request. It's worth handling both in code, rather than letting your agent keep retrying forever.

What does the DeepSeek Search API cost?

Search and Fetch bill per successful request, not by tokens and not by the number of results. Here is the whole price list from DeepSeek's pricing page:

The billing rule is on the generous side. A request counts only when it returns HTTP 200 and actually produces something: a non-empty results array for Search, page content for Fetch. Empty results, failed requests and timeouts are free, and asking for 50 results costs the same as asking for one.

The other half of the bill comes from the model reading whatever you pulled in. Those tokens bill at normal Flash pricing or V4 Pro rates. Off-peak prices are half of peak, and peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays:

One date is worth putting in your calendar. When you use the DeepSeek API through DeepSeek Harness, Claude Code or Codex, the agent's server-side searches already go through these endpoints. The guide says those calls are free for now and that per-request billing starts at 00:00 Beijing time on November 1, 2026 (16:00 UTC on October 31). If you have been leaving web search on in Claude Code because it costs nothing, that changes in under two weeks.

How it compares with other search APIs

I pulled each vendor's own pricing page on October 19, 2026. The units are not the same across vendors, so check the second column before you compare any numbers.

Tavily and Firecrawl figures are my arithmetic from their credit rates, assuming basic depth and 10 results.

Three things stood out to me. First, DeepSeek undercuts every list price here, and the closest rivals at $1 to $1.20 are a fast tier or a $599-a-month plan. Second, the "plus tokens" rows matter: OpenAI and Anthropic charge $10 per thousand searches and then bill the results as input tokens on top, on models like GPT-5.6 and Claude (see Anthropic API pricing) that cost far more per token than DeepSeek Flash. Third, DeepSeek's rate limit is the lowest in the table, and by a wide margin.

If you want to switch providers without rewriting code, Cloudflare's Web Search API puts three of them behind one endpoint. For deep multi-step research rather than single queries, Exa Agent Ultra is a different product at a different price.

If you mostly need page-to-Markdown at scale, Firecrawl's pricing is the one to compare Fetch against.

The 5 QPS limit is the number to plan around

Search and Fetch each allow 5 requests per second per account. Since the limit is account-wide, adding more API keys won't raise it. It is also separate from DeepSeek's model concurrency limits, and Fetch adds a per-domain cap on top. Anything over the line gets HTTP 429.

Five per second sounds tiny, but do the math: it is 432,000 searches a day per endpoint, which is more volume than almost anyone needs. Where it actually bites is bursts. A research agent that fans out 20 parallel searches, or 10 users hitting your app in the same second, will trip the limit even if your monthly volume is small. Brave and Perplexity allow 50 per second, so this is where DeepSeek's low price shows its tradeoff.

The fix is boring and works, and it's the same pattern any AI agent API integration needs: put a queue in front of the API with a token-bucket limiter, retry 429s with backoff, and fan out fetches across domains rather than hammering one site. DeepSeek's error guide says to retry on 408, 429 and 5xx, top up your balance on 402, and leave other 4xx errors alone until you change the request.

What does one agent task really cost?

Let me walk through a worked example. Say a research agent runs 2,000 tasks a month, and each task makes 4 searches and fetches 3 pages. That is 8,000 searches and 6,000 fetches, or $10.50 a month in DeepSeek fees. The same 8,000 searches would cost $40 on Brave, $64 on Tavily pay-as-you-go, and $80 on OpenAI before its token charges.

Now for the part people tend to skip. Those 6,000 fetched pages go into the model. If a page averages 6,000 tokens (my assumption, real pages vary a lot), that is 36 million input tokens: $5.40 on Flash off-peak, $10.80 on Flash at peak, or $23.76 on V4 Pro off-peak. On V4 Pro, the pages you read cost more than the searches that found them.

On small jobs, it flips the other way. A Reddit user who logged a week of agent work found one research subagent made 85 searches against just $0.07 of model work. At $0.75 per thousand, those searches cost about $0.06, nearly as much as the model itself. So on cheap Flash calls, the search fee can end up matching the model bill. Plug in your own numbers below.

The estimator leaves out output tokens and the search summaries, so treat it as a floor. Two levers move the bill more than anything else. The first is need_content: true, which returns page text inside the search results so you can skip separate fetches. The builder of a Perplexity-style answer engine said it took one question "from 31s to 7s," with 15 results and about 119,000 characters in one billable call. That trades fetch fees for tokens, since 119,000 characters is roughly 30,000 tokens for the model to read. The second lever is timing: run batch jobs off-peak, where every DeepSeek token costs half. And if Flash isn't smart enough to pick good sources, compare it against Kimi K3 or step up using my Flash vs Pro notes before you pay for more fetches.

Using it from Claude Code, Codex and Harness

Most people will run into this API without ever calling it directly. DeepSeek's Claude Code guide says the API "natively supports the Web Search feature in Claude Code." When the model decides a question needs the web, Claude Code calls the Web Search tool and DeepSeek runs the search on its side.

The same page spells out the cost: summarizing search results takes extra model requests, so "additional model token costs will be incurred," and the searches themselves bill at Search API rates. That lines up with what I said earlier. On Claude Code, the search fee is the small line on the invoice. If you're tuning spend, my Claude Code pricing guide covers the rest, and the environment variables post shows how to point Claude Code at another API.

The model gating is an easy thing to miss. In the Responses API, the built-in web_search tool is "Supported with deepseek-v4-pro" and "Ignored with deepseek-flash." The Codex integration is the same (my Codex pricing post covers OpenAI's own plans): web search only works when Codex runs on deepseek-v4-pro, and DeepSeek's setup script writes web_search = "disabled" until you change it to "live". So if you moved Codex to Flash to save money and search quietly stopped working, that is why. The standalone endpoints don't care which model you use, since your code makes the calls.

DeepSeek Harness, DeepSeek's own agent app, is the third route in the free window (see Harness alternatives if it isn't your tool). Its trajectory view shows every tool call in a session, which is the easiest way I know to see how many searches an agent really makes before you start paying for them.

What developers are saying

The first reaction was about price, and it was loud. The Hacker News thread on the launch ran the comparison people care about:

"For comparison that's $5 with Brave Search API and $12 with Kagi API"

thombles, Hacker News

Developers who had already built their own search tools, often as an MCP server, were impressed too:

"About a year ago I built my own search and fetch MCP tools for agents based on third-party scraping providers. It is about 15-20x more cost-effective than what OpenAI and Anthropic is offering with their integrated web search and fetch tools. Very impressive that DeepSeek has such a competitive offering today."

suncemoje, Hacker News

The most detailed data point came from a Reddit user who ran 353 queries and 196 fetches through both the new API and DeepSeek's older search path, which billed by tokens. Their numbers: cost fell from $0.64 to $0.41, and search latency from 4.3 seconds to under 0.9 seconds. (The post says DeepSeek's own model wrote it up from the user's logs, and it didn't compare against Tavily, Exa or Brave.) Their take on what matters, beyond the snippets and dates they now get instead of bare URLs:

"The 2.4× is nice. The real win is that the price is now predictable"

u/Kraionix, Reddit

On quality, the reviews are more mixed. A developer who runs their own fetch benchmark wasn't impressed:

"Ran a few quick tests on my web-fetch bench. As much as I like DeepSeek, its search and fetch aren't very good (is quite cheap tho). You'd probably be better off using free services like Jina directly, or if you're going paid, Parallel, Firecrawl, Tavily and Exa are all pretty good now."

ggnore7452, Hacker News

Another probed what sits behind the API:

"as expected, the typical "politically sensitive" search queries return 0 results"

czk, Hacker News

The same comment says fetch traffic exits through Huawei Cloud in Hong Kong. Neither of the testers gave hard numbers, so I'd treat them as reasons to test rather than verdicts. The open question is the one the widget above tries to answer:

"At $0.75 per 1000 requests, I want to know how many calls an agent makes in the background. Has anyone calculated the cost for typical research task?"

u/Glum-Guitar-5083, Reddit

And for teams who just want to get going, the boring advantage got a mention:

"I have been looking for Search API that will scale and no one is close to Deepseek's API search pricing. Deepseek also makes it easy to pay - just a credit card and you don't need to jump through any hoops to add money."

u/Viktri1, Reddit

Where it falls short

The price is real, and so are the limits. Before you swap your search provider, check these:

• Rate limit. 5 requests per second per account is a tenth of what Brave and Perplexity allow. Fine for one agent, tight for a busy product.
• Short queries. 128 characters per query, so long natural-language questions need to go in ori_question.
• Data location. DeepSeek's privacy policy says personal data may be stored on servers in the People's Republic of China, and lists improving its models among the uses of user input, with an opt-out right. Search queries can carry customer details, so that is a compliance check, not a footnote.
• No published retention terms for search. Brave describes zero data retention by design, and Exa and Firecrawl offer it on enterprise plans. I didn't find an equivalent statement for DeepSeek's search endpoints.
• Filtered results. One tester reported that politically sensitive queries return zero results, and that fetches go out through Huawei Cloud in Hong Kong. If your agent researches news, policy or China-related topics, expect gaps (and remember empty results are at least free).
• An index outsiders haven't tested at scale. DeepSeek says its engine handles hundreds of millions of searches a day. How well it ranks English-language niche results against Google-backed or Brave-backed APIs is something to test on your own queries, not take on faith.

None of these is a dealbreaker for a side project or an internal research tool. For anything customer-facing, though, they add up quickly.

Is it useful for customer support?

This is the part where I'd slow down. A cheap web search API makes it tempting to build a support bot that "just looks it up." For a small slice of questions, that works: a shipping carrier's public holiday schedule, a changelog for a third-party tool your product integrates with, a regulation that changed last week.

Most support answers aren't on the open web, though, which is why AI search engines are bad at them. They sit in your help center (often behind a login, like that hardware team's), in past tickets, in macros, and in internal docs. That's the job of an AI knowledge base, not a search engine. A web search API can't reach any of that, and pointing one at the public web invites the bot to quote a competitor's docs or a three-year-old forum post as if it were your policy. eesel learned a version of this the hard way: a confident-sounding answer is not the same as a right one, which is why every eesel rollout is simulated against historical tickets before it touches a live customer.

So for support, I'd treat web search as a narrow tool you allow for specific public sources, with site: filters, not the main knowledge layer. The main layer is your own content, with citations on every answer. If you're wiring that up yourself, my notes on MCP for customer support cover where web tools fit and where they don't.

Try eesel

The DeepSeek Search API is infrastructure: a cheap, fast way for your code to find and read public pages. You'd still have to build everything that makes an AI safe to put in front of customers. eesel is the employee, one of a roster of AI teammates. Its AI helpdesk teammate connects to Zendesk, Freshdesk, Gorgias and the rest, learns from your help center, macros and past tickets (including help centers behind a login), cites its sources, and runs against hundreds of your historical tickets before it answers anyone.

If you're the kind of builder who reads search API docs for fun, you'll probably want to drive it from a terminal. The eesel CLI does that: npx @eesel/cli init chat-bubble --site <your-site> spins up a free 7-day workspace with no account, eesel integrations connect zendesk wires in your helpdesk, eesel instructions edits the teammate's standing rules, and eesel activity shows what it did and why. Every command prints JSON, writes accept --dry-run, and eesel mcp token turns your workspace into an MCP server, so Claude Code or Codex can manage your support teammate the way they manage your repo. If you write content instead of answering tickets, the same roster includes an AI blog writer.

It's free to start with 100 credits and no card. Try eesel on last month's tickets and see what it would have answered, and where it would have cited your docs instead of the open web. Plans are on the pricing page.