Scraping API PricesTavily vs Exa
Compare standard web-search requests across Tavily and Exa, with full meters and every computed price boundary.
Tavily
Exa
The difference
Both paths, one ruler
Tavily
Successes you want
100,000 standard searches
Your stated workload. Every vendor on this site is priced against this same number.
- ÷ 1
Attempts you are billed for
100,000 standard searches
Tavily bills failed fetches. This workload assumes none fail, so nothing is added here.
- × 1
What the meter counts
100,000 credits
One attempt is one billed unit for this workload.
- =
Cash per month
$500.00 /mo
Growth. Cheapest of every eligible purchase option, not the first plan that fits.
Bars share one linear scale across the 3 counted stages, so a multiplier shows as length. Units differ by stage and are labelled. Cash is not on that scale.
Exa
Successes you want
100,000 standard searches
Your stated workload. Every vendor on this site is priced against this same number.
- ÷ 1
Attempts you are billed for
100,000 standard searches
Exa bills failed fetches. This workload assumes none fail, so nothing is added here.
- × 1
What the meter counts
100,000 requests
One attempt is one billed unit for this workload.
- =
Metered cash this month
$700.00 /mo
Search. Cheapest of every eligible purchase option, not the first plan that fits.
Bars share one linear scale across the 3 counted stages, so a multiplier shows as length. Units differ by stage and are labelled. Cash is not on that scale.
Both ladders share one linear scale, topping out at 100,000 counted units, so a longer bar means more billed work rather than a different drawing.
These figures are for one stated workload: 100,000 standard search calls with one default-depth result set per call. The comparison below names where the answer changes.
The shared baseline is a standard search request. Tavily’s deeper search path and Exa’s deep modes, extra results, contents, and summaries remain visible as distinct meters.
The checkpoint volumes are workload assumptions. Prices, receipts, verification dates, and every whole-request boundary are computed from the current dataset through the engine, so a plan change updates the verdict without editing this file.