Why configuring web_search means installing a plugin
DeepSeek Harness ships with two built-in web tools: web_search, which looks things up, and web_fetch, which opens a specific URL and returns its readable content. Together they cover the browsing loop every agent needs: find a source, read it, cite it. Out of the box, both run through DeepSeek’s official provider and authenticate with a DeepSeek API key—the official repository calls the whole product “everything is a plugin,” and web search is one of the plugin seams. The tools themselves are native; only the provider behind them is swappable.
That seam is the thing people get stuck on. A r/LocalLLaMA thread that ranks first for “deepseek harness web_search api key” describes the exact failure: you point the harness at another model source, the model works, and then every web_search call still bills you as if it had called DeepSeek’s own model. The same issue shows up in the harness’s GitHub Discussions, where a ten-comment thread reports that web_search pins itself to the official endpoint, so users of self-configured gateways hit authentication failures on every search.
The reason is structural. The harness routes web_search and web_fetch through a searchProvider / fetchProvider seam, and the default provider is DeepSeek’s own. The configuration-only path that swaps your model source—covered in the DeepSeek Harness custom model guide—does not touch this seam. Swapping the search and fetch providers is exactly what the Modellix plugin for DeepSeek Harness calls the “second reason a plugin exists”: a plugin can patch the seam, pure configuration cannot.
This article walks through one concrete seam swap: the dsh-modellix plugin’s Web module, which registers Modellix as the search and fetch provider for the native tools. Modellix operates the search API used in these examples, so we have a commercial interest in this working for you. Endpoints and prices were verified against docs.modellix.ai on August 31, 2026; plugin behaviors were verified against the dsh-modellix README (0.2.0).
What the Web module does (and does not do)
The dsh-modellix profile bundle ships three modules—Design, LLM, and Web. The Web module’s entire job is to make web access run through Modellix. This article documents dsh-modellix 0.2.0 (released August 31, 2026); the native-provider takeover introduced in 0.1.x remains. The plugin README describes the current behavior verbatim:
The explicit Modellix tools and the native Harness providers share the same underlying service, but the routing instruction prevents both tool families from being called for the same operation. Failed or unknown Web requests are not repeated automatically.
That mechanism is the structural difference this article is about. There are two ways to give a harness web access:
- Take over the native seam. The plugin patches the existing configuration so
web_searchandweb_fetchkeep their names, keep their call signature, and simply hit a different provider. The model keeps using tools it already knows how to call. - Create a new custom tool. A plugin or skill adds a differently named capability (a new skill, a new tool) that the model has to learn, discover, and prefer over the built-in one.
dsh-modellix 0.2.0 sits on both sides of that line. Its cordis.patch.yml sets searchProvider: modellix and fetchProvider: modellix with 60-second timeouts for both tools, and registers the plugin under the modellix id—the same patch as 0.1.x, so the native web_search and web_fetch still run through Modellix. On top of that, 0.2.0 registers explicit modellix_web_search and modellix_web_fetch tools that Agent routing selects automatically when current or source-backed information is needed. Both tool families share the same Modellix service, and the routing instruction is what stops them from being called for the same operation.
The seam takeover in one diagram: the native tools and the explicit Modellix tools share the same Modellix service, and the routing instruction prevents both tool families from being called for the same operation.
Three behaviors follow from this design, and all three are worth knowing before you install:
- The provider is unavailable when Web is disabled or no valid Key exists. The native tools exist, but there is nothing behind them.
- Web requests may incur Modellix usage, and the provider does not automatically retry. If a request fails on the wire, the plugin does not re-fire it for you. That is a deliberate boundary: retrying a billed call automatically is how duplicate charges happen.
- If a paid Fetch outcome is unknown, inspect the Harness transcript or the Modellix-side record before repeating it manually. “Outcome unknown” is a real state (connection dropped after the request left), and the documented recovery is to check what actually happened, not to re-run the call blindly.
Before you start: versions and a key
The plugin pins its host interfaces, so the version requirements are not negotiable:
- DeepSeek Harness
0.1.1-rc.2— the plugin’s peer dependencies are fixed to@deepseek-ai/dsh-*@0.1.1-rc.2. Harness and the plugin both use prerelease interfaces; check the package’s peer dependencies before upgrading Harness. - Node.js
^22.19.0 || >=24.0.0for the published package. - A Modellix API key from the Modellix console—a Modellix key, not a DeepSeek, OpenAI, or Anthropic platform key. The getting-started guide at docs.modellix.ai shows where to create one.
One ordering trap from the plugin’s local-usage notes: a fresh profile may show Harness’s own DeepSeek initialization dialog first. Complete (or dismiss) that step before the plugin’s “Connect Modellix” dialog appears—otherwise it looks like the plugin failed to load when it is simply waiting its turn.
Install and verify: three commands
Installation is three commands against the profile that runs your Web UI (default web):
1 | dsh plugin --profile web add dsh-modellix |
Verification lives in the middle command: --dump-config should show the dsh-modellix Bundle layer and a plugin row whose id is modellix. If you see those two entries, the Web module is registered; start or restart the profile and the “Connect Modellix” dialog will appear on first launch.
Two details that are easy to miss:
- Updating the plugin requires restarting the profile. Reloading the browser does not load a new Client Bundle. After
dsh plugin add(or an update), stop and start the profile. - Installing from source is not
dsh plugin add <git-url>. Building a tarball from the repo (pnpm install --frozen-lockfile→pnpm run verify:release:static→pnpm pack) and adding the.tgzworks; pointing the plugin command at an unbuilt Git checkout does not, because the package must producelib/before it loads. For Windows isolation environments, the plugin’sLOCAL_USAGE.mddocuments aDSH_HOME-scoped flow.
The key: what web_search actually authenticates with
The “deepseek harness web_search api key” question has a simple answer once the seam model is clear: the key belongs to the provider configured on the seam, not to the tool name. Default provider, DeepSeek key. Provider swapped to Modellix, Modellix key. The web_search tool itself never “needs a DeepSeek key”—it needs whatever key the provider on the seam accepts. That is why the reddit thread’s setup kept billing DeepSeek: the model source was changed, but the search provider on the seam was still DeepSeek’s.
The Web module accepts the key from two sources, matching the rest of the plugin:
- Enter it in the “Connect Modellix” dialog or in Modellix settings. The Harness Credential service stores it; after saving, the UI shows only a redacted descriptor, never the key itself.
- Provide
MODELLIX_API_KEYin the Harness launch environment. An environment-sourced key is read-only in the UI—change it outside the harness and restart.
The plugin’s README is explicit about handling keys: never put a real key in a repository, command argument, log, screenshot, HAR, recording, or test snapshot. MODELLIX_API_KEY in your shell profile or secret manager is the supported pattern. The one-key-per-provider rule also means a single Modellix key covers search, fetch, and any Modellix LLM models you configure—there is no separate “search key” to create.
What the two tools call on the Modellix side
Modellix’s web tools run at https://tool.modellix.ai, launched on August 17, 2026 per the product changelog. Both calls are synchronous and use the same Modellix API key. The Modellix Tools overview documents the two endpoints:
| Tool | Endpoint | What it does |
|---|---|---|
| Web Search | POST /v1/web-search |
Returns ranked results; depth lite, standard, or rich; optional filters for domain, time range, topic, or country |
| Web Fetch | POST /v1/web-fetch |
Extracts readable title and content from public HTTP/HTTPS URLs, up to 20 per request; failed URLs are returned separately |
Pricing follows the same per-call split. Web Search is charged per request by depth—not per result, not per URL: lite $0.01, standard $0.015, rich $0.02 per request (default standard). Web Fetch is charged $0.002 per successful URL, and failed URLs are not billed. Full parameter details live in the Web Search and Web Fetch API references. Prices change; confirm current rates in the Modellix console before you rely on them.
Both tools are synchronous calls on the same host: search is billed once per request at the chosen depth, fetch is billed per successful URL.
Two practical notes. First, the tool calls carry an X-Mdlx-User-Id header (8–128 characters), which the provider sets on your behalf—you do not configure it inside the harness, but it is what appears in Modellix-side request logs if you need to trace a specific agent run. Second, request history is queryable through the Get Tool Logs endpoint, which is the “Modellix-side record” to check when a fetch outcome is unknown.
How this differs from community web search plugins
The SERP for “deepseek harness web search” is dominated by community-built search plugins, and each one sits on a different side of the seam distinction above:
| Plugin | Form | Where it operates |
|---|---|---|
| ModSearch | A skill with its own CLI and engine failover (Firecrawl, Tavily, Exa, Grok, local) | A new capability called by name—a new tool, not a replacement for the native one |
| AnySearch provider | A custom WebSearchProvider against AnySearch’s /v1/search, with its own settings section and credential flow |
At the seam, but community-built and maintained, and search only—fetch stays on the default provider |
| dsh-modellix (0.2.0) | Native seam takeover (cordis.patch.yml unchanged) plus explicit modellix_web_search / modellix_web_fetch tools |
Both: the native tools run through Modellix, and Agent routing selects the explicit tools automatically—the routing instruction prevents both families from being called for the same operation |
These are structural differences, not quality judgments. A custom tool and a seam takeover both give the model web access; the difference is what the model has to know. With a seam takeover, web_search behaves exactly as before from the model’s perspective—same name, same arguments, same result shape—so prompts, agent presets, and saved sessions that already call it keep working. With a new tool, the model must discover the new name and learn to prefer it. Under 0.2.0 the two paths coexist in dsh-modellix: the seam keeps the native tools on Modellix, and the explicit tools give the Agent an automatically selected route to the same service.
One honest caveat that belongs to the harness, not to any plugin: community threads have noted that web_fetch lacks HTTP proxy support. That is a Harness-side gap raised against the native tool—it is not a defect of the Modellix plugin, which simply routes the native tool to its provider.
Where this fits: boundaries and next steps
The Web module is one of three in the plugin; the Design module covers image, video, and audio generation and has been chat-first since 0.2.0 (a separate guide in this series covers it), and the LLM module handles model selection. If you only needed a different model source, you did not need a plugin at all—the custom model guide is pure configuration. If you are deciding whether any plugin is worth it, the plugin mechanisms article explains bundles, manifests, and the two entry points.
For the wider category, the agent harness overview provides the surrounding context and the pillar DeepSeek Harness article ties the whole cluster together. If you are weighing gateway-level options rather than Harness specifics, the unified AI API guide covers the aggregation-API angle.
Two boundaries worth stating explicitly. First, this article is about how to connect search and fetch in the harness—which search provider to pick (Tavily versus Exa versus a tool API) is a separate selection decision, and a dedicated guide covers provider alternatives. Second, choosing Modellix for search does not change the text-gateway rule for the LLM side: the Modellix LLM gateway is text-only, and you should not attach images to model requests in the harness.
What you should be able to do now: install the plugin, confirm the modellix provider row in --dump-config, enter one Modellix key, and ask the harness to search and fetch through the native tools—knowing that search is billed per request, fetch per successful URL, and neither is retried automatically.
DeepSeek Harness Integration Docs
Read the full DeepSeek Harness configuration reference for the Modellix LLM gateway, including the Web module, credentials, and the troubleshooting table.
View DocsOpen the Modellix Console
Log in to create your Modellix API key and check live Web Search and Web Fetch rates before your first harness run.
LoginEndpoints, prices, and launch dates reflect Modellix public documentation as of August 31, 2026, and change as the platform evolves; confirm live rates in the Modellix console before committing. Access image and video models, including the leading Chinese models, through a single API key at modellix.ai.
