DeepSeek’s $0.75 Search API Changes the Economics of AI Agents

An AI agent is only as current as the information it can reach. That makes web search less like an optional plugin and more like core infrastructure—and DeepSeek has just made that infrastructure dramatically cheaper. Its new Search and Fetch APIs cost $0.75 per 1,000 successful requests, a price low enough to change how developers design research agents, coding assistants, monitoring systems, and self-hosted automations. The important story is not simply that one vendor undercut another. It is that live web access is becoming a commodity primitive, while the harder questions—quality, provenance, privacy, reliability, and control—are moving to center stage.

The launch quickly climbed past 100 points on Hacker News, where the conversation focused on comparisons with Brave, Kagi, Exa, self-hosted SearXNG, and scraping services. Those comparisons are useful, but cost per search is only one line in a much larger bill. A production agent may issue several searches, fetch dozens of pages, rerank them, summarize them, and then pass thousands of retrieved tokens into a language model. Cheap retrieval can reduce the friction of that workflow, but it can also encourage architectures that search too often, ingest too much, and trust results too easily.

What DeepSeek Actually Launched

DeepSeek now exposes two raw JSON endpoints under its existing API. The Search API accepts a query and returns structured results, including titles, URLs, snippets, longer summaries, optional page content, publication dates, authority tiers, and a rerank score. The Fetch API takes one URL and returns the page title and extracted Markdown. Both use the same bearer authentication as DeepSeek’s model API, so teams already using the platform can add retrieval without adopting a separate provider or translating between unrelated authentication and response formats.

The Search endpoint supports up to 50 results and familiar operators such as site restrictions, exclusions, quoted phrases, language filters, and date ranges. DeepSeek says the service runs on an in-house search engine rather than merely wrapping a public search-results page. That distinction matters. A provider with its own index can control crawling cadence, ranking signals, summaries, and the structured metadata delivered to agents. It also becomes responsible for index freshness, coverage, abuse controls, publisher relationships, and the difficult task of deciding what counts as authoritative.

The price is deliberately simple: both search and fetch are billed at $0.75 per 1,000 successful requests. A search is billable only when it returns HTTP 200 with a non-empty result set; a fetch is billable only when it returns usable page content. Failed requests, empty searches, and timeouts are not charged. The result count does not change the request price. Each API has an account-level limit of five requests per second, with additional per-domain limits on fetches. That is enough for many interactive and background-agent workloads, although large research pipelines will still need queues, backoff, and concurrency controls.

There is one timing detail developers should not miss. DeepSeek’s documentation says server-side Search and Fetch calls made through DeepSeek Harness, Claude Code, or Codex are currently free, with per-request billing beginning at midnight Beijing time on November 1, 2026. Teams testing the feature during the free window should still meter usage as if it were paid. Otherwise an agent that looks inexpensive in development can produce an unpleasant surprise when billing starts.

Why $0.75 per Thousand Is More Than a Pricing Headline

At $0.00075 per successful call, retrieval becomes cheap enough that engineers may stop treating every search as a scarce event. Ten thousand searches would cost $7.50 before model tokens and other infrastructure. A modest agent handling 1,000 tasks per day and making three searches plus five fetches per task would generate roughly 240,000 retrieval calls in a 30-day month, or about $180 at list price. That is material, but it is small compared with staffing costs and often smaller than the language-model bill produced by processing all the retrieved text.

This changes the optimization target. When search itself is expensive, developers try to minimize calls. When it is cheap, the best design may use multiple queries with different wording, search within authoritative domains, fetch primary sources, and cross-check claims. The marginal retrieval cost of better evidence becomes tiny. A well-designed agent can spend more calls to improve recall and source diversity while still reducing total cost by sending less irrelevant content into an expensive model.

But low unit prices can hide multiplication effects. Deep-research systems branch. One initial question becomes five subquestions; each produces several searches; promising results produce fetches; failed fetches lead to alternatives; and validation adds another round. The correct unit of analysis is not price per 1,000 calls but cost per completed, trustworthy task. That includes retrieval, inference, storage, observability, retries, human review, and the cost of incorrect output.

• Measure searches and fetches per completed task, not only total API calls.
• Track retrieved characters and tokens, because model input may dominate the bill.
• Record fetch failures, stale pages, duplicate results, and unsupported content types.
• Score source diversity and primary-source coverage rather than rewarding raw result count.
• Set hard per-task budgets so a looping agent cannot turn cheap calls into an expensive incident.

Search Quality, Provenance, and the New Trust Boundary

Search APIs for agents are not interchangeable pipes. Ranking quality directly influences what the model believes. A conventional search page gives a human visual cues: domain names, result ordering, dates, familiar brands, and the ability to skim several alternatives. An agent receives fields in JSON and may treat a provider-generated summary as evidence. That creates a new trust boundary. Developers must distinguish material extracted from the source page, text generated by the search provider, and conclusions produced by their own model.

DeepSeek’s response schema is promising because it exposes URLs, dates, authority tiers, and rerank scores. Those fields enable policy. A security assistant, for example, can prefer vendor advisories, CVE records, package registries, and project repositories over secondary commentary. A purchasing agent can require multiple independent sources before reporting a price. A compliance workflow can reject undated results. Yet metadata is not a substitute for verification: an authority score is the provider’s judgment, and summaries can omit qualifications that appear in the original page.

Prompt injection is the other major concern. The Fetch API returns web content in Markdown, but Markdown from the open internet is untrusted input. A page can contain instructions telling an agent to ignore its task, reveal credentials, call another tool, or treat advertising copy as policy. Retrieval should never share an unchecked authority channel with system instructions. Content should be delimited, normalized, scanned, and passed to a model with explicit rules that web text is evidence—not commands.

Teams also need to decide what query data they are comfortable sending to a third party. Search terms can reveal unreleased product names, customer incidents, source-code identifiers, internal hostnames, legal matters, or security investigations. Convenient integration with a model provider may reduce operational complexity, but it can also concentrate prompts, queries, and browsing targets with one vendor. Before production use, organizations should review retention terms, processing locations, access controls, logging, and whether sensitive queries can be redacted or routed through a different system.

Hosted Search Versus Self-Hosted Retrieval

For homelabbers and privacy-conscious teams, the obvious comparison is SearXNG or another self-hosted metasearch layer. Self-hosting can keep orchestration and logs under your control, avoid a per-call fee, and let you tune engines and filters. It is also attractive for experiments where occasional breakage is acceptable. But free software is not free infrastructure. Public search engines may rate-limit or block automated traffic, result formats change, and reliable page extraction requires handling JavaScript, bot defenses, malformed HTML, PDFs, and content negotiation.

A hosted API sells operational consistency as much as search results. Stable schemas, predictable authentication, documented error codes, request accounting, and managed crawling can save engineering time. For a company, that may be worth far more than the request fee. The Hacker News discussion captured this split: some users pointed to free self-hosted kits, while others emphasized latency, processing guarantees, and scrape reliability for research jobs that may perform ten searches and a hundred fetches.

The strongest architecture may be hybrid. Route ordinary public queries to the inexpensive hosted service. Keep sensitive searches on an internal or self-hosted path. Cache fetched documents by canonical URL and content hash. Use direct connectors for high-value systems such as GitHub, internal documentation, ticketing, or package registries. Fall back to another search provider when coverage is poor. This avoids turning any one index, ranking system, or jurisdiction into a single point of epistemic failure.

1. Classify the query before retrieval: public, confidential, regulated, or internal-only.
2. Choose a provider or local index based on that classification and required freshness.
3. Search broadly, then fetch only the most promising and authoritative pages.
4. Sanitize and label retrieved text before it enters the model context.
5. Require citations and verify important claims against the fetched primary source.

Practical Implications for Developers and IT Leaders

Developers should resist wiring the endpoint directly into an autonomous loop and calling the integration finished. Put a retrieval service between the agent and the provider. That service should own query validation, allowlists and denylists, caching, timeouts, retries, budgets, content-size limits, audit logs, and provider failover. It should return a normalized document format so the rest of the application is not coupled to DeepSeek-specific fields. This small abstraction is inexpensive now and valuable later if price, policy, quality, or availability changes.

Observability should answer more than whether the API returned 200. Log which query produced which sources, whether content was fetched or summarized, how old the documents were, which citations appeared in the final response, and how much retrieved text was discarded. Sample completed tasks for factual accuracy. Build evaluation sets from real user questions, including queries where fresh information matters and queries where malicious or low-quality pages rank well. A search provider should be selected with evidence from your workload, not a leaderboard or list price.

IT and security leaders should treat agentic web access as controlled egress. Apply the same principles used for browsers, proxies, and data-loss prevention: restrict destinations where appropriate, prevent access to link-local and private network ranges, strip credentials from URLs, block unsupported schemes, and isolate the fetcher from sensitive services. Server-side request forgery is a classic risk whenever a tool accepts a URL. DeepSeek’s documented validation helps at its boundary, but customers still need controls around what their agents are permitted to request and what they can do with the response.

Homelabbers have a different trade-off. At this price, a hosted API may be cheaper than maintaining a reliable scraping stack, especially when personal automation runs only a few thousand requests per month. Still, local caching is worthwhile, and SearXNG remains useful as a privacy-preserving option or fallback. The sensible goal is not ideological purity about cloud versus self-hosting. It is understanding which data leaves the network, how often the system fails, and whether an external dependency is acceptable for the automation’s importance.

What This Means

DeepSeek’s launch signals that web retrieval is entering the same commoditization cycle as model inference. Providers will compete on price, integrated tooling, latency, index coverage, ranking quality, and the amount of useful structure returned per call. As prices fall, more applications will gain live web access by default. Static chatbots will look increasingly limited when an inexpensive search can verify a release, read a current advisory, or find an updated manual in seconds.

The competitive advantage will therefore move upward. Simply connecting a model to search will not be special. Reliable products will differentiate themselves through query planning, source selection, citation discipline, privacy-aware routing, prompt-injection defenses, caching, and evaluations that measure whether retrieval actually improved the answer. Cheap search makes poor agent design cheaper to run, but it does not make it safe or useful.

For publishers and site operators, the launch also reinforces a difficult reality: agents are becoming a major audience for the web. That raises unresolved questions about crawler identity, robots.txt, attribution, caching, compensation, and bot-defense systems that increasingly inconvenience human visitors. An in-house index can reduce repeated hits by serving cached material, but the industry still needs clearer norms about how content is collected and reused. Developers choosing a provider should care about those practices because today’s scraping shortcut can become tomorrow’s blocked domain or legal dispute.

What to Watch Next

The first question is quality. Independent evaluations should test freshness, geographic coverage, long-tail technical queries, source diversity, duplicate handling, and resistance to search-engine manipulation. A service can be exceptionally cheap and still be expensive if agents miss critical sources or require more model calls to repair weak retrieval. The second question is whether the introductory economics last. Search indexes require crawling, storage, ranking infrastructure, abuse prevention, and ongoing operations; sustained low pricing could force competitors to respond or reveal that retrieval is being subsidized to attract model workloads.

Watch for deeper integration as well. Because Search and Fetch already sit beside DeepSeek’s model APIs and are used server-side by agent harnesses, the company can optimize models around its own result format. That may improve convenience and tool-use reliability, but it can also create lock-in. Open schemas, exportable logs, and a provider-neutral retrieval layer will remain valuable even when a vertically integrated stack performs well.

The practical takeaway is straightforward: test the service, but test the whole system. Start with a bounded pilot, meter calls, compare results against at least one alternative, cache aggressively, and evaluate answer quality with citations. Treat fetched content as hostile, separate sensitive queries, and impose hard budgets. DeepSeek has made web access cheap enough to become routine. The teams that benefit most will be the ones that remember access is not the same thing as truth.

Sources: DeepSeek Search & Fetch documentation (https://api-docs.deepseek.com/guides/search/) and the Hacker News discussion (https://news.ycombinator.com/item?id=50138531).