Open-Source Tavily Alternatives — What They Actually Do

What "open-source Tavily" actually means

Tavily is a closed-source AI-first search API. "Open-source Tavily" is a question without a single answer because Tavily bundles three things:

1. Web search aggregation — querying Google/Bing/etc. and ranking results.
2. Content extraction — pulling clean markdown or text from result URLs.
3. Optional LLM-grounded answer synthesis — turning results into a synthesized answer.

OSS projects mostly cover (1) and (2). Almost none cover (3) as a built-in service — that's where Tavily's commercial moat is. The matrix below is built around that reality.

Live OSS projects, honest comparison

Project	License	Stars	Architecture	Tavily compat	MCP	Hosting story
fastCRW	AGPL-3.0	new	Rust + bundled search backend	Tavily-style, adapter shim	Yes (search+scrape+crawl+map)	docker compose up
OrioSearch	MIT	~22	Python (FastAPI) + metasearch aggregator + Redis	Yes — explicit drop-in	No	docker compose up --build
agent-search	MIT	~25	Python (FastAPI) + metasearch aggregator	Partial (functional, not byte-shape)	Yes + Tor stack	docker compose up
Vane (was Perplexica)	MIT	34.2k	Chat UI + metasearch aggregator	Tavily as backend (consumer, not replacement)	No	Chat app, not API
A bare metasearch daemon	AGPL-3.0	varies	Aggregator only, no API wrapper	No — results JSON, not a Tavily shape	No	docker compose up, then build the wrapper

The critical reads from this table:

• OrioSearch is the only project that ships explicit Tavily-shape compatibility today. If your priority is byte-level shim-free migration from a Tavily client, that's the path. Trade-off: small project (~22 stars), no MCP, Python.
• fastCRW is Tavily-style — same concepts, renamed fields, adapter required. Trade-off: lower resource cost (Rust), broader API surface (crawl, map), AGPL license.
• agent-search is the MCP-native option — bundles a server for Claude Desktop/Cursor. Trade-off: Python, partial compatibility, optional Tor.
• A bare metasearch daemon is what you run if you want zero wrapper. Trade-off: no API keys, no rate limits, no content extraction, no answer — you build the rest.
• Vane is a chat product, not an API. Listed because it surfaces in search results for this query; if you wanted an OSS Tavily client, this is closer.

Skip list — projects that come up but shouldn't

• Whoogle (benbusby/whoogle-search): final release April 2026. Google's JS-disabled query blocking killed it. Don't deploy.
• SciPhi-AI/agent-search: last release January 2024. Over two years stale. Different from brcrusoe72/agent-search (the active one).
• UnSearch: does not exist. The name floats around in OSS-Tavily discussions but no repo backs it.
• Farfalle (rashadphz/farfalle): chat product, no published releases since launch May 2024, consumes third-party search APIs as a backend rather than replacing them.

How to self-host fastCRW (the 2-minute path)

# Clone
git clone https://github.com/us/crw && cd crw

# Configure
cp .env.example .env
# Edit .env to set CRW_API_TOKEN if you want auth (optional for local)

# Boot
docker compose up --build
# fastCRW (:8080) + search backend + Redis

# Smoke test
curl -X POST http://localhost:8080/v1/search \
  -H "Content-Type: application/json" \
  -d '{"query": "agentic search benchmarks", "limit": 5}'

The compose stack ships the search backend with hardening defaults: read-only rootfs, dropped Linux capabilities, no-new-privileges, memory and PID limits, pinned image tag. The audit trail is in docker-compose.yml and the mounted backend config.

Migrating from Tavily client code

The full Python adapter shim (CrwTavilyShim) is on the Tavily alternative hub. If you're on the OrioSearch path, no shim is needed — it claims explicit Tavily request/response shape, so swap the base URL and you're done. agent-search uses its own endpoint shape (/search, /search/extract); you'll need a thin wrapper.

License notice

fastCRW is AGPL-3.0 (full text). OrioSearch and agent-search are MIT. AGPL has specific requirements for network-deployed modifications to the licensed software; calling the API from your application is not a modification. Consult your own counsel if your organization treats AGPL as a hard blocker.

Where each option breaks

Honest failure modes, by project:

• fastCRW: at high QPS, a self-hosted search backend gets rate-limited by the engines it queries. Mitigation: move to fastCRW Cloud, where upstream rotation is handled.
• OrioSearch: small project, single maintainer, ~22 stars. Long-term maintenance is a real risk.
• agent-search: same scale concern as OrioSearch (~25 stars). Tor stack is cool but adds operational surface area.
• A bare metasearch daemon: no auth, no rate limit, no content extraction. You're building the wrapper. That's the whole reason these other projects exist.
• Vane: not an API. Different product.

Recommended next reads

• Tavily alternative hub — the wider compatibility matrix, hosted plan, pricing math.
• Self-hosted search API — broader devops/security audience, full hardening checklist.
• fastCRW vs Firecrawl and vs SerpAPI — adjacent paid APIs, when they make sense.

Three calls to action

• Deploy OSS now — docker compose up. Quickstart →
• Compare directly — Tavily ↔ fastCRW compatibility matrix
• Skip the ops — hosted plan with the same API surface →