When people ask what I am building, the shortest honest answer is: the thing OpenRouter did for models, but for the tool APIs agents actually call. Models got a router years ago. One key, one API shape, dozens of providers behind it, automatic fallbacks. Tools never got that. If your agent searches the web, scrapes a page, parses a PDF, generates an image, or transcribes audio, you are still signing up for each vendor separately, learning each API’s quirks, and hoping none of them has a bad day while your agent is mid-task.
A tool router is the layer that fixes that. Let me define the category properly, because “router” gets used loosely.
The problem: agents are integration multipliers
A chatbot calls one API. An agent calls many. A single research task might fire a web search, scrape three pages, parse a PDF, and embed the results. Each of those is a different vendor with its own key, its own billing model, its own failure modes, and its own idea of what a response should look like.
That multiplication is the whole problem. Every provider you add makes your agent more capable and less reliable at the same time, because now there is one more service whose outage becomes your outage. I wrote more about that dynamic in why AI agents need failover, but the short version is: single-vendor risk compounds across a chain of tool calls.
What a tool router actually does
A tool router sits between your agent and the providers and does three jobs.
1. Routing
You call one endpoint per category (search, scrape, parse, and so on) and a policy decides which provider serves the request. The useful policies are cheapest, fastest, and best quality. This matters because the price spreads inside a category are large. In our catalog, web search runs from $1.20 per thousand queries (Serper, routed price) up to $8.40 (Exa, routed). Scraping runs from $0.36 per thousand pages (Jina Reader or Spider) to $1.92 (Firecrawl). If your workload does not need the premium tier, cheapest-first routing is free money. If it does, quality-first routing is one line of config, and saved routing preferences let you change the policy later with no code change.
2. Failover
When the chosen provider fails, times out, or returns garbage, the router retries the same request against the next provider in the chain, up to three providers deep in our case. A circuit breaker watches error rates and skips any provider that goes above 30% errors over a five minute window, so your traffic stops hitting a vendor that is actively falling over. Per-request wall-clock budgets cap how long failover is allowed to take (20 seconds for search, up to 330 seconds for video), because an agent waiting forever is its own kind of failure.
3. Normalization
Every provider in a category returns a different response shape. A router flattens those into one schema per category, so swapping Serper for Brave does not mean rewriting your parsing code. Normalization is genuinely lossy at the edges (provider-specific fields do not always survive), and an honest router gives you an escape hatch to see the raw provider response when you need it. But for the 90% case, one schema per category is what makes provider choice a config decision instead of an engineering project.
What it costs, and how to sanity-check one
Routers are middlemen, and middlemen deserve suspicion, so here is the math on ours as a reference point for evaluating any of them. Prices are provider list plus a flat 20% (documented at /docs/pricing), or you can bring your own provider keys and pay a 5% platform fee instead. Every response includes the full routing.attempted chain and the exact price of the call, so nothing is a black box. Quality scores are hand-curated on a 0 to 100 scale and published in an open-source catalog, with the methodology written up rather than implied.
Whatever router you evaluate, ask for those things: a public fee, per-call prices in the response, visible attempt chains, and scores you can audit. A router that hides any of them is asking you to trust routing decisions you cannot inspect.
Who actually needs one
If you call one tool API, rarely, with a human watching, you do not need a router. Sign up with the vendor directly and move on.
The category exists for agents that run unattended, call several tool categories, and cannot afford to hard-fail because one vendor returned a 429. That describes most production agents I see, and almost no prototypes. Start direct, and reach for a router the first time you catch yourself writing a try/except that falls back to a second provider. That try/except is a tool router; it is just a very small one that nobody maintains.
If you want to see what a full category looks like side by side, the search API comparison is generated from the same catalog our router reads, and it is a decent picture of why routing across a category beats marrying one vendor.