Workload estimator · Checked September 24, 2026
Firecrawl pricing calculator: estimate credits from the work you actually run
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 September 24, 2026
Why a page count is not a budget
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 basic Scrape, Crawl, and Map, 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.
Use the estimator
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.
Estimate your monthly Firecrawl workload
This is a planning model, not a measured bill. Enter requests, not just the number of URLs in your spreadsheet. Enter ordinary and JSON pages separately to avoid double counting. Browser interaction, search, monitoring, and retries use different credit rules. Monitor defaults to a seven-credit assumption because the official page conflicts; change it only after verifying the relevant rate.
Base credits
1,000
Before retry allowance
Planning credits
1,100
Includes 10% retries
Accepted documents
850
At 85% assumed yield
Allowance-only fit
Hobby
$16/month equivalent, billed annually
Current credit rules to put beside your spreadsheet
| 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 | Conflicting: 1 in table; 7 in detailed explanation | Confirm your Monitor mode. The estimator uses an editable seven-credit assumption, not a verified charge. |
| 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. |
The official page distinguishes no-result scrapes from returned error-status pages, which can still be charged. 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.
Four workload examples
Documentation RAG
You ingest 2,000 known documentation pages once a week, with 10% JSON extraction and a 15% retry allowance. Per run, 1,800 ordinary pages use 1,800 credits and 200 JSON pages use 1,000 credits. A 15% retry allowance adds 420 credits to the 2,800-credit base: 3,220 per run, or 12,880 across four runs before embeddings and evaluation. The more important output is how many canonical, current documents enter the index.
Competitive monitoring
You monitor 100 pages every day. That is 3,000 page checks per 30-day month. The conflicting public rates imply 3,000 or 21,000 credits before retries; confirm the selected mode rather than treating either as a verified bill. If only 40 pages change meaningfully, a change-aware workflow may be more economical than treating every check as a full re-ingestion job.
Research agent
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.
JavaScript-heavy site
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 credits, 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.
Five endpoint decisions that change the estimate
Known page or unknown page?
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.
Text or structured fields?
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.
Static request or browser task?
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.
One-time backfill or recurring refresh?
A backfill needs scope and a completion budget. A recurring job needs change detection, freshness policy, deduplication, monitoring, and a reserve for growth.
Prototype or customer-facing system?
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.
Turn the estimate into a reliable production budget
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.
Frequently asked questions
How many Firecrawl credits do I need?
Start with the operations in your workload. The current official pricing page lists basic Scrape, Crawl, and Map 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.
How much does Firecrawl cost per page?
For ordinary basic Scrape, Crawl, and Map 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.
Does Firecrawl charge for failed requests?
The pricing page says a scrape returning no result is free, but a returned error-status page such as 403 or 404 costs one credit. 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.
Do Firecrawl credits roll over?
Firecrawl's pricing FAQ says Free through Growth have no rollover, Scale has one month, and Enterprise is custom. Confirm the current plan terms before buying extra capacity, especially if your workload is seasonal.
Is Firecrawl good for a RAG pipeline?
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.
Should I use Firecrawl Scrape, Crawl, Map, or Agent?
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.