# OpenRouter 为所有工具调用模型提供统一的网页搜索与抓取功能

- 来源：OpenRouter：Announcements（RSS）
- 作者：David Bai
- 发布时间：2026-05-07 20:00
- AIHOT 分数：55
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmq29zxqw00gtsloph4fqbdij
- 原文链接：https://openrouter.ai/blog/agentic-web-tools

## 精选理由

OpenRouter 给所有工具调用模型配上了统一的网络搜索和抓取能力，开发者不用再为每个模型单独对接搜索 API，适配成本直线下降。

## AI 摘要

OpenRouter 推出新功能，允许任何工具调用模型自主进行网页搜索并抓取页面内容，支持多种搜索引擎和抓取引擎供选择。

## 正文

Consistent Web Search and Fetch Across Every Model — OpenRouter Blog

Consistent Web Search and Fetch Across Every Model

David Bai · 5/7/2026

On this page

Swap Models Without Swapping Tools

Web Search

Parallel Searches in Agentic Loops

Web Fetch

Migrating From the Web Search Plugin

Introducing openrouter:web_search and openrouter:web_fetch, two new tools that any model can call during a request. When a model decides to use one, OpenRouter executes it server-side and returns the result to the model without requiring any client-side implementation.

Web Search: a tool for agentic search 0 to N times per request, letting the model choose its own queries and timing.

Web Fetch: a tool for retrieving full page content from any URL. Commonly used for pages found during search.

Try it now in the chatroom by clicking the tool icon and read the docs for the API details.

Swap Models Without Swapping Tools

Each model provider has its own built-in web search tool with a different schema. Switch models or providers, and you’re stuck rewriting how you define, configure, and parse search results. You’re also not guaranteed to have the same behaviors available, which can be problematic if you need features like strictly enforced blocked domains.

These new server tools give you one consistent way of enabling search and fetch. Specify {"type": "openrouter:web_search"} once, and the tool definition, invocation, and result format stay identical across all tool-calling models. If you want identical search behavior as well, you can specify a provider like Exa or Parallel so the results coming back to the model are consistent regardless of whether the request routes to GPT-5.5, Claude, or Kimi.

{
"model": "openai/gpt-5.5",
"messages": [{ "role": "user", "content": "What happened in tech news today?" }],
"tools": [
{ "type": "openrouter:web_search" },
{ "type": "openrouter:web_fetch" }
]
}

Web Search

Web search supports four engines:

Engine How it works Pricing

Auto (default) Uses native if the provider supports it, otherwise Exa Varies

Native The provider’s built-in search (OpenAI, Anthropic, Google, xAI, Perplexity) Provider pricing

Exa Passes the search to Exa and bills from your OpenRouter credits $0.005 per request. Includes up to 10 results, then $0.001 per additional result.

Parallel Passes the search to Parallel and bills from your OpenRouter credits $0.005 per request. Includes up to 10 results, then $0.001 per additional result.

Each engine has different strengths. Native search is tightly integrated with the provider’s model. Exa and Parallel add configurable result context size (search_context_size), which native engines ignore. Most engines support domain filtering (allowed_domains, excluded_domains).

You can configure this in the chatroom UI or via the API:

{
"type": "openrouter:web_search",
"parameters": {
"engine": "exa",
"max_results": 5,
"search_context_size": "high",
"allowed_domains": ["arxiv.org", "nature.com"]
}
}

Parallel Searches in Agentic Loops

When a model needs to compare information across sources, it can fire multiple searches in a single request. A question like “compare the pricing of the top 3 cloud GPU providers” might trigger three separate searches, each with different queries, before the model synthesizes an answer.

Use max_total_results to cap cumulative results across all searches in a request. This keeps costs and context usage predictable:

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

Once the cap is hit, the model gets a message saying the limit was reached instead of running another search.

Web Fetch

Web fetch lets models retrieve full page content from URLs and comes with five supported engines.

Engine How it works Pricing

Auto (default) Uses native if supported, otherwise Exa Varies

Native The provider’s built-in fetch Provider pricing

OpenRouter Direct HTTP fetch by OpenRouter Free

Exa Content extraction and clean markdown output $0.001 per fetch

Parallel High-quality content extraction via Parallel’s extract API $0.001 per fetch

Specifying Exa, Parallel, or OpenRouter as the engine ensures consistent fetch behavior across all models, including the ability to restrict which URLs the model can fetch using allowed_domains and blocked_domains. Native provider fetch capabilities vary, so choose one of these engines if you need the parameters to be respected across models.

Use max_content_tokens to cap how much content the model receives (useful for large pages that would eat your context window):

{
"type": "openrouter:web_fetch",
"parameters": {
"engine": "openrouter",
"max_content_tokens": 50000,
"allowed_domains": ["docs.example.com", "api.example.com"],
"blocked_domains": ["internal.example.com"]
}
}

Migrating From the Web Search Plugin

Until now, models could only search through the web search plugin, which ran exactly one search per request regardless of what the model actually needed. The model had no say in when to search, what to search for, or whether to search at all.

To migrate, replace plugins with tools in your request body:

Before (plugin):

"plugins": [{ "id": "web" }] After (server tool):

"tools": [{ "type": "openrouter:web_search" }] Server tools let the model decide when and how often to search. One caveat: server tools require a model that supports tool calling. If your current model doesn’t support tools, you’ll need to switch to one that does or keep using the plugin.

We’ve created a migration guide with full details.