Expert Opinion Your agents search the web dozens of times a day, but do you know which search engine receives those queries? Most providers don't say. Otari lets you keep your model and choose the search backend: ours, your own key, or self-hosted.
From all the people that have their agents searching the web dozens of times a day, very few actually know who is running those searches. Web search is part of the basic toolkit of any agent today; regardless of whether you are interacting through end-user applications (i.e. https://chatgpt.com/, https://claude.ai/, etc), building around the provider APIS, or using a coding harness.
Getting your agents to search the web for you is convenient, but it also hides a decision. Somewhere behind that tool call, a search engine receives your agent's queries: the name of the internal service it is debugging, the customer it is researching, the half-built feature it needs docs for.
Which search engine is it? What can it keep, and for how long? What does it cost per query? Can you change it?
What "default web search" actually means #
None of the three big providers names its search engine in the developer docs. If you dig deep enough you might try to guess it from a subprocessor list, from independent testing, or (most likely) you might never fully know.
You might think things work differently for local inference tools, but the experience is quite similar instead. While llama.cpp keeps search out of the server by design and leaves the choice of engine to you, Ollama's built-in web_search ends at a hosted ollama.com/api/web_search endpoint, and the Ollama team has publicly declined to say which search provider is behind it. LM Studio's sibling agent app Bionic likewise ships a built-in web search, without disclosing their search provider.
Coding agents inherit the same opacity. Claude Code's documentation says it plainly: its WebSearch tool "runs a query against Anthropic's web search backend", and "the search backend is not configurable" (tools reference).
There is nothing deeply sinister here. But it is their choice, made under their contracts, and it can change without your code noticing.
Why it matters #
- Data. Queries can carry internal service names, customer names or unreleased product details. Your data processing agreement is with the model provider; the search engine behind it is a step removed, and zero-data-retention promises don't always reach that far. Anthropic's ZDR page, for example, excludes "data processed by third-party websites, tools, or other integrations" (source ).
- Compliance. Some teams must name every processor that touches user data, or keep processing in a region. That is hard when the engine is not disclosed.
- Quality. Search engines have different indexes, freshness and ranking. The engine decides what your agent reads, and so what it concludes. A research agent and a coding agent may want different ones.
- Cost. Each provider sets its own per-search price, and you pay it on top of tokens with no way to shop around.
- Lock-in. Switch models and you switch search engines too, silently. The same agent, same prompt, can return different sources because the search engine changed.
None of these might be a reason to give up frontier models. They are a reason to stop treating the search engine as part of the model.
Keep the model, choose the search engine #
At mozilla.ai we are building Otari, a platform that sits between your agent and the model provider. This position lets us separate many things the providers bundle together, including the model that reasons over search results, and the engine that produces them.
You can keep Claude, GPT or Gemini, and Otari can run the search on a backend of your choice.
There are three options to pick:
- A provider we run for you. On otari.ai, workspaces can use the search backend otari operates, with no key to manage.
- Your own key. From your own Brave, Exa, Tavily (more providers will come) account. The search is billed to your account under your contract with that provider, and the key stays in the gateway and never reaches the agent. Organization admins can store keys and pin a different one per workspace.
- Your own engine. Point Otari at a self-hosted, SearXNG-compatible endpoint that you fully control.
Your code can keep sending the provider's native web_search tool, and Otari intercepts it: the search runs on your backend, and the response still comes back in the provider's own format (i.e. server_tool_use and web_search_tool_result blocks on Anthropic's Messages API). This matters for clients you don't control, like coding agents.
Control goes beyond which engine runs. You can turn search on or off, cap results, and set allowed or blocked domains.
Every search is counted, priced and logged on the same traces as the model tokens, so you can see what your agents searched for and what it cost on a specific session.
Your agents, your search terms #
Adding a Web search feature to an agent immediately makes any model more useful. Big AI companies learned it early, local inference engines followed soon after. For a real choice-first stack, the logical step is treating the search engine as its own component.
Choose your search tool on purpose, with a contract you signed, at a price you can compare, and with every query on record. Otari allows you to customize this component, as well other parts of your AI stack.
Check otari on GitHub and/or our hosted solution otari.ai