What is a web search router?
A web search router, also called a search router or a search API router, is a service that sits between an AI application and several search engines. For each query it chooses one engine and forwards the query there. The application holds one key and speaks one format, and the router decides where each search goes: by a rule, by the kind of question, by price, or by which engine is available.
Jevlin can be used as one. Name an engine on a request and the query goes there.
What is SuperSearch?
SuperSearch is not a router, because nothing is chosen. It is a search that asks every engine at once and returns one list: each page appears once, and says which engines found it and where each ranked it. The idea is that search engines disagree far more than people expect, so the way to find a page is to ask all of them.
We think this is its own kind of product. A router gives you access to many engines and one engine's answer. A SuperSearch gives you every engine's answer in one. Jevlin's SuperSearch asks up to six engines today: Exa, Brave, Parallel, Perplexity, Serper and TinyFish.
On 485 questions with a known answer page, the best web search router found that page 57.5% of the time. SuperSearch found it 62.1%.
Web search router vs SuperSearch at a glance
| Web search router | SuperSearch | |
|---|---|---|
| Engines asked per query | One | Several: two to six, set by the tier |
| Who picks the engine | The router, or you | Nobody. All are asked |
| What you receive | One engine's list | One merged list, each page naming the engines that found it |
| Answer page in the top ten | 57.5% with the best engine | 62.1% with four engines |
| When the chosen engine misses | The page is lost | Another engine may still return the page |
| Calls that came back empty | Up to 1.44%, by engine | 0.00% |
| List cost per search | $0.0039 to $0.0070 | $0.0209 with four engines |
| Best when | Cost per answer matters most | A missed page is expensive |
The rest of this page shows what Jevlin ships and how these numbers were measured.
What Jevlin ships
SuperSearch: ask every engine, get one list
This is the default. Send a query and the tier sets how wide it goes: fast asks two or three quick ones, balanced asks four, max asks six.
{"query": "pydantic v2 limit maximum length of a string field",
"tier": "balanced"}Each page in the merged list appears once and names the engines that found it and the rank each gave it. Each engine's own list is in the response too, in the order that engine returned it.
The router: one engine when you want one
The same key and request format reach Exa, Brave, Parallel, Perplexity, Serper and TinyFish one at a time. Name an engine and the query goes there alone:
{"query": "pydantic v2 limit maximum length of a string field",
"tier": "balanced", "providers": ["exa"]}Name two and you get those two, merged. The request fields are on Request options. The router sends to the engines you name; it does not guess one for you per query, and the test below is the reason.
Observability: a receipt for every engine, on every search
Both modes answer in the same shape, and the shape is the point.
This is part of a real response from 10 November 2026, shortened: the other pages, the excerpt text and the end of one URL are omitted.
{
"merged": [
{"url": "https://stackoverflow.com/questions/61326020/...",
"found_by": [
{"provider": "exa", "rank": 4},
{"provider": "brave", "rank": 1},
{"provider": "parallel-search", "rank": 3}],
"votes": 3}
],
"indexes": {"selected": 4, "ok": 4, "by_provider": [
{"provider": "exa", "status": "ok",
"results": 8, "latency_ms": 1719},
{"provider": "brave", "status": "ok",
"results": 8, "latency_ms": 1321},
{"provider": "parallel-search", "status": "ok",
"results": 8, "latency_ms": 3176},
{"provider": "perplexity-search", "status": "ok",
"results": 8, "latency_ms": 1096}
]},
"usage": {"cost_micros": 22000, "latency_ms": 3179}
}You can read off which engines were asked, which answered, how many results each returned and how long each took, what the search cost, and for every page, who found it and where they ranked it. An engine that fails or times out is named in the same list with its status.
For coding agents the record also covers the session. The hooks that Jevlin installs attach a small trace to each search: which session, which turn, and the text the agent wrote just before it searched, with ids hashed before they leave the machine. The platform shows one search as a trace, with a receipt per engine, and one session as a trajectory: the agent's turns in order with each search in its place. So you can ask whether a search was any good, and also whether it moved the agent along. Trajectory observability describes what is recorded and what is not.
Routing without this is a guess you cannot check. With it, the choice between one engine and several becomes something you can measure on your own traffic. What follows is our measurement on ours.
Search router vs SuperSearch: the test
Jevlin sells both and earns more from SuperSearch, so the comparison is on public data with the script published. We took the 485 questions of our public benchmark, each with one known answer page, and the results four engines returned for them on 27 October 2026: Exa, Brave, Parallel and Perplexity. From those recorded results we simulated routers. A simulated router picks one engine per question, and it scores if that engine's first ten results held the answer page. No new searches were made, so every router and the merge are judged on the same day's results.
Each router is one a team could build.
| how the engine is chosen | engines called per search | answer page in the top ten | points behind the four-engine merge |
|---|---|---|---|
| Router, fixed always Exa, the best engine overall | 1 | 57.5% | 4.6 1.4 to 7.7 |
| Router, by kind of question best engine for that kind, chosen on other questions | 1 | 56.4% | 5.6 2.8 to 8.5 |
| Router, trained a classifier reads the query and predicts which engine will hit | 1 | 57.1% | 5.0 2.0 to 7.9 |
| SuperSearch, fast two or three quick engines, merged | 2 to 3 | 60.3% | 1.8 |
| SuperSearch, balanced four engines, merged | 4 | 62.1% | 0 |
The three routers landed within about a point of each other, between 56.4% and 57.5%, and the four-engine merge was 4.6 to 5.6 points ahead of each. None of those intervals reaches zero. The smaller merge, fast, was 2.9 points ahead of the fixed router, and that interval does include zero (-0.5 to 6.3), so on this panel we cannot say fast beats always calling Exa.
Why a smarter search router did not help
Routing is worth something only when the best engine changes from question to question in a way you can see in advance. On this panel it changed, and it could not be seen.
It changed: among questions that any engine answered, no engine was the best choice for even a third of them.
| engine | share of answerable questions where it was the best choice |
|---|---|
| Exa | 31.8% |
| Brave | 25.2% |
| Parallel | 22.3% |
| Perplexity | 20.7% |
It could not be seen from the kind of question. Exa had the highest score in all three kinds, so a router that switches by kind ends up always calling Exa:
| kind of question | Exa | Brave | Parallel | Perplexity |
|---|---|---|---|---|
| Library documentation | 63.5% | 52.7% | 61.9% | 54.4% |
| Vendor API tasks | 50.0% | 18.9% | 18.9% | 36.7% |
| Hard factual questions | 53.5% | 49.9% | 34.9% | 37.5% |
And it could not be seen from the words of the query. The trained router read each query and predicted, for each engine, whether it would find the page. Trained on four fifths of the questions and tested on the rest, it sent 66% of queries to Exa, 17% to Parallel, 16% to Brave and 2% to Perplexity, and scored 57.1%: no better than not routing at all. Which engine happens to have indexed and ranked a given page is mostly not written in the query.
That is the whole case for merging. For 17.7% of questions exactly one of the four engines held the answer page, and the query did not say which.
What happens when a search router picks wrong
The fixed router's engine missed the answer page on 206 of 485 questions (42.5%). For 38.3% of those misses, another engine had the page in its top ten. The router never sees that, because it asked one engine.
A merge asks the other engines on every search, so those pages are in the pool that feeds its list.
When is a search router the better buy?
A router calls one engine and a merge pays for all of them. At the engines' list prices on the day of the test:
| what you call | list cost per search | answer page in the top ten | cost per 1,000 answers found | came back with no results |
|---|---|---|---|---|
| One engine: Exa | $0.0070 | 57.5% | $12.18 | 0.07% |
| One engine: Brave | $0.0050 | 49.1% | $10.17 | 0.09% |
| One engine: Parallel | $0.0039 | 45.1% | $8.74 | 1.44% |
| One engine: Perplexity | $0.0050 | 44.5% | $11.19 | 0.44% |
| SuperSearch, fast | $0.0140 | 60.3% | $23.17 | 0.00% |
| SuperSearch, balanced | $0.0209 | 62.1% | $33.66 | 0.00% |
The four-engine merge found the answer page 4.6 points more often than one engine and cost 3.0 times as much per search. Per answer found it is the most expensive row. If cost per answer is what you are optimising, one engine wins, and a router is a tidy way to call one engine.
A router is also the right tool when:
- Your agent can search again. A second search with different wording recovers much of what a second engine would have.
- You route for reasons other than quality. Sending traffic to whichever engine is up, or cheapest, or allowed for a given customer, is real work that a router does and a merge does not.
- Speed matters more than coverage. A merge waits for its slowest engine unless it is told to stop waiting.
These are list prices of the engines, not what Jevlin charges. Jevlin's prices are on the pricing page.
What SuperSearch gives that routing cannot
A second opinion on every page. Each merged result says which engines found it. In our overlap data, a page that all four engines returned was the answer page 25.3% of the time, and a page only one engine returned was the answer 2.6% of the time. A router returns one engine's list, and every page on it has one vote.
No empty answers. The last column of the cost table is how often a call came back with nothing. One engine did so on 1.44% of calls. The merge never did in 4,365 calls, because another engine answered. A router inherits the failure rate of whichever engine it picked, unless it retries elsewhere, which costs the time it was saving.
Earlier news. On election night, 3 November 2026, we asked six engines every five minutes who had won each of 156 races. Across the 131 races that were called, the line using all engines named the winner a median of 120 minutes after the call, and the best single engine took 140. The record is on the election-night page.
Which should you use?
Use SuperSearch by default. It found the answer page more often than any router we could build, it did not come back empty, and every page it returns carries the evidence of how many engines agreed.
Use Jevlin as a search router when you have measured that one engine is enough for your questions, or when cost per search decides. You keep the same key, the same response format and the same receipts, so you can switch between the two per request and compare them on your own traffic.
Questions
What is a search router?
A search router, also called a web search router or a search API router, is a service that puts one API in front of several search engines and sends each query to one of them. The application keeps one key and one response format, and the router decides which engine handles each search.
Is SuperSearch a web search router?
No. A router chooses an engine, and SuperSearch chooses nothing: it asks every engine and merges the results into one list.
Is Jevlin a web search router?
It can be. Name the engines on a request and Jevlin sends the query only to those engines. Leave them out and you get SuperSearch.
Is SuperSearch better than a web search router?
For finding the right page, yes, on our test. Across 485 questions SuperSearch with four engines found the answer page 62.1% of the time, and the best search router found it 57.5%. A router costs about a third as much per search, so it remains the better buy when cost per answer matters most.
Does the router choose the engine for me?
No. You name the engines, or pick a tier and let SuperSearch ask several. On the test above, routers that chose per query did no better than a fixed engine.
What does observability mean here?
Every response lists each engine asked with its status, result count and latency, the cost of the search, and for each page the engines that found it and their ranks. With the agent hooks installed, each search is also tied to its session and turn.
What is the difference between a search router and a search aggregator?
A router chooses. An aggregator combines. A router's response is one engine's results; an aggregator's is one list built from several engines' results, with duplicates removed. SuperSearch is an aggregator built for programs and agents: it keeps every engine's rank for every page and reports what each engine did.
Can a search router be trained to pick the right engine?
Ours could not, on this panel: it scored 57.1% against 57.5% for a fixed choice. That is one classifier on 485 questions, not a proof. A router trained on far more traffic, or one that reads the first results before deciding, could do better.
Does a model rerank the merged results?
No. The merged order is by how many engines found a page, then by the best rank any engine gave it.
Which is better for deep research?
We have not measured long research tasks, so this is reasoning and not data. A research agent makes many searches and reads many pages, which favours the cheaper call. It also builds on whatever it finds first, which favours not missing the page. The single-search numbers above are the only evidence we can offer.
Data, method and limits
The calls are in the supersearch-tests dataset, CC-BY-4.0. A hit is the question's known answer page, matched by URL after normalisation, in the first ten results. Each question was run three times and figures are means over runs. Intervals are 95%, from a paired bootstrap over questions.
The router by kind of question picks, for each of the three kinds, the engine that scored best on a random half of the questions and is scored on the other half, repeated 200 times. The trained router is a logistic regression per engine on the words of the query and the kind of question, scored on questions it was not trained on (five folds, ten repeats), choosing the engine with the highest predicted chance. The script and its output: router.py and data.json.
The limits: one day, four engines, ten results, 485 questions about developer documentation, vendor APIs and hard facts. The routers are simulated from recorded results, not run live. The trained router is a simple one, and a better one may exist. The answer page is one page, and another may hold the answer too. And Jevlin sells both modes, which is why the data and the script are public.