Web Search
Give any model access to real-time web information
Beta
Server tools are currently in beta. The API and behavior may change.
The openrouter:web_search server tool gives any model on OpenRouter access to real-time web information. When the model determines it needs current information, it calls the tool with a search query. OpenRouter executes the search and returns results that the model uses to formulate a grounded, cited response.
How It Works
- You include
{ "type": "openrouter:web_search" }in yourtoolsarray. - Based on the user’s prompt, the model decides whether a web search is needed and generates a search query.
- OpenRouter executes the search using the configured engine (defaults to
auto, which uses native provider search when available or falls back to Exa). - The search results (URLs, titles, and content snippets) are returned to the model.
- The model synthesizes the results into its response. It may search multiple times in a single request if needed.
Quick Start
Configuration
The web search tool accepts optional parameters to customize search behavior:
User Location
Pass an approximate user location to bias search results geographically:
All fields within user_location are optional.
Engine Selection
The web search server tool supports multiple search engines:
auto(default): Uses native search if the provider supports it, otherwise falls back to Exanative: Forces the provider’s built-in web search (falls back to Exa with a warning if the provider doesn’t support it)exa: Uses Exa’s search API, which combines keyword and embeddings-based search. Returns Exa highlights — excerpts drawn from each page that are most relevant to the search query — rather than truncated page text. See the Exa section below.firecrawl: Uses Firecrawl’s search API (BYOK — bring your own key)parallel: Uses Parallel’s search API
Engine Capabilities
* Exa: limit applies per result
** Parallel: limit applies as a total across all results
Exa
OpenRouter requests Exa highlights for each result rather than the text content option. Highlights are extractive excerpts drawn directly from the page that Exa selects as most relevant to the search query, typically yielding higher-quality context per token than truncated page text for agentic web tooling.
By default, Exa selects an adaptive highlight size per query and document — typically ~2,000–4,000 characters per result. To pin a larger fixed per-result budget, set search_context_size, which maps to Exa’s contents.highlights.maxCharacters parameter:
low— 5,000 characters per resultmedium— 15,000 characters per resulthigh— 30,000 characters per result
When search_context_size is omitted, OpenRouter lets Exa pick the highlight size adaptively. The selected excerpts are returned to the model on each result and surfaced to API callers via url_citation annotations. Within a single result, excerpts that come from different parts of the page are separated by Exa’s [...] markers, so the content field of a url_citation annotation may look like:
Firecrawl (BYOK)
Firecrawl uses your own API key. To set it up:
- Go to your OpenRouter plugin settings and select Firecrawl as the web search engine
- Accept the Firecrawl Terms of Service — this creates a Firecrawl account linked to your email
- Your account starts with 10,000 free credits (credits expire after 3 months)
Firecrawl searches use your Firecrawl credits directly — no additional charge from OpenRouter. Firecrawl supports domain filtering (allowed_domains / excluded_domains), but they are mutually exclusive — you cannot use both in the same request.
Parallel
Parallel supports domain filtering and context size control (search_context_size), and uses OpenRouter credits at $0.005 per request. Includes up to 10 results in a request, then $0.001 per additional result.
Domain Filtering
Restrict which domains appear in search results using allowed_domains and excluded_domains:
Controlling Total Results
When the model searches multiple times in a single request, use max_total_results to cap the cumulative number of results:
Once the limit is reached, subsequent search calls return a message telling the model the limit was hit instead of performing another search. This is useful for controlling cost and context window usage in agentic loops.
Works with the Responses API
The web search server tool also works with the Responses API:
Usage Tracking
Web search usage is reported in the response usage object:
The web_search_requests field counts the total number of search queries the model made during the request.
Pricing
All pricing is in addition to standard LLM token costs for processing the search result content.
Migrating from the Web Search Plugin
The web search plugin (plugins: [{ id: "web" }]) and the :online variant are deprecated. Use the openrouter:web_search server tool instead.
The key differences:
Migration example
Next Steps
- Server Tools Overview — Learn about server tools
- Datetime — Get the current date and time
- Tool Calling — Learn about user-defined tool calling