OrioSearch: Your AI Agent need WebSearch

The API mirrors Tavily's /search, /extract, and /tool-schema endpoints, so switching over usually means changing a base URL and clearing the API key. Your existing agent code and response parsing keep working. That compatibility is the whole reason the migration is painless, since a normal API swap means rewriting request builders, response handlers, and error paths before you can ship anything. No rewrites. No new SDK to learn, either.

OrioSearch leans on SearXNG to aggregate results from Google, Bing, DuckDuckGo, and dozens more, with an automatic fallback to DuckDuckGo if SearXNG is unreachable. More sources mean better odds of catching a result a single engine would miss. Which engine actually wins depends on the query, and that's the point of pooling them.

When you point it at a URL, the extraction pipeline uses trafilatura first and falls back to readability-lxml if that fails. It hands back clean markdown or plain text rather than raw HTML. That saves you a parsing step before the content goes into a model. Small thing. It adds up across thousands of pages.

Flip on include_answer: true and OrioSearch synthesizes an answer from the returned results using an OpenAI-compatible model, then attaches sources. You can run it against Ollama locally, or route it to OpenAI or Groq if you'd rather use a hosted model. Your choice. The answer quality tracks whatever model you wire in, so a small local model and a frontier model won't read the same. Pick carefully.

The /search/stream endpoint pushes results over Server-Sent Events as they arrive instead of waiting for the full response. For agents that act on the first useful hit, that shaves real time off each turn. Not a small win when your agent fires dozens of searches per task and each round trip stacks up into minutes of dead waiting.

Redis batches lookups with configurable TTLs and graceful stale-cache fallback, so repeated queries come back fast. On top of that, a small FlashRank ONNX model reranks results by semantic relevance, all on CPU with no PyTorch dependency. No GPU needed. That keeps the footprint small enough to run next to your app on a modest box, so you're not renting a bigger instance just to host the search layer.