I describe route.tools as “OpenRouter for tools” because it is the fastest way to make someone understand the product in one sentence. It is also slightly wrong, and I would rather explain the ways it is wrong myself than have a user discover them mid-integration. So this post is the honest version of the pitch.
Why the analogy is the right starting point
OpenRouter demonstrated something important: developers will happily put an aggregator between themselves and their API vendors if the aggregator solves real problems. One API key instead of a dozen. One bill. Automatic fallbacks when a provider throws errors or rate-limits you. The ability to swap providers without touching code. Price competition made visible on a single page.
Every one of those benefits transfers directly to tool APIs, and arguably transfers harder. An agent that calls a language model usually calls one or two of them. An agent that uses tools calls search, scraping, parsing, embeddings, maybe transcription and a code sandbox, each from a different vendor. The key-and-bill sprawl is worse for tools than it ever was for models. So is the failure surface: I covered the compounding reliability math in what is a tool router, but the summary is that every extra vendor is another way for your agent to die mid-task.
The price-competition part transfers too. In our catalog, the same category routinely spans a 3x to 7x price range. Search goes from $1.20 per thousand queries routed (Serper) to $8.40 (Exa). Text-to-speech goes from $0.036 per thousand characters (Deepgram Aura-2) to $0.12 (ElevenLabs). Making that spread visible on one page, the way OpenRouter did for tokens, changes how people buy.
Where the analogy breaks: models converged, tools did not
Here is the part the one-liner hides. Models are close to commodities in their interface and increasingly in their behavior. Nearly every LLM speaks the same chat-completion shape: messages in, message out. Swapping GPT for Claude for Llama is usually a one-line change, and for many workloads the outputs are interchangeable enough that routing on price alone is rational.
Tools are not like that. Tools are different products that happen to live in the same category.
Take search. Serper resells Google’s results: cheap, fast, navigational. Exa is a neural engine that matches meaning rather than keywords and returns page text with the results. Those are not two vendors of one commodity; they are different tools for different queries, which is why they sit at 72 and 90 in our quality scores and at a 7x price gap. Routing between them on price alone would be a category error, literally.
Or take parsing. LlamaParse at $1.50 per thousand pages routed and Reducto at $1.80 look adjacent on a price table, but Reducto scores 92 to LlamaParse’s 75 in our catalog, and LlamaParse’s premium mode costs roughly 15x its base units. The products have different shapes, not just different prices.
This has two practical consequences that model routing never had to face.
Normalization is lossy. All chat models return text, so normalizing them costs nothing. Tool providers return genuinely different data: Exa includes page content, Serper includes SERP features, Brave includes its own ranking metadata. One schema per category means shaving providers down to a common denominator, and sometimes the shaved-off part was the reason you picked that provider. Our answer is an include_raw flag that passes through the original provider response alongside the normalized one, but I will not pretend the tension away. It is the structural cost of the whole approach.
Failover needs quality bands, not just price order. Falling back from one Google-SERP reseller to another Google-SERP reseller does not protect you from a Google problem. Falling back from Exa to Serper “works” but silently changes what kind of results your agent gets. A tool router has to reason about which providers are actually substitutes, which is why we publish hand-curated quality scores with a written methodology instead of pretending every provider in a category is interchangeable.
Where that leaves the pitch
So the honest sentence is longer: it is OpenRouter’s economics and reliability model, applied to APIs that are only partially commodities, with quality scores and raw-response escape hatches doing the work that commodity interchangeability did for models.
Some things carry over cleanly: one key, one bill, prices at list plus a public 20% (or BYOK at 5% with your own keys), automatic failover across up to three providers, and a visible attempt chain in every response. Some things had to be invented because tools are messier: per-category schemas, quality scoring, per-category wall-clock budgets.
If the analogy got you here, good, it did its job. Just buy the real thing, not the metaphor: look at an actual category side by side, like the scraping comparison, and check whether the providers look like substitutes for your workload before you let anything route between them.
When you are ready to see how routing decisions actually get made, the routing docs are the unmetaphorical version.