[Feature Request]: Feature request: pluggable web_search backend interface (allow custom/self-provided backends)

[Radu0120]

Component

CLI

Problem statement

web_search is currently hardcoded to Mistral's hosted search. I'd like a documented extension point so users can plug in their own search backend, with Mistral remaining the built-in default.

Motivation

When running vibe against a local model (e.g. via a llama.cpp OpenAI-compatible endpoint), web_search still calls Mistral's cloud. This means:

• A MISTRAL_API_KEY is required even for an otherwise fully-local setup.
• Search is subject to Mistral's account-tier rate limit. I regularly hit: web_search failed: Mistral API error: API error occurred: Status 429.
• Once the cap is hit, the tool is unusable for the rest of the window, and the model tends to retry into it.
• There's no way to route search to a self-hosted or otherwise user-chosen engine (privacy, air-gapped, or simply to avoid the cap).

Current behavior

core/tools/builtins/websearch.py calls the Mistral SDK directly:

response = await client.beta.conversations.start_async(
model=self.config.model, # "mistral-vibe-cli-with-tools"
instructions="Always use the web_search tool to answer queries. ...",
tools=[{"type": "web_search"}],
inputs=args.query,
store=False,
)
WebSearchConfig only exposes timeout and model (which model field selects which Mistral cloud model drives the search, it can't target a non-Mistral engine).

Proposed solution

Expose a backend extension point and select it via config, defaulting to the current Mistral implementation so nothing breaks:

• Define a minimal backend interface: e.g. async def search(query: str) -> WebSearchResult - returning the existing
  WebSearchResult (answer + sources), so all downstream/UI code stays unchanged.
• Refactor the current Mistral logic into the default implementation of that interface.
• Allow a user-provided backend to be selected via config, resolved the same way other user extensions are (consistent with how custom tools / agents / skills are already discovered), e.g.:
  [tools.web_search]
  backend = "mistral" # default; otherwise a user-registered backend id / import path
• Backend-specific settings (URLs, keys, etc.) live under the user's own backend config, not in core.

This keeps the core tool provider-neutral: Mistral ships and maintains only the default backend; anything else is the user's own code behind a stable interface.

Additional context

Happy to open a PR if the approach sounds acceptable. The change is reasonably localized to core/tools/builtins/websearch.py plus the WebSearchConfig schema.