dsh-web-search-responses

Readme

# dsh-web-search-responses

A [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH) `ctx.web` search provider that reuses the conversation model's **OpenAI Responses built-in `web_search`** tool, instead of DSH's built-in Anthropic Messages search provider.

## Why

DSH's model-facing `web_search` goes through `dsh-tool-web` → `ctx.web.search()` → a registered search provider. The shipped `web-search-deepseek` provider only speaks the Anthropic-compatible `/messages` API with `web_search_20250305`, so a custom model whose Responses endpoint supports built-in `web_search` cannot be reused by configuration alone.

This plugin registers a provider (`responses-web`) that sends a Responses API request to the same endpoint the conversation model uses, with:

```json
{
  "tools": [{ "type": "web_search" }],
  "tool_choice": { "type": "web_search" }
}
```

It parses the `web_search_call` item and message citations back into DSH's standard `WebSearchResult`.

## Install

### From GitHub (recommended)

Requires `pnpm` on PATH:

```sh
dsh plugin --profile web add github:herminger/dsh-web-search-responses
```

If you previously installed a local link copy and want to switch to the GitHub source:

```sh
dsh plugin --profile web remove dsh-web-search-responses
dsh plugin --profile web add github:herminger/dsh-web-search-responses
```

### From a local checkout

```sh
dsh plugin --profile web add /path/to/dsh-web-search-responses
```

Quick test without pnpm (keep `overlay.patch.yml` next to `index.mjs`, or use an absolute path):

```sh
dsh --profile web --patch /path/to/overlay.patch.yml
```

Then **fully restart** `dsh web` so the new bundle loads.

## Configuration

The provider auto-follows the current model by default:

- provider/model come from the executing agent, the DSH default model, or the single configured `llm-pi-ai` Responses route
- `baseURL`, `apiKeyEnv`, and `api` come from that route's `llm-pi-ai` settings

To pin a route explicitly, edit the profile's `cordis.patch.yml`:

```yaml
- id: web-search-responses
  config:
    provider: cpa
```

| Field | Meaning | Default |
| --- | --- | --- |
| `provider` | `llm-pi-ai` route to reuse | current model route |
| `model` | model for the search request | current model |
| `baseURL` | Responses endpoint prefix (`/responses` is appended) | route `baseURL` |
| `apiKeyEnv` | credential reference, e.g. `CPA_API_KEY` | route `apiKeyEnv` |
| `includeSources` | send `include: ["web_search_call.action.sources"]` | `false` |
| `searchContextSize` | `low` / `medium` / `high` | unset |
| `toolChoice` | `{ type: "web_search" }` or `"required"` | `{ type: "web_search" }` |
| `maxOutputTokens` | output token cap for the search request | `4096` |

## Troubleshooting

- `configured web provider "responses-web" is registered but unavailable` — the plugin's config was parsed as YAML `null` (empty `config:`). Update to the latest `index.mjs`, which normalizes `config ?? {}`, and restart DSH.
- `Responses API returned no web_search_call item` — the endpoint/model does not actually support the built-in `web_search` tool.
- `no API key for "..."` — check the route's `apiKeyEnv` and the credential stored in DSH.

Chinese docs: [README.zh.md](README.zh.md)