dsh-web-search-provider

The built-in web-search-deepseek plugin spawns a separate internal session to perform each search, then shoves the results back into your conversation. That design costs you extra latency and a heavy token bill. dsh-web-search-provider takes a different route: instead of routing through DSH's internal web_search tool, it sends the model's search request straight to the provider's endpoint and lets the server execute the search natively. In a controlled five-query benchmark, the plugin averaged 14.5 seconds and roughly 822 output tokens per run, compared to 47.5 seconds and 4,446 tokens for the built-in plugin. The gap grows larger the more web content a task demands.

The depth of what you get depends on the provider API behind your route. On an OpenAI Responses API endpoint, the model can not only fire off search queries but also pull a URL's page content and search for specific text within that page, eliminating the need for the AI to bash/curl an entire page into context. On an Anthropic-compatible Messages API, the provider exposes the search capability alone. The plugin is configurable down to provider whitelists, base-URL overrides, model pinning, idle timeouts, and an optional pre-flight probe that verifies the endpoint actually executes native search before you ever serve a real request. Because it bypasses DSH's internal web_search tool slot, it coexists cleanly with other search-provider plugins and can be toggled per route.

This plugin is a good fit if your DSH sessions lean heavily on live web lookups, you are watching response latency or token spend, and your current model provider genuinely offers a native search capability. The experience is most complete on OpenAI Responses API routes (Deepseek official, OpenCode Go, OpenAI relay stations, and the like). A couple of caveats: some providers charge extra for the search feature; and if a provider speaks the Responses or Messages protocol but does not actually support search, the first call will error out. DSH itself keeps working fine in that case, it simply loses the web-search leg until the route is switched to a supported provider.