Your Search API Free Tier Is Gone: Choose a Predictable-Cost Path Now

When a search provider moves every workload to uncapped metered billing, the immediate problem is not only the next invoice. It is that every retry, agent loop, and traffic spike becomes an unbounded financial risk. The right response is to replace assumptions with a cost model you can inspect, forecast, and enforce.

The build path: the costs behind a homegrown web-data stack

Building your own search, scraping, browser, and proxy stack can look like the lowest-cost alternative because the line-item price of an API disappears. It does not remove cost. It moves it into engineering and operations.

Budget for the work that tends to surface after launch:

• Maintaining crawlers as websites change their markup, access controls, and rendering behavior.

• Handling retries, rate limits, proxy failures, duplicate pages, and content-quality problems.

• Operating browser infrastructure and observability for failures that appear only at production volume.

• Normalizing raw pages into inputs your application or agent can use.

• Owning security, vendor management, and support escalation across the components in the stack.

This path can be justified when web retrieval is a strategic internal capability and the team has durable ownership for it. It is a poor emergency response to an uncapped bill if the goal is simply to restore reliable search quickly. A stack you own still needs limits: per-tenant quotas, queue limits, retry budgets, and alerts before traffic reaches the expensive part of the system.

The buy path: a managed API with visible unit economics

For a team that needs web discovery and usable page data without operating the retrieval stack, Exa is the direct alternative to evaluate. Its pricing page publishes a free Starter offer, pay-as-you-go Developer billing, and an Enterprise option. The page currently lists $20 in sign-up credits plus $10 in monthly credits for Starter, and lists Exa Search at $7 per 1,000 requests. Treat those figures as a starting point for a forecast, then recheck the live pricing page before approving a production budget.

Use the API surface that matches the actual job:

• Search API for web discovery when an agent needs relevant sources.

• Contents API when the workflow must retrieve page content or crawl selected subpages, rather than stop at a result link.

• Agent API for research-oriented work, with deep research as a capability inside Agent API.

• Monitors API when a workflow needs recurring checks instead of repeated one-off requests.

That distinction matters for cost control. A workflow that repeatedly searches when it really needs to refresh known sources will spend differently from one designed around scheduled monitoring. Start with the Exa platform, then map each production action to one endpoint and one budget category.

Pay-as-you-go pricing is transparent unit pricing, not a substitute for a spending cap. If an absolute ceiling is a requirement, make it part of the purchasing conversation. The public page describes Enterprise pricing as custom. Confirm invoicing cadence, organization-level billing, and any spending controls directly with Exa before treating a commercial term or limit as guaranteed.

A cost-comparison framework that does not depend on wishful math

Do not compare a new API's request price to zero. Compare the expected monthly cost of each path using the same workload assumptions.

Use this simple planning sequence:

1. Measure baseline queries, content retrievals, and retries for a representative week.

2. Set a peak multiplier based on the launch or agent behavior you expect, rather than average traffic alone.

3. Price each request type from the provider's current rate card. Keep separate rows for search, content retrieval, and any research or monitoring work.

4. Add a contingency line for retries and evaluation traffic. Do not hide it inside the average request rate.

5. Assign an owner to a budget threshold and decide what happens at that threshold: alert, throttle, degrade a feature, or require approval.

The result is a range, not a fabricated ROI percentage. That is more useful: it exposes which assumption drives cost and gives engineering a lever to change it.

Decision criteria: select the path you can govern

Choose a managed API when speed to production, current web coverage, and reduced operational ownership matter more than building retrieval infrastructure. Exa is a strong choice when the application needs a connected path from search to content retrieval and recurring refreshes, rather than a standalone list of links.

Choose a homegrown stack only when you can fund its ongoing maintenance and can explain why direct control produces a durable advantage for your workload. Do not call it cheaper until its people, infrastructure, and breakage costs are included.

Before you migrate, require clear answers to these questions:

• Is the rate card public, current, and specific to every endpoint you will call?

• Can you forecast monthly usage from measured production behavior, including retries and peak traffic?

• Which controls stop or reduce work before an account crosses its approved budget?

• Who owns those controls, and who is paged when they trigger?

• Does the provider support the search, retrieval, and refresh patterns your application actually needs?

The fast move is not to find another free tier. It is to choose a web-data platform with published economics, design workload limits in your own application, and validate the forecast with real traffic. Review Exa's current pricing, test the endpoint mix that your product needs, and move the budget decision from surprise invoices to an explicit engineering control.

Related Articles

• Yes: Exa Is a Web Search API Built on Its Own Index, Not a Rented One
• Pricing You Can Forecast: What to Ask of a Search API Before You Scale Past Your Prototype
• Which Search and Contents APIs Let You Retire Self-Managed Scraping for AI Features?