The new Firecrawl /search - Our most accurate Search API for AI agents.
by•
Search is how AI agents ground themselves in the web, but reading full pages for every query burns tokens fast.
We trained a model that returns the excerpts from each /search result that best answer your query, giving your AI agents highly relevant context from every page.
It outperforms processing full pages while using 10x fewer tokens.
On SimpleQA, AI agents using Firecrawl /search now score 94.7%, higher than any other provider. It's live today on every /search call.


Replies
That side-by-side cost/accuracy comparison thing is exactly the stuff that ends up getting litigated in G2/Capterra reviews later, when prospects are comparing tools and can't just ask you directly. Curious if you've found review platforms actually surface that kind of signal for you, or if it's still mostly direct sales conversations at this stage?
Firecrawl
@thys_beesman great points!! There are definitely trade-offs, however, you can always turn this option off.
That's a solid benchmark score. Does the relevance model retrain continuously or is it a fixed release?
Firecrawl
@dhiraj_patel5 It's fixed for now, but we will retrain in the future.
firecrawl has become the default answer every time someone in the agent space asks "how do i give my agent reliable web access." that kind of organic word of mouth in developer communities is hard to manufacture. the "interact with" part beyond just scraping is where it gets interesting for agentic use cases. filling forms, clicking through flows, handling dynamic content that only renders after javascript executes. curious how the rate limiting and retry logic works when a target site starts throttling requests mid-crawl.
Returning the relevant excerpt instead of making every agent carry the whole page is the practical win. Long agent runs fail in boring ways when context fills with page furniture, so keeping retrieval lean is a reliability feature as much as a token-cost feature.
Returning the relevant excerpt instead of making every agent carry the whole page is the practical win. Long agent runs fail in boring ways when context fills with page furniture, so keeping retrieval lean is a reliability feature as much as a token-cost feature.
The 10x fewer tokens claim is the part that caught my attention. In agent workflows, the expensive failure is often not retrieval itself, but letting the model chew through irrelevant page structure. I’d be curious to see where the relevance model struggles most: tables, long docs, or queries with several equally plausible answers?
94.7% on SimpleQA is impressive. How does the relevance model handle ambiguous queries?
FetchSandbox
The excerpt approach is a clean tradeoff for factual lookups where the signal is usually in one paragraph. Curious how the model handles research queries where the evidence is spread across 3-4 short paragraphs on the same page, or where two sources directly contradict, does it surface multiple excerpts per result, or one best-match per page? That gap is where we've seen agents get confidently wrong answers from snippet-based search.