[Feature]: Choose the web search provider, with Serply as a second option #459

Activity

1. github-actions commented on Oct 2, 2026

   

   github-actionsbot

   on Oct 2, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for the thorough write-up, and for the Serply disclosure up front — that's genuinely helpful for review. A provider-selectable Web Search slot with Tavily as the default plus one additional adapter is a reasonable, well-bounded direction, and the scope you list matches how the current Tavily integration is already laid out. This reads as an extension of the earlier web-research work (#433, #439) rather than a duplicate.

   What lines up with the current design:

   • The existing integration is already search-only and settings-driven. .changeset/tavily-settings-entry.md describes safe key save/replace/clear with bounded connection testing, applying settings to new runs "without restarting while retaining per-run networking consent and active-run snapshots", and keeping search-only credentials out of the model API service list. A second adapter reuses that same shape — consent, per-run snapshots, and the no-automatic-fallback behavior stay as they are.
   • .changeset/preserve-web-search-settings.md shows web-search opt-in and limits are already preserved across provider/model changes, config imports, image settings, and design-system saves, so an optional webSearch.provider field should ride that same persistence path instead of adding a second one.
   • The adapter is app code over the existing HTTP path — no new shipped dependency, so the permissive-dependency constraint isn't triggered.

   Things worth pinning down before the PR:

   • On-disk config should carry the schemaVersion field (per CLAUDE.md: "Schema-version everything that lives on disk") with 'tavily' as the default, so existing installs migrate with no user action.
   • Repo guidance says to avoid config-driven dispatch "unless we have two real callers" (CLAUDE.md). Shipping both providers at once satisfies that; the two-step split (field with Tavily only first) would land a dispatcher with a single caller. Either ordering is workable — a maintainer may have a preference.
   • Keeping each provider's key strictly in its own slot, with no move or copy on switch, is the right call and matches your proposal.

   Need more info:

   • Should maxCalls, the 1–5 result count, and the 2,000-character snippet cap stay shared across providers, or can they be provider-specific?
   • Will the Serply adapter stay under the same opt-in networking rules as the current search requests, with no new host beyond api.serply.io?
   • Do you want the first PR to include the provider selector and en / zh-CN strings for both providers, or land the selector with Tavily only and add Serply routing in the follow-up?

   ---

   Open-CoDesign Bot