← Back to feed

OpenRouter shipped openrouter:web_search and openrouter:web_fetch on May 8 — two server-side tools that any model on the platform can invoke during a request, regardless of which provider the request ultimately routes to.

The structural change: search and fetch execution moves to OpenRouter’s infrastructure, not the client. The model decides when to search; OpenRouter runs it and returns results. Application code specifies the tool once.

The Engine Options

Both tools expose four engine choices.

Web search:

Engine	How it works	Pricing
Auto (default)	Native if provider supports it, otherwise Exa	Varies
Native	Provider’s built-in search (OpenAI, Anthropic, Google, xAI, Perplexity)	Provider pricing
Exa	Routes to Exa, billed from OpenRouter credits	$0.004/result
Parallel	Routes to Parallel, up to 10 results per request	$0.005/req + $0.001/additional result

Web fetch:

Engine	How it works	Pricing
Auto (default)	Native if supported, otherwise Exa	Varies
Native	Provider’s built-in fetch	Provider pricing
OpenRouter	Direct HTTP fetch	Free
Exa	Content extraction with clean markdown output	$0.001/fetch

Exa and OpenRouter engines enforce allowed_domains and blocked_domains parameters. Native provider fetch capabilities vary — those parameters are not guaranteed to be respected.

Multi-Search in a Single Request

The tools support parallel execution: a model can fire multiple searches before synthesizing an answer. A prompt like “compare the pricing of the top 3 cloud GPU providers” might trigger three concurrent searches. The max_total_results parameter caps cumulative result count across all calls within a request, making cost predictable.

{
  "type": "openrouter:web_search",
  "parameters": {
    "max_results": 5,
    "max_total_results": 15
  }
}

max_content_tokens does the same job on the fetch side, preventing large pages from consuming the full context window.

Migration Path

The feature replaces OpenRouter’s prior plugins system. Migration is a field rename: plugins → tools in the request body. Existing plugin configurations translate directly to server tool definitions.

One constraint: server tools require tool-calling support from the underlying model. Models that do not support function calling cannot use the feature.

Why the Engine Choice Matters

Native search is tightly coupled to the provider’s own model behaviour. Exa and Parallel add configurable search_context_size — the amount of content each result returns to the model — which native engines ignore. For developers who need consistent retrieval behaviour across model swaps, specifying Exa or Parallel as the explicit engine preserves that contract even when the underlying model changes.

The Infrastructure Play

OpenRouter’s prior value proposition was model routing: abstract away vendor lock-in, normalise pricing. Adding server-side search execution extends that to capabilities. A developer writing an agentic application can now specify tool behaviour once and get consistent operation whether the request lands on GPT-5.5, Claude, Kimi, or any other model in the fleet.

The pricing arithmetic favours OpenRouter’s economics. At $0.004 per result, a 10-result search is $0.04 — a rounding error relative to frontier model output costs. Usage at scale gives OpenRouter visibility into which queries drive the most downstream inference spend, a data asset with obvious strategic value.