Don't stop here
Hand-picked guides our readers explore right after this one.
Convert word count to pages by spacing, font, and font size, including 1000 words to pages
Read the guideExpert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideUnlock Google's Gemini with multimodal prompting strategies
Read the guideWorkload estimator · Checked August 13, 2026
Estimate page processing, JSON extraction, search, browser minutes, monitoring, retries, and useful-document yield before you choose a Firecrawl plan.
Michael Okeje
Web data, RAG, and AI tool workflow research · Last updated August 13, 2026
Firecrawl's credit model looks simple until you describe the actual web-data job. The current official pricing page lists 1 credit per page for Scrape, Crawl, Map, and Monitor, 2 credits per 10 Search results, and 2 credits per browser minute for Interact. The extraction documentation adds a separate example for Scrape with JSON mode at 5 credits per page, while Agent has dynamic pricing. Those units are useful, but they describe requests, not the value your application receives.
A responsible estimate therefore has three layers. First, count the operations you expect to run. Second, add the cost of retries, reprocessing, monitoring, and the more expensive endpoints. Third, estimate the useful yield: how many retrieved items become complete, relevant, canonical, current, and acceptable documents. If you skip the third layer, a workload that appears cheap can still produce an expensive knowledge base full of noise.
The calculator above is deliberately transparent. It does not pretend to predict Agent pricing, taxes, advanced feature charges, model costs, embedding, storage, or engineering time. It gives you a planning number you can challenge. Replace its assumptions with measurements from a representative pilot as soon as you have them.
I would use the free allowance to test a mixed sample, not merely to scrape the easiest page on the internet. Include a normal page, a JavaScript-heavy page, a long document, a page with navigation noise, a duplicate route, a page that should be excluded, and a target that fails. Record what the application calls, what Firecrawl returns, how many credits are used, and what a human or evaluator accepts.
Affiliate disclosure: this page contains an affiliate link. If you choose to try Firecrawl through it, GPTPrompts.AI may earn a commission at no extra cost to you. The estimate and recommendations are based on the documented workload rules, not on the affiliate relationship.
Start with a representative month. If you are estimating a one-time backfill, set the recurring monitor checks to zero. If you are planning a RAG refresh, include the pages that will be reprocessed and a realistic retry reserve.
Enter requests, not just the number of URLs in your spreadsheet. JSON mode, browser interaction, search, monitoring, and retries use different credit rules.
Base credits
1,000
Before retry allowance
Planning credits
1,100
Includes 10% retries
Accepted documents
850
At 85% yield
Smallest listed fit
Hobby
$16/month shown yearly
| Operation | Current documented rule | Use it when |
|---|---|---|
| Scrape | 1 per page | Known URL and ordinary page content. Start here when the page is already known. |
| Crawl | 1 per page | Discover and process multiple linked pages under crawl rules. Set scope and limits before launching. |
| Map | 1 per page | Build a page or URL inventory. Treat the result as discovery data before deciding what to scrape. |
| Search | 2 per 10 results | Find results when the URL is not known. Search cost is separate from processing the pages you select. |
| Interact | 2 per browser minute | Use browser interaction when page content requires actions or a rendered session. |
| Monitor | 1 per page/check | Refresh a page or monitored target at a recurring interval. Monthly cost is checks multiplied by pages. |
| JSON mode | 5 per page in current extractor docs | Structured extraction from a known page. Use only where a schema materially helps the workflow. |
| Agent | Dynamic pricing | Autonomous discovery and gathering. Set a maximum credit budget and evaluate the result for completeness. |
Firecrawl's official pricing FAQ says it charges for successful requests, not failed requests. That is helpful, but successful retrieval is not the same as useful output. A successful response can be a duplicate, an old version, a navigation page, a page outside scope, or a document whose fields fail validation. Keep success at the API layer and acceptance at the application layer as separate metrics.
You ingest 2,000 known documentation pages once a week, with 10% JSON extraction and a 15% retry allowance. The ordinary pages are 1,800 credits, JSON pages are 2,000 credits at 5 each, and retries add 570 credits to the 3,800-credit base. That is roughly 4,370 planning credits before embeddings and evaluation. The more important output is how many canonical, current documents enter the index.
You monitor 100 pages every day. At 1 credit per page/check, that is about 3,000 credits per 30-day month before retries or additional extraction. If only 40 pages change meaningfully, a change-aware workflow may be more economical than treating every check as a full re-ingestion job.
You run 50 search batches of 10 results and ask an Agent to find structured information across sources. Search alone is 100 credits; Agent is dynamically priced, so the calculator cannot honestly predict the full cost. Set max credits per run, record sources, and compare accepted findings with a known-answer test set.
You need 300 browser minutes for interactions and scrape 1,000 known pages. The base is 1,600 credits before retries. Browser minutes are often the hidden cost, so test whether ordinary scraping, a direct endpoint, or a single interaction followed by page requests can reduce the session time.
If you are building RAG, the page count is only the beginning. A documentation site may contain versioned routes, language copies, changelogs, navigation pages, generated API references, and duplicate URLs. Decide which versions are authoritative, how a document is identified, how old content is removed, and how the answer cites the source. Firecrawl can normalize retrieval; it cannot decide which policy your assistant should trust.
If you are building monitoring, frequency is the main economic lever. A daily check of every page can be wasteful when only a small set of prices, policies, inventory pages, or competitors changes frequently. Split pages into risk or volatility groups. Check high-change pages often, low-change pages less often, and use a meaningful diff before triggering downstream work.
If you are building an extraction pipeline, define the schema before you estimate volume. A field that looks simple may require page selection, multiple sources, currency normalization, date interpretation, confidence, and a missing-value policy. A structured response that is wrong in a convincing way can be more dangerous than raw Markdown that a reviewer can inspect.
If you are building a research agent, cap the run. Autonomous discovery is valuable when you do not know where the answer lives, but its search path is less predictable than a known URL scrape. Give it a maximum credit budget, require source URLs, preserve the evidence for each field, and test whether it finds the right answer rather than merely returning a full-looking JSON object.
The plan decision should happen after the pilot. Firecrawl currently lists Free at 1,000 credits per month, Hobby at 5,000 pages, Standard at 100,000, Growth at 500,000 credits, and Scale at 1,000,000 credits, with the displayed annual-billing prices changing by plan. The exact plan names and pricing can change. More important, do not choose a plan based on a theoretical maximum. Choose the smallest allowance that covers ordinary demand plus a reserve, then revisit when your accepted-document rate and peak usage are known.
There is also a workload boundary. If the target has an official API, use it when its terms and fields meet the need. If the task is a small one-time extraction from stable HTML, a direct HTTP client and parser may be cheaper and easier to inspect. If the workflow is private, authenticated, or legally sensitive, review access, terms, privacy, and retention before sending content to any managed service. A calculator cannot make an unsuitable collection legitimate.
Known pages favour Scrape or controlled JSON mode. Unknown pages require discovery through Map, Search, Crawl, or Agent. Discovery is a separate cost and quality problem.
Markdown can be enough for retrieval and reading. JSON adds schema value when a downstream database, comparison, or rule depends on stable fields. Do not pay for structured extraction that nobody validates or uses.
A normal request is easier to budget and cache. Browser time is justified when rendering or interaction changes the available content. Test whether you can reduce interaction to a short bootstrap step.
A backfill needs scope and a completion budget. A recurring job needs change detection, freshness policy, deduplication, monitoring, and a reserve for growth.
A prototype can tolerate manual inspection. A production system needs quotas, retries, idempotency, observability, data retention, and a fallback when the provider or source is unavailable.
Count accepted documents, not requested URLs. A page can be successfully retrieved and still be empty, duplicated, irrelevant, stale, or unusable for the downstream task.
Separate discovery from processing. Map or Search can help you find candidates; Scrape, Crawl, or JSON extraction can process the subset that passes your scope and quality rules.
Keep ordinary retrieval separate from high-cost operations. Browser interaction and structured extraction can be valuable, but using them everywhere makes the budget reflect convenience rather than need.
Add a retry reserve without hiding the failure rate. Record the endpoint, URL, status, credits, latency, content length, parser result, and reason for reprocessing.
Cache stable pages and attach a content hash or last-seen timestamp. Reprocessing identical content is a cost and freshness problem, not just an API detail.
Set maximum credits per job and per customer. A broad crawl or autonomous research run should not be able to consume the reserve for a production ingestion pipeline.
Evaluate downstream usefulness. For RAG, test retrieval and citations. For extraction, test field-level accuracy. For monitoring, test alert precision. A low credit bill can still represent an expensive failure.
For a first pilot, I would label every output with its source URL, operation, timestamp, credit usage, content length, and acceptance status. That small ledger lets you calculate the number that matters: how many credits and minutes produce one document your product, analyst, or reviewer can actually use.
Start with the operations in your workload. The current official pricing page lists Scrape, Crawl, Map, and Monitor at 1 credit per page, Search at 2 credits per 10 results, and Interact at 2 credits per browser minute. JSON mode has an additional cost in the current extraction documentation, while Agent has dynamic pricing. Add retries, then estimate how many processed items become useful accepted documents.
For ordinary Scrape, Crawl, Map, and Monitor operations, Firecrawl's pricing page currently lists 1 credit per page. A known page processed with JSON mode is listed in the extraction documentation at 5 credits per page. Browser interaction is time-based at 2 credits per minute. Advanced formats, agent runs, and other features may change the calculation.
Firecrawl's current pricing FAQ says it charges only for successful requests. That does not mean a workflow can ignore failures: retries, incomplete content, duplicates, irrelevant pages, and later reprocessing still affect engineering time and the useful-document yield. Check your usage dashboard and current terms for your endpoint and account.
Firecrawl's pricing FAQ says credits do not roll over on self-serve plans and that rollover is available on Scale and Enterprise plans. Confirm the current plan terms before buying extra capacity, especially if your workload is seasonal.
Firecrawl can be a useful collection and normalization layer for public web content, but it is not the whole RAG system. You still need scope, URL identity, canonicalization, freshness, deletion, chunking, metadata, access control, embeddings, retrieval evaluation, and citations. Estimate cost per accepted and evaluated document, not cost per requested URL.
Use Scrape when you know the page, Map when you need a URL inventory, Crawl when you want to process linked pages within defined rules, and Agent when discovery and multi-step research are central. The narrowest endpoint that solves the job is usually easier to budget and test. Firecrawl's current docs describe Agent as dynamic-priced and the successor to Extract for autonomous discovery.
For the broader product decision, read the Firecrawl review. It covers scrape versus crawl versus agent, RAG quality, self-hosting, alternatives, and who should pay.