How OpenRouter gives 400+ models web search with Exa

OpenRouter gives developers one API for hundreds of models across labs, providers, and open-source ecosystems. Teams can switch models without rebuilding auth, rate limits, billing, or usage reporting every time.

When Exa and OpenRouter first worked together, the goal was simple: bring live web data to models that did not have search built in. Exa became the search engine behind that launch. Last year, OpenRouter had powered 2.36M+ search queries with Exa. Today, that number is 73M search queries to date.

OpenRouter's first web-search experience made search available through plugins and online model variants. That gave developers a simple one-shot way to add live web context and proved there was real demand for search-enabled models.

OpenRouter's public rankings show weekly model usage in trillions of tokens, with the leaderboard changing quickly across labs, providers, and open-source ecosystems. Open-source and open-weight model usage has also taken off, giving developers more real choices for cost, latency, and quality.

As model choice expanded, that one-shot search path needed to become more agentic. If a developer is routing between many models, search should travel with them. They should be able to define one tool once, switch models, and keep the same result shape, usage tracking, and citations.

OpenRouter is evolving that plugin-powered search experience into server-side tool calls. Developers can now add tools: [{ type: "openrouter:web_search" }] to a request, and the model can decide when to search, what to search for, and whether it needs to search again.

OpenRouter runs the search on the server and passes URLs, titles, snippets, and citations back to the model. The same tool definition works across supported tool-calling models, so teams can change models without rewriting their web-search integration.

With Exa as an engine option, OpenRouter can give models relevant excerpts instead of dumping long pages into context. Exa selects the passages that match the query, and OpenRouter returns them as cited web context.

That matters more when the model is choosing when to search. It may run more than one query, inspect sources, and combine the results into an answer. Better context per result makes that loop more useful without forcing every developer to build search and retrieval themselves.

OpenRouter turned web search from a model-specific add-on into shared infrastructure across its model marketplace. Developers can keep routing across hundreds of models while giving offline models the same path to fresh web context, citations, and server-side tool usage.