Giving a model access to the web used to mean one of two things: lock into a single provider’s built-in search tool, or wire up search and fetch APIs yourself on the client and reconcile a different schema for every provider. OpenRouter’s agentic web tools offer a third path: two server tools, openrouter:web_search and openrouter:web_fetch, that any model can call during a request — searching, reading the pages it finds, and synthesizing an answer on its own.
Two properties make this interesting. Execution: OpenRouter runs the tools server-side and returns results to the model, so your client ships no implementation. Consistency: the tool definition, invocation, and result format stay identical across every tool-calling model — swap models without swapping tools, which is exactly the leverage a routing platform should have.
From Plugin to Agentic Tool: Who Decides to Search
OpenRouter’s earlier web search plugin was passive: it ran exactly one search per request regardless of what the task needed, and the model had no say in timing or query. The new server tools hand that decision back to the model — zero to N searches per request, with queries and timing chosen by the model itself. Asked to compare three cloud GPU vendors, it can fire three separate queries and synthesize. Search count goes from a fixed constant to a model decision, and that is precisely the agentic dividing line.
Server-Side Execution, Zero Client Implementation
Enabling a tool takes one {"type": "openrouter:web_search"} declaration. Switching providers used to mean rewriting tool definitions and result parsers, with no guarantee of behavioral parity — strictly enforced blocked domains, for instance, simply do not exist in some native tools. This abstraction peels tooling capability away from provider differences: if you also need identical behavior, name Exa or Parallel as the engine, and the results reaching the model are the same no matter which model the request routes to.
Web Search: Four Engines and Their Pricing
| Engine | How it works | Pricing |
|---|---|---|
| Auto (default) | Uses native if the provider supports it, otherwise Exa | Varies by engine used |
| Native | The provider’s built-in search | Provider pricing |
| Exa | Search passed to Exa, billed from your OpenRouter credits | $0.005/request (up to 10 results), $0.001 per additional result |
| Parallel | Search passed to Parallel, also billed from credits | $0.005/request (up to 10 results), $0.001 per additional result |
The division of labor: Auto uses native search when the provider supports it and falls back to Exa otherwise. When you need cross-model consistency or predictable billing, name Exa or Parallel — same price, different executor. Only Exa and Parallel honor search_context_size (the size of result context); native engines ignore it. Most engines also support domain filtering through allowed_domains and excluded_domains. The docs example is directly usable: max_results at 5, allowed_domains limited to arxiv.org and nature.com, and search_context_size set to high — a research configuration that reads only academic sources with high context.
Web Fetch: Five Engines, Including a Free One
The typical fetch call chains off a search: the model first finds candidate pages with web_search, then pulls their full content with web_fetch, stringing both tools into one research pipeline inside a single request.
| Engine | How it works | Pricing |
|---|---|---|
| Auto (default) | Uses native if supported, otherwise Exa | Varies by engine used |
| Native | The provider’s built-in fetch | Provider pricing |
| OpenRouter | Direct HTTP fetch by OpenRouter | Free |
| Exa | Content extraction with clean markdown output | $0.001 per fetch |
| Parallel | High-quality extraction via Parallel’s extract API | $0.001 per fetch |
Fetch adds an OpenRouter engine of its own: a direct HTTP fetch priced at Free, which is where cost-sensitive pipelines should start. Exa and Parallel cost $0.001 per fetch and add content extraction and clean markdown. Naming Exa, Parallel, or OpenRouter also makes allowed_domains and blocked_domains work consistently across models — native fetch capabilities vary, so choose one of these three when the parameters must be respected.
The Parameters That Control Cost and Context
The real risk in an agentic loop is not any single charge; it is frequency multiplied by context. Two parameters belong in your defaults. max_total_results caps cumulative results across all searches in a request — once the cap is hit, the model gets a limit-reached message instead of running another search. max_content_tokens (50000 in the docs example) caps how much content the model receives, so one large page cannot eat half your context window. Feel the scale with real numbers: a three-vendor GPU comparison where the model searches once per vendor with max_results at 5 accumulates 15 results; setting max_total_results to 15 locks the task’s marginal search cost in place.
Migrating From the Plugin: One Line and One Red Line
"plugins": [{ "id": "web" }] → "tools": [{ "type": "openrouter:web_search" }]The migration itself is replacing plugins with tools in your request body; OpenRouter’s migration guide covers the full details. The red line is model compatibility: server tools require a model that supports tool calling. Models without tool support stay on the old plugin — with its fixed one-search-per-request behavior.
Trade-offs and Limits
These are server-side tools, so execution is not in your hands: no custom JavaScript, no client-side redirect handling. When max_content_tokens truncates a page, the model sees the truncated version — critical details at the bottom of a long page can be lost. On cost, a model in an agentic loop may search repeatedly; Exa and Parallel are cheap per call, but multiplied by behavior they need monitoring, and native engine pricing is set by the provider, so compare across providers separately. One more practical detail is where the bill lands: Exa and Parallel charges go through OpenRouter credits, so costs sit in one record, while native engine charges land on the provider’s invoice — cost visibility splits across two places.
Builder Guidance
Three starting moves you can apply today. First, validate your pipeline with the OpenRouter fetch engine (Free), then upgrade to Exa’s clean markdown if output quality demands it. Second, set max_total_results and max_content_tokens as defaults so cost and context usage stay predictable. Third, restrict search and fetch to trusted domains with allowed_domains, and use blocked_domains in the other direction to exclude internal hosts — the docs example uses exactly that to block internal.example.com. For an agent you expose to customers, that is also a security boundary. The chatroom’s tool icon enables both tools instantly; the API takes the parameters from the tables above.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.