feat(sidecar): OpenCode Zen (opencode.ai/zen/go/v1) as web-search sidecar backend — natively serves hosted web_search, no ChatGPT/Claude quota

[carlosqwqqwq]

Area

Proxy and routing · Web-search sidecar

What are you trying to accomplish?

When the main model is routed through a third-party provider, the web-search sidecar currently has only two backends: openai (gpt-mini via the ChatGPT forward path) and anthropic (stored Claude OAuth). Both borrow an account the user may have very little quota on — and when that quota is exhausted, search turns degrade (the exact scenario from #398).

I'd like to point the web-search sidecar at a provider I actually have quota on: OpenCode Zen (https://opencode.ai/zen/go/v1, the built-in "opencode-go" provider), using e.g. deepseek-v4-flash to execute the search — with zero ChatGPT/Claude quota consumption.

What prevents this today?

• OcxWebSearchSidecarConfig.backend is hardcoded to "openai" | "anthropic" (src/types.ts, src/web-search/index.ts resolveSidecarBackend); there is no keyed/custom-provider option.
• The hosted web_search tool is unconditionally stripped for routed providers (src/responses/parser.ts buildTools), and the sidecar executor only knows how to POST to the ChatGPT forward endpoint with forwarded OAuth headers (src/web-search/executor.ts runWebSearch).
• I verified there is no config-only workaround (changing webSearchSidecar.model, disabling the sidecar, or repointing the openai provider's baseUrl all fail — the latter breaks isCanonicalOpenAiForwardProvider).

Key fact: OpenCode Zen natively serves hosted web_search

Unlike a plain OpenAI-compatible chat gateway, OpenCode Zen executes the Responses API's hosted web_search tool server-side. Tested 2026-08-13 with a opencode-go API key (model deepseek-v4-flash):

• POST https://opencode.ai/zen/go/v1/responses with tools: [{type: "web_search", max_results: 5}] + tool_choice: {type: "web_search"} → 200.
• The model ran real multi-step searches (web_search_call with search and open_page actions) and returned a summary with source URLs.
• Streaming emits standard Responses SSE — response.output_text.delta, response.output_text.done, response.completed (plus ping heartbeats) — exactly the event shapes parseSidecarSSE already handles.
• The gateway reports "cost": "0" for these calls; either way, the spend lands on the user's Zen key, not ChatGPT/Claude.

This is the "provider-native search capability" category of #415 — Zen just isn't on the list there yet. It also fits #414's "decouple which account backs search" goal without adding a dedicated search vendor.

Proposed change (minimal, additive)

Add a third sidecar backend, e.g. backend: "keyed" with provider + model config, that POSTs to the named provider's {baseUrl}/responses with Authorization: Bearer <apiKey> and the same hosted tool + BASE_INSTRUCTION, reusing the existing loop, parseSidecarSSE, and format-result unchanged:

• src/types.ts — extend OcxWebSearchSidecarConfig (backend: "keyed", provider?: string)
• src/web-search/executor.ts — add runKeyedWebSearch() (~30 lines, mirrors runWebSearch with Bearer auth)
• src/web-search/index.ts — planWebSearch keyed branch, resolving a configured key-auth openai-responses provider
• src/web-search/loop.ts + src/server/responses/core.ts — thread the keyed provider through and dispatch

Roughly 60–80 additive lines; the ChatGPT forward path and anthropic path stay untouched.

Acceptance criteria

• Config like webSearchSidecar: { backend: "keyed", provider: "opencode-go", model: "deepseek-v4-flash" } makes search runs on the Zen key with no ChatGPT/Claude quota involvement.
• Search cells, citations/sources, and the loop behavior match the existing openai backend.

Related

#398 (original fixed-backend bug), #414 (dedicated search vendors like Exa), #415 (provider-native search, e.g. Gemini Grounding — Zen is a sibling case), #1276 (superseded umbrella; maintainer's note that arbitrary LLMs can't auto-back search is exactly why Zen's hosted tool is special).

[coderabbitai]

🔗 Related PRs

#652 - feat(providers): add bounded model discovery contract [merged]
#671 - feat(codex): add exact account routing [merged]
#1155 - fix(web-search): preserve buffered upstream policy [open]
#1161 - feat(vision): add chat and Google sidecars [open]
#1529 - fix(codex): keep direct MCP tools visible for routed models [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Maintainer decision respected

A maintainer has reopened this issue. The automated closure has been deactivated.

[lidge-jun]

Accepted as a provider-native web-search sidecar request, with a narrower implementation contract than the proposed generic executor.

Verified against current dev: OcxWebSearchSidecarConfig.backend permits only "openai" | "anthropic" in src/types.ts:1141, and resolveSidecarBackend can resolve only those two values in src/web-search/index.ts:103. The management endpoint rejects every other backend in src/server/management/config-routes.ts:465. opencode-go exists as a key-auth provider at src/providers/registry.ts:1188 but cannot be selected for search, so your "no config-only workaround" claim reproduces and is not fixed on dev.

Please do not implement this as an unrestricted backend: "keyed" branch accepting any configured provider. The sidecar sends a provider API key to an outbound endpoint, so selection must fail closed unless the provider is enabled, key-authenticated with a resolvable key, uses the Responses wire, and carries an explicit tested declaration that it supports the hosted web_search tool. Keep redirects disabled/manual as the existing credential-bearing executor does (src/web-search/executor.ts:81), and keep API keys and raw upstream bodies out of logs.

The change must thread the selected provider through the plan and loop rather than falling back to the OpenAI forward executor: the loop currently dispatches only the Anthropic executor or runWebSearch with a forward provider (src/web-search/loop.ts:653). Add focused tests for provider eligibility, missing/disabled/unresolved credentials, exact Authorization: Bearer request shape, manual redirect handling, SSE text/citation parsing, tool-loop result injection, and confirmation that neither ChatGPT nor Anthropic credentials are selected. Update /api/sidecar-settings, Claude override validation, and the Sidecars documentation, which currently documents only the two existing backends (docs-site/src/content/docs/guides/sidecars.md:11).

This is a valid capability request, but it crosses an outbound credential and third-party hosted-tool trust boundary. It needs a capability-gated design and a real Zen compatibility capture before implementation.

DISPOSITION: ACCEPTED