DeepSeek Search and Fetch Puts a $0.75 Price on Live Web Access

DeepSeek has opened its Search and Fetch APIs at $0.75 per 1,000 successful requests, putting a strikingly low price on live web access for AI agents. The DeepSeek Search and Fetch release separates web retrieval from model inference, so developers can search or extract pages through two raw JSON endpoints.

That changes the economics of research agents, coding assistants, and retrieval-augmented generation, or RAG, which gives a model outside information at runtime. Search is often treated as a secondary feature. In a production agent, however, repeated searches and page fetches can become a distinct infrastructure expense.

The low headline price immediately attracted attention. Yet the more important contest is not DeepSeek against one search vendor. It is cheap retrieval against dependable retrieval. Developers still need evidence that DeepSeek can return relevant sources, extract difficult pages, protect sensitive queries, and sustain production traffic.

The comparison also extends to integrated model platforms. OpenAI charges separately for web search calls and associated model input, while specialist providers sell search, extraction, or research as independent services. DeepSeek is betting that a simple interface and aggressive request price can make web access an ordinary agent primitive.

DeepSeek Search and Fetch Splits Retrieval Into Two APIs

DeepSeek has turned two common agent actions into independently billable services: finding pages and reading them.

The Search and Fetch guide documents two endpoints under the company’s existing API domain. Search accepts a query and returns structured results. Fetch accepts one URL and returns the page title and content in Markdown.

The Search endpoint can return between one and 50 results. Its response includes the title, URL, snippet, longer summary, publication date when available, and an authority score. DeepSeek says that scores of three or four identify highly authoritative sources, while negative one means the authority is unknown.

Developers can also request full page content with each search result. The need_content option makes that possible within the search call, although content remains empty when retrieval fails. This design can reduce orchestration work for agents that need both discovery and readable text.

The query syntax supports exact phrases, exclusions, language restrictions, date boundaries, and site filters. A developer can restrict results to selected domains or exclude a source without building a separate query translator. The original user question can also accompany the search phrase to help DeepSeek interpret intent.

Fetch performs the narrower task. It retrieves one HTTP or HTTPS URL and converts extractable content into Markdown, a plain-text format that preserves headings and links. This output is easier to pass into a language model than an unprocessed HTML document.

Both services use bearer authentication and ordinary JSON requests. They are not confined to a proprietary software development kit. An application can call them from a function tool, workflow engine, command-line agent, or custom backend.

That separation matters because search and extraction fail differently. Search might return no relevant result, while Fetch might encounter a blocked domain, unsupported format, or page without usable content. Keeping the operations distinct lets developers retry, replace, or cache either stage.

DeepSeek lists explicit error codes for invalid input, insufficient account balance, security rejection, unavailable content, rate limits, and downstream timeouts. It advises retries for timeouts, rate limits, and server errors, but not for other client errors without changing the request.

The service is read-only. It can discover and retrieve content, but it does not click buttons, submit forms, or operate a browser session. Teams still need a browser automation layer for interactive websites, authenticated resources, or applications that render important information after user actions.

Search requests have an account-level limit of 100 requests per second. Fetch has a separate limit of 25 requests per second and an additional per-domain restriction. Separate quotas prevent a burst of extraction work from consuming all search capacity.

These details make the release more than a model feature. DeepSeek is offering retrieval infrastructure that can sit beside its models or inside a broader agent system. The next question is how the billing rule changes application design.

The $0.75 Rate Rewards Successful Retrieval

DeepSeek charges for usable responses rather than every attempt, which shifts part of retrieval failure risk back to the provider.

Search costs $0.75 per 1,000 successful requests. Fetch carries the same rate. DeepSeek defines a successful Search request as an HTTP 200 response containing a nonempty results array. A Fetch request becomes billable only when it returns page content.

Failed calls, timeouts, and searches without results are not billed. The result count does not change the request price, so asking for 50 results carries the same search charge as asking for one. Model processing and other API usage remain separate expenses.

A workflow that makes one search and fetches five pages would therefore create six potentially billable retrieval calls. At the published rates, 1,000 such workflows would produce 6,000 successful calls and $4.50 in retrieval charges. Token processing would add another cost.

That distinction prevents a misleading interpretation of the headline. The advertised figure does not mean an entire research task costs $0.00075. An agent can reformulate queries, inspect multiple sources, follow citations, and fetch several pages before it writes an answer.

A deep-research workflow may produce dozens of calls. An autonomous agent can also repeat searches when sources conflict or when an initial query lacks useful results. Cheap unit pricing matters, but orchestration determines the final bill.

DeepSeek’s rule still offers developers a useful degree of predictability. Search charges do not change with the number of results, and unsuccessful retrievals do not consume paid units. Teams can estimate costs from successful tool calls instead of modeling an additional stream of retrieval tokens.

The release also affects DeepSeek’s coding and agent integrations. Its documentation says server-side tool calls from DeepSeek Harness, Claude Code, and Codex already use the Search and Fetch services. Those calls remain free until billing begins at midnight Beijing time on November 1, 2026.

That date is operationally important. A developer may not issue an endpoint request directly, yet an agent can trigger searches while solving a task. Usage dashboards and budgets therefore need to count autonomous tool calls, not only actions explicitly initiated by a person.

DeepSeek’s Responses API guide shows how server-side search can participate in a model response. In that setup, the platform runs retrieval, adds the results to the model’s context, and continues generation. The convenience also makes search consumption less visible inside a long agent session.

For comparison, the current OpenAI API pricing lists web search at $10 per 1,000 calls, with search content tokens billed at the selected model’s rates. The services are not identical, so the numerical gap does not establish equivalent value.

Integrated search can include ranking, source handling, citations, safety controls, regional features, or model-specific optimizations. Independent APIs may expose more control over the retrieval loop. Buyers need to compare complete tasks rather than one line on a pricing page.

DeepSeek’s offer nevertheless creates pressure at the lower end of the market. A developer experimenting with thousands of calls can now treat hosted retrieval as a small variable expense. That weakens the assumption that every agent team must operate its own scraping and search stack to control costs.

The change also favors modular architectures. Search can serve one model, while Fetch can supply content to another. A team can preserve its model choice and test DeepSeek as a retrieval component, although account terms and data handling still require review.

Cheap AI Search Pressures Integrated and Specialist Providers

DeepSeek is testing whether search should remain a premium AI feature or become inexpensive infrastructure.

AI applications use web retrieval for several different jobs. A support agent checks current documentation. A research assistant finds evidence for a claim. A coding agent reads release notes, issue trackers, and library references that appeared after its training cutoff.

These tasks require more than a familiar search result page. The application needs machine-readable output, stable response fields, predictable latency, and text that can enter a model context. It also needs a billing system that does not punish reasonable retry behavior.

Specialist providers compete through index coverage, ranking quality, extraction success, freshness, and workflow features. Some offer full-page text, answer synthesis, domain filters, or research endpoints. Others emphasize data residency and contractual controls.

Model vendors take a different route. They can embed search inside a response and let the model decide when to use it. This reduces integration work, but it can make retrieval behavior harder to observe or transfer between platforms.

DeepSeek combines parts of both approaches. Its raw endpoints resemble specialist infrastructure, while its server-side tools connect retrieval to DeepSeek models and compatible agent clients. That gives the company two routes into a developer’s stack.

The low rate is most compelling for high-frequency, modest-value tasks. Consider an internal monitoring system that checks vendor documentation every hour. Search quality must be acceptable, but each individual query does not justify an expensive research process.

The calculation changes for high-stakes work. A legal, medical, financial, or security workflow may value dependable source coverage far above the request price. Missing one authoritative document can cost more than thousands of searches.

Latency also matters. A chat assistant cannot pause for a slow chain of searches and fetches after every short question. A research job may tolerate more time, but it still needs successful extraction across many domains.

Developers discussing the release on the Hacker News thread highlighted both sides of that tradeoff. Some viewed hosted retrieval as easier and more reliable than maintaining scrapers. Others questioned coverage, privacy, rate limits, and extraction quality.

Those comments are anecdotal rather than benchmark results. They show the questions buyers are asking, but they do not establish that one provider performs better. The service is too new for broad production evidence to settle the comparison.

Self-hosted search remains another opponent. Open-source metasearch systems can aggregate public engines without a per-request vendor fee. Direct extraction tools can also convert many ordinary pages into clean text.

However, “free” self-hosting still involves servers, proxies, updates, observability, and responses to blocking. Teams must decide whether that operational work is worth avoiding a hosted fee. The answer changes with scale, staff, and reliability requirements.

DeepSeek’s price narrows the economic argument for maintaining that infrastructure. It does not eliminate the control argument. A locally operated system can keep queries within an organization and apply custom ranking or allowlists.

The practical response is measurement. Teams should build a fixed evaluation set that represents their real domains and questions. They can then compare relevance, source diversity, extraction completeness, latency, and total calls per finished task.

A searchable collection of internal technical material can complement live retrieval. Teams often need both current public sources and private context. A structured engineering knowledge base can keep internal evidence available without sending every question to the public web.

That combined architecture also reduces unnecessary searches. The agent can consult local material first, identify what is missing, and reserve external retrieval for information that needs fresh verification.

DeepSeek Search API Quality Remains the Missing Number

The pricing is verified, but the evidence needed to judge search quality is still incomplete.

DeepSeek says Search runs on its in-house engine. Its response schema exposes summaries, ranking scores, authority levels, and optional page content. Those fields are useful, but a schema cannot prove that the underlying results are relevant or complete.

Search quality varies by language, geography, topic, and query type. An engine might perform well on Chinese technical sources while missing local North American reporting. It might find official documentation reliably but struggle with niche forums or recently updated pages.

Fetch quality has its own failure modes. Modern sites can require JavaScript, reject automated clients, place content behind authentication, or serve important information inside documents. DeepSeek notes that fetching remains subject to site availability and access policies.

A successful HTTP response also does not guarantee useful evidence. Extracted Markdown can omit a table, confuse navigation with article text, or lose relationships between captions and images. Agents can then produce confident answers from incomplete material.

The “successful request” billing definition is narrower than successful task completion. Search becomes billable when it returns at least one result, even if that result is irrelevant. Fetch becomes billable when it returns content, even if the content lacks the needed fact.

Teams should therefore monitor semantic success separately from billable success. Useful measures include whether the correct source appears, whether extraction contains the target passage, and whether the final answer cites evidence supporting its claims.

Source diversity is another test. An engine that repeatedly returns copies of the same report can create the appearance of corroboration. Deduplication by URL alone will not detect syndicated or rewritten material.

Developers also need to inspect the authority score. DeepSeek defines the scale, but its public guide does not explain the complete scoring method. A high score should guide ranking, not substitute for an independent judgment about the source.

Political and regional coverage deserves careful testing. Search engines make choices about indexing, ranking, safety, and legal compliance. Those choices can affect what an agent sees before a language model even begins reasoning.

Privacy presents a separate concern. Queries can disclose product plans, security problems, customer names, acquisition targets, or unpublished research. Fetch URLs can reveal which documents and systems an organization is investigating.

DeepSeek’s public privacy policy should be reviewed alongside the API agreement before sensitive deployment. The Search and Fetch guide explains functionality and billing, but it does not provide a dedicated zero-data-retention promise for these endpoints.

A procurement review should establish what request data is logged, where it is processed, how long it is retained, and whether it can support service improvement. Contractual commitments matter more than assumptions drawn from the low price.

Security teams should also examine indirect prompt injection. A fetched page can contain text designed to manipulate an agent, request secrets, or redirect its behavior. Converting a page to Markdown does not make its instructions trustworthy.

Applications need to treat retrieved content as untrusted data. Tool permissions should remain separate from page text, and the agent should not execute instructions merely because they appear in a source. Sensitive actions require explicit policy checks outside the model’s generated plan.

Caching can reduce both expense and exposure. Frequently requested public pages do not need repeated retrieval when freshness requirements allow reuse. A cache also provides a record of exactly what content informed an earlier answer.

Still, caching introduces version questions. Teams must record retrieval time, source URL, and content hash if they need reproducible results. Otherwise, a later fetch can return a changed page that no longer supports the original claim.

DeepSeek has made the cost easy to understand. It has not removed the engineering work required to make retrieval accurate, safe, and auditable.

How DeepSeek Search and Fetch Changes Agent Design

The release makes retrieval cheap enough to use more often, but good agents should search more deliberately, not indiscriminately.

A strong workflow begins by deciding whether live information is necessary. Stable definitions and internal procedures may already exist in a trusted knowledge store. Current prices, releases, policies, and news usually require outside verification.

The agent can then convert the user’s question into a small search plan. One query should target the primary source. Another can look for independent reporting or criticism. Additional searches should address specific gaps rather than repeat broad wording.

DeepSeek’s operators support that pattern. A query can target official domains, set a publication window, or limit languages. These controls help an agent search with an evidentiary purpose instead of gathering a large, unfocused result set.

The result count also creates an optimization opportunity. Because the published request rate does not change between one and 50 results, a system can request enough candidates for reranking. It should still avoid filling the model context with every returned item.

A separate ranking stage can select sources by relevance, authority, recency, and diversity. Fetch should then retrieve only the pages likely to influence the answer. This reduces extraction calls and limits untrusted text entering the model.

The workflow should preserve citations throughout processing. Summaries are convenient, but a final answer needs URLs and passages that support each important claim. When evidence conflicts, the system should report the disagreement rather than blend it into one unsupported conclusion.

Fetch failures need bounded retries. Retrying a rate-limited or timed-out request makes sense after a delay. Repeating a security rejection or unsupported-content error without changing the request wastes time and can create a loop.

Production systems also need budgets at several levels. A session limit prevents one user request from triggering hundreds of searches. A daily account limit contains unexpected traffic. Per-domain controls reduce pressure on individual sites.

The new economics could encourage excessive retrieval because each call appears nearly free. That would be a mistake. More search results can increase latency, duplicated evidence, context size, and opportunities for prompt injection.

Agent designers should measure cost per accepted answer, not cost per API call. That metric includes retrieval, model tokens, retries, validation, and human review. It also reflects whether the answer actually solved the user’s problem.

A useful evaluation set can contain four categories. Freshness questions test recent updates. Known-item questions test whether the engine finds a specific authoritative page. Comparative questions test source diversity. Difficult pages test extraction behavior.

Each test should record the rank of the expected source, extraction completeness, latency, and number of paid requests. Evaluators can score citation support and note when an answer requires another provider or manual review.

The raw endpoints also make fallback routing practical. An application can try DeepSeek for ordinary searches, then use another source when coverage or extraction fails. This protects quality while preserving lower average cost.

That strategy requires normalization. Providers return different fields, scores, summaries, and date formats. A common internal schema can prevent the rest of the application from depending on one vendor’s response shape.

DeepSeek’s API is therefore easy to test but not automatically easy to replace. Developers should isolate authentication, error handling, and provider-specific ranking fields inside an adapter. The agent can then request “search” without knowing which service executes it.

This architecture turns price competition into a buyer advantage. Providers must earn traffic through measurable performance, while teams retain the ability to move workloads when policies or quality change.

Three Signals Will Determine Whether the Low Price Matters

The next test is whether DeepSeek can convert developer curiosity into sustained production use without weakening quality or trust.

The first signal is independent retrieval benchmarking. Useful tests must cover languages, recent events, technical documentation, local information, and adversarial pages. They should publish query sets and scoring methods, not only a single average.

If DeepSeek consistently finds authoritative sources and extracts complete content, the low rate gains strategic weight. If results require repeated searches or frequent fallback providers, the headline advantage will shrink at the task level.

The second signal is enterprise data handling. Buyers need clear answers about query retention, processing locations, training use, security controls, and contractual deletion. A documented zero-retention option would strengthen DeepSeek’s position with sensitive workloads.

Silence or ambiguity would have the opposite effect. Many organizations will pay more for enforceable controls because search terms can expose confidential intent. Cheap retrieval cannot compensate for an unacceptable data path.

The third signal is competitor response. Search specialists and model platforms can reduce prices, bundle retrieval, improve free allowances, or emphasize higher-quality research. They can also differentiate through regional processing, citations, browser execution, or enterprise agreements.

A broad price response would confirm that DeepSeek has reset expectations for basic retrieval. A limited response would suggest that competitors believe buyers value quality, integration, and governance more than the request fee.

Developers should also watch usage after billing begins on November 1. Continued adoption would show that users value the service beyond its initial free period. A sharp decline would indicate that curiosity, rather than production demand, drove early attention.

The published rate gives DeepSeek an effective entry point. Search and Fetch are simple enough to test in a few hours, and unsuccessful requests do not create retrieval charges. That lowers the cost of running a real evaluation.

It does not settle the buying decision. Teams should compare representative tasks, review the relevant agreements, and trace the full path from query to cited answer. They should also test failure conditions before routing customer or company data through the service.

DeepSeek Search and Fetch makes one claim difficult to ignore: live web access no longer needs to be an expensive premium attached to a model. The remaining question is whether DeepSeek can deliver reliable, governable retrieval at that price.

Run the same evaluation set across your current provider and DeepSeek. Measure relevant sources, complete extractions, latency, billable calls, and citation accuracy. Then repeat the test with sensitive queries removed until the data terms meet your requirements. If DeepSeek wins on complete tasks rather than isolated calls, its $0.75 rate will matter. If it only wins on the price sheet, the cheapest search request may still produce the more expensive answer.