DeepSeek launches Search and Fetch APIs with separate agent billing
DeepSeek has made web retrieval a cheap agent primitive, but the separate meter, throughput ceiling and added lock-in argue for a measured pilot rather than a direct production switch.
What shipped
On October 17, DeepSeek opened its Search and Fetch APIs to everyone. Search returns structured web results, while Fetch retrieves one page and returns its content as Markdown.
Both are standalone JSON APIs using the same authentication as DeepSeek’s model API, so teams can call retrieval directly instead of leaving every decision to the model.
Where cost moves
Search and Fetch each cost $0.75 per 1,000 successful requests. Empty results, failed requests and timeouts are not billed, but model usage remains a separate cost.
Server-side calls made through DeepSeek Harness, Claude Code and Codex are currently free for DeepSeek API users. Billing begins at 16:00 UTC on October 31, 2026. Each API also has its own account-level limit of 5 requests per second.
What we would do
Virtual Arc would put the service into a controlled pilot for research and coding agents, but we would not wire it directly into application logic. We would add an internal retrieval layer, log every Search and Fetch call, and limit how many pages a task may retrieve.
Production migration should wait until completed-task cost, latency and fetch-failure rates have been measured on real traffic. We would keep a second search provider available until then.
DeepSeek’s Search and Fetch launch matters more than another incremental model release because it turns web retrieval into an explicit, low-priced primitive that agents can call directly. The headline rate—$0.75 per 1,000 successful requests for each endpoint—is attractive, and failed calls, empty searches and timeouts are not billed. But teams should not read cheap as free or unlimited: Search and Fetch are separate meters, model usage remains another cost, and each API is capped at 5 requests per second per account. Virtual Arc would test this now for research and coding workflows, but only behind a provider-neutral retrieval interface. We would log every search and fetch, cap fan-out per task, set budgets at the workflow level and keep an existing search provider as a fallback. We would not let a coding agent silently adopt the server-side tools before billing starts on November 1, because that converts an invisible convenience into a production dependency without a measured cost per completed task.