Skip to content
Journal / search

Semantic vs keyword search: routing agent queries to the right tier

Agent search queries split into navigational and conceptual types. Route keyword lookups to cheap SERP APIs and semantic queries to neural search.

Watch the actual search queries an agent fires during a session and a pattern jumps out fast: they are not all the same kind of question. Some are lookups (“anthropic api pricing page”). Some are conceptual (“companies building evaluation tools for multi-agent systems”). The search API market has quietly organized itself around exactly this split, with a cheap keyword tier and an expensive neural tier, and the single most profitable thing you can do to an agent’s search bill is stop sending every query to one of them.

The two tiers, priced

Our search catalog spans a 7x price range, and the tiers explain almost all of it. Routed prices are list plus 20%.

TierProviderRouted per 1k queriesQuality score
Keyword/SERPSerper$1.2072
Keyword/SERPBrave$6.0080
NeuralPerplexity$6.0086
NeuralExa$8.4090

The SERP tier answers queries the way a search engine does: match terms, rank by authority and freshness, return links and snippets. Serper resells Google’s results and is the price floor. Brave runs its own independent index, which matters for failover more than features (two Google-derived APIs can fail for the same upstream reason).

The neural tier embeds your query and matches meaning. Exa is the clearest example: you can hand it a description of what you want (“startups building agent sandboxing”) and get documents that match the concept even when they share no keywords with the query. It also returns page text with results, which can replace a scrape call. I went deep on this in the Exa neural search guide.

A working query taxonomy

Four buckets cover nearly everything an agent asks.

Navigational: the agent wants a specific page it knows exists. “stripe webhook signature docs”, “kubernetes 1.31 changelog”. Keyword tier, always. These queries are exact-match problems, and Google-class term matching solves them at $1.20 per thousand. A neural engine adds nothing except cost.

Factual lookup: a specific answer that lives on some page. “firecrawl rate limits”, “python 3.13 release date”. Still keyword tier. The terms in the question are the terms on the page.

Conceptual: the agent is describing a shape of thing, not naming it. “tools that convert PDFs to markdown preserving tables”, “criticisms of vector databases for agent memory”. This is where keyword search degrades: the good results use different words than the query. Neural tier earns its price here.

Exploratory research: open-ended mapping of a topic, where the agent will read many results and synthesize. Neural tier, and specifically the content-included providers, since getting page text with the results collapses a search-then-scrape loop into one call.

What sending queries to the wrong tier costs

Misrouting downward (semantic query to a SERP API) does not fail loudly, which is what makes it expensive. The agent gets plausible-but-shallow results, decides it needs more, reformulates, searches again, maybe scrapes a few dead ends. You pay for the extra searches, the scrapes, and the model tokens spent reasoning about mediocre results. In my experience the token waste dwarfs the search cost.

Misrouting upward is simpler: it is a straight 7x overpayment. A navigational query answered by Exa at $8.40 per thousand gets you the same link Serper had at $1.20. Do that across an agent fleet firing dozens of searches per session and the delta stops being a rounding error.

Classifying queries in practice

The good news is that classification does not need to be perfect, because the failure modes are asymmetric: misrouting upward wastes money, misrouting downward wastes quality, and both are recoverable. Two approaches work.

Heuristics get you most of the way. Queries containing quoted strings, domain names, product names, or “docs/pricing/changelog”-style tokens are navigational. Long queries phrased as descriptions (“companies that…”, “approaches to…”) are conceptual. A dozen lines of rules will route the obvious 80% correctly.

For the rest, let the model decide. If an LLM is generating the search query anyway, having it also emit an intent tag costs a few tokens. The agent already knows whether it is looking something up or exploring; you just have to ask it to say so.

Then route on the tag. With saved routing preferences this is configuration rather than code: navigational traffic defaults cheapest-first (Serper, with Brave as an independent-index failover), conceptual traffic sorts by quality into the neural tier. One key, two policies, and the split lives where you can change it without a deploy.

The tier map is the takeaway

You do not need my router for any of this. The durable idea is that “search” is two products wearing one name, priced 7x apart, and your agent emits both kinds of query every session. Split them, route them, and re-check the split when your workload changes. My rundown of all six providers we route is in the search API listicle, and the tiering logic applies whichever vendors you pick.

Current prices and quality scores for every search provider, side by side, live on the search API comparison page.