In my September 1 setup of DeepSeek Harness v0.1.1-rc.2, web_fetch worked while web_search could not complete a search. The difference was the service behind each tool, rather than whether the agent could reach the web.
This is a record of that setup, not a claim about the current release or every account.
The default profile selected searchProvider: deepseek-official and looked for its key in DEEPSEEK_API_KEY. My fresh DeepSeek API account returned 402 Insufficient Balance.
Having a key was therefore insufficient. The request reached a service that required a funded account. In the version I inspected, the three bundled search backends were DeepSeek, Exa, and Perplexity; none supplied a free search path for my setup.
web_fetch still worked. Fetching an already-known public URL used anonymous HTTP, without that search-provider balance requirement. That made the failure easy to describe too broadly: “the agent cannot use the web” would have hidden the useful capability that remained.
For a similar failure, I would separate these checks:
web_search does not tell you which external service will receive the request.
Those are diagnostic steps, not a guarantee that every 402 has the same cause. The concrete observation here was the Insufficient Balance response from my account.
I wrote a Tavily provider and plugin, and checked the interface against the installed type declarations. I had not tested it with a Tavily key. That means I had an implementation to try, not a verified alternative, and I cannot report that it fixed search.
The useful result from this investigation was a smaller, more accurate description of the system: fetching worked; the configured search service required funding; the proposed replacement remained untested.
For agent tooling, I would like a setup check to expose those dependencies before the first task needs them. “Tool enabled” is a much weaker statement than “the selected provider can complete a request with this account.”