SearXNG vs Exa vs Tavily vs Brave for AI Agent Search

Prism can answer an agent's search tool calls locally. That makes the choice of search provider a real decision rather than an afterthought, because the provider you pick determines cost per session, how often queries silently fail, and how much of the results an agent can actually use.

There are six options in Prism: a managed SearXNG instance, four hosted APIs, and a declarative custom provider for anything else. Here is what each is actually good at.

SearXNG — the free default

SearXNG is a metasearch engine. It does not crawl or index anything itself; it forwards a query to many engines and merges what comes back. Prism runs one locally on 127.0.0.1:8888 and manages its lifecycle.

Exa — neural search for agents

Exa is built for the retrieval pattern language models actually use: give it a natural-language description of what you want, not keywords. Its results tend to be more semantically relevant for a query like "how do people configure X in production" and less useful when you already know the exact page title.

Read its API key from EXA_API_KEY or store it in the config. It is metered, so it is the natural second entry in a fallback chain behind SearXNG rather than the first.

Tavily — search shaped for LLMs

Tavily's selling point is that its response is already in the shape an agent wants: a short answer plus trimmed source content, rather than a page of HTML to strip. That reduces the amount of token-burning cleanup between a search and a usable result.

{
  "search": {
    "active": "searxng",
    "fallback": ["tavily", "exa"],
    "providers": {
      "searxng": { "enabled": true, "base_url": "http://127.0.0.1:8888" },
      "tavily":  { "enabled": true, "api_key": "tvly-..." }
    }
  }
}

Brave — an independent index

Brave runs its own crawl rather than reselling someone else's results, which matters when you want a second opinion that is not correlated with the first. It is a good complement to SearXNG precisely because the underlying index is different.

The key comes from BRAVE_SEARCH_API_KEY. Free tiers exist and are rate-limited, which is exactly the profile of a provider that belongs in a fallback chain.

Serper — Google-shaped results

Serper returns results in the shape Google's own results page has: organic links, answer boxes, related questions. If your agent's prompts were written against Google-shaped output, this keeps that structure. It is an API in front of Google results, with the cost and dependency that implies.

Custom REST — when your provider is missing

Anything with an HTTP search endpoint can be described declaratively, with no code: a URL, a method, where the query and options go, where the results array is in the response, and which fields hold title, URL and content.

{
  "search": {
    "custom_providers": [
      {
        "id": "linkup",
        "name": "Linkup",
        "endpoint": "https://api.linkup.so/v1/search",
        "method": "POST",
        "authHeader": "Authorization",
        "apiKey": "Bearer your-key",
        "resultsJSONPath": "results",
        "fieldMap": { "title": "name", "url": "url", "content": "content" },
        "enabled": true
      }
    ]
  }
}

The URL, params and body support the placeholders {{query}}, {{numResults}}, {{allowedDomains}} and {{blockedDomains}}.

Side by side

The sensible default configuration

Put free search first for volume and a paid provider second for the queries where quality actually changes the outcome. Prism will skip a provider that fails or returns nothing, so the agent never sees the difference.

{
  "search": {
    "active": "searxng",
    "fallback": ["tavily", "brave"],
    "max_per_turn": 5,
    "timeout_ms": 8000,
    "default_num_results": 5
  }
}

Three knobs do most of the tuning: max_per_turn caps how many searches one agent turn may run, timeout_ms bounds each provider, and default_num_results controls context cost — capped at 10 no matter what you set.

Two routes where none of this applies

Prism does not intercept search on Codex OAuth accounts, or on any model marked api: "responses". On those routes the agent uses its own search tool and your provider configuration is irrelevant. That is worth knowing before you spend time tuning a chain that will not be consulted.