Firecrawl
The Web Data API for AI Agents and Developers
5.0•14 reviews•2.9K followers
The Web Data API for AI Agents and Developers
5.0•14 reviews•2.9K followers
The API to search, scrape, and interact with the web at scale.
This is the 10th launch from Firecrawl. View more
The new Firecrawl /search
Launching today
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.
Free Options
Launch Team
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.
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 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.
94.7% on SimpleQA is impressive. How does the relevance model handle ambiguous queries?
MonoCloud for Startups
Firecrawl has been my default for feeding clean web data to LLMs, so seeing /search get more accurate at 10x fewer tokens is a big deal for anyone running retrieval at scale. One suggestion from the buyer side, put a quality-per-token comparison next to the raw token number. Technical teams evaluate cost and accuracy together, and you have a strong story on both.
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.