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.

Two tools, two dependencies

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.

What I would check before changing the model

For a similar failure, I would separate these checks:

  1. Which provider does the active profile select? A tool named web_search does not tell you which external service will receive the request.
  2. Is the credential present, and is the account usable? These are separate conditions. In this setup, the balance response was the evidence that mattered.
  3. Can the agent fetch a known URL? A successful fetch does not prove search works, but it narrows the failure to a different dependency.
  4. What capability can the task still use? Supplying a known source URL may allow a fetch-only task to proceed. It does not replace discovery when finding sources is the task.

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.

A backend implementation is not a working fallback

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