My agent could fetch a URL but could not search for one

A developer testing DeepSeek Harness v0.1.1-rc.2 found that the agent's web_fetch tool worked via anonymous HTTP while web_search failed with a 402 Insufficient Balance error, because the default searchProvider (deepseek-official) required a funded DeepSeek API account. The developer wrote a Tavily search provider and plugin checked against the installed type declarations, but it was not tested with a Tavily key, so the fix remains unverified. The developer concluded that agent tooling should surface provider and account dependencies before a task needs them, since 'tool enabled' is weaker than 'the selected provider can complete a request with this account.'

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.”