Make web search follow the session's LLM route (and support gateway routing headers)

[rinat797]

Environment: DSH Desktop 0.2.0-rc.2, macOS arm64, bundled runtime 0.2.0-rc.2 (hostProtocolVersion 4), LLM route opencode-go through @deepseek-ai/dsh-llm-pi-ai / @earendil-works/pi-ai 0.87.1, web search provider deepseek-official (@deepseek-ai/dsh-web-search-deepseek).

What I expected

With the conversation served by OpenCode Go (https://opencode.ai/zen/go), web searches would go through the same route I am paying for, and only sessions running on a DeepSeek route would search through api.deepseek.com.

What actually happens

Searches always go to https://api.deepseek.com/anthropic/v1/messages with DEEPSEEK_API_KEY, regardless of the session's LLM provider. So a conversation billed to a third-party gateway still spends DeepSeek API credit on every web_search — and each search is a full auxiliary model turn (in my probes: ~6.8k input / ~0.9k output tokens per search).

Pointing it at OpenCode Go fails on exactly one header

Config attempt:

- id: web-search-deepseek
  name: '@deepseek-ai/dsh-web-search-deepseek'
  config:
    apiKeyEnv: OPENCODE_GO_API_KEY
    baseURL: https://opencode.ai/zen/go/v1

Result: HTTP 400, error type MissingSessionID:

Request is missing x-opencode-session and cannot be routed efficiently.

The same request with an x-opencode-session: <id> header added: HTTP 200, content blocks thinking, server_tool_use, web_search_tool_result, thinking, text — 10 results, usage: {input_tokens: 6769, output_tokens: 896, server_tool_use: {web_search_requests: 1}}. Verified for both deepseek-v4.1-flash and the provider's default deepseek-v4-flash.

So the gateway does implement the native web_search_20250305 server tool; the only missing piece is the routing header.

There is no way to supply it today:

• the provider config schema is apiKey | apiKeyEnv | baseURL | model | apiVersion | maxTokens | maxUses, and the request headers are fixed (x-api-key, authorization, anthropic-version, content-type, accept, user-agent);
• the Plugins → Web search settings page exposes only API key, endpoint and max searches per request.

Worth noting the asymmetry: the chat path already sends this header — withOpenCodeSessionHeader in pi-ai (dist/providers/opencode-headers.js, "Adds OpenCode's required per-conversation routing header before API dispatch"). The requirement is known on the LLM route but not on the search route.

Two proposals (independent, either one unblocks me)

1. Allow extra headers in the web search provider config, e.g. headers: { x-opencode-session: ... }, ideally with values resolvable from the credentials store the same way apiKeyEnv is. That unblocks any gateway requiring routing or affinity headers, without hardcoding vendor knowledge.
2. Route search through the session's LLM route when that route can search. The provider already inspects the session for the account case — resolveAccountToken returns nothing unless session.requestContext().provider === "deepseek-account". Generalizing that rule to: "if the session's route is an Anthropic-compatible Messages endpoint that supports web_search_20250305, search through that route using its base URL, credential and headers; otherwise fall back to the current DeepSeek default" would match the mental model that search belongs to whichever model/account the conversation runs on. It would also make the 0.2.0-rc.1 improvement ("no extra API key needed for web search") apply to non-DeepSeek routes by construction, instead of only to account-model sessions.

Happy to test a patch or a new config field on 0.2.0-rc.2 and report back.

[slyyr]

The successful request after adding x-opencode-session is a strong indication that the web-search adapter is missing session-specific routing information rather than the gateway itself being incompatible.

I'd separate the problem into two parts:

1. Resolving which provider/base URL/credentials should handle the search.
2. Passing the routing metadata required by that provider.

If the current session already has a resolved LLM route, the web-search implementation could reuse that route when it is compatible with the search tool instead of always falling back to the DeepSeek endpoint.

For gateways such as OpenCode Go that require session affinity, the adapter should also allow provider-specific routing headers such as x-opencode-session to be supplied.

I would avoid hardcoding OpenCode-specific behavior into the generic web-search implementation. A better design would be for the selected provider/route to expose the required headers or request context, with the web-search adapter simply forwarding them.

A regression test using a mock Anthropic-compatible gateway that requires x-opencode-session would be useful here. It could verify both that the session route is selected and that its required routing headers reach the request.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.

[rinat797]

Thanks — the diagnosis matches what I could reproduce on 0.2.0-rc.2, and I agree with splitting this into "select the route" and "carry that route's routing metadata". Adding the concrete artefacts in case they help whoever implements it.

Reproduction (Desktop 0.2.0-rc.2, macOS arm64, session route opencode-go via dsh-llm-pi-ai / @earendil-works/pi-ai 0.87.1)

Config attempt:

- id: web-search-deepseek
  config:
    apiKeyEnv: OPENCODE_GO_API_KEY
    baseURL: https://opencode.ai/zen/go/v1

• exactly as above → 400, error type MissingSessionID: "Request is missing x-opencode-session and cannot be routed efficiently."
• same body plus x-opencode-session: <id> → 200, content blocks thinking, server_tool_use, web_search_tool_result, thinking, text, 10 results, usage: {input_tokens: 6769, output_tokens: 896, server_tool_use: {web_search_requests: 1}}.

Both deepseek-v4.1-flash and the adapter's default deepseek-v4-flash work on that gateway, and an arbitrary constant session id is accepted — so nothing secret is being asked for, only stable routing metadata.

Regression test sketch

With a mock Anthropic-compatible gateway that rejects requests lacking x-opencode-session, assert that:

1. the request goes to the session route's base URL, not the shipped DeepSeek endpoint;
2. it carries the route's routing header with the same value the chat path uses for that session;
3. a route with no search-compatible API (or no header contract) still falls back to the current DeepSeek behaviour instead of failing.

Two details the "selected route exposes its headers" design will meet today

1. On the chat path the header is added inside the LLM adapter, not exposed as route metadata: pi-ai's withOpenCodeSessionHeader wraps stream/streamSimple and injects x-opencode-session from options.sessionId (dist/providers/opencode-headers.js). So either the LLM seam has to surface per-route request metadata, or the search provider needs a generic way to carry headers from config. Both are fine designs; hardcoding OpenCode into the generic search adapter is not — agreed.
2. session.requestContext() currently returns only {provider, model, contextWindow?, systemPromptUpdate?} (dsh-agent-loop), so a search initiated from an opencode-go session has no way to obtain the same sessionId the chat path sends. Whatever shape is chosen, the routing id needs to reach the search adapter.

Happy to test a patch or a new config field on 0.2.0-rc.2 and report back with the same probes.