Firecrawl launches /monitor webhooks with up to 90% lower token use

• Firecrawl shipped /monitor, a new URL watcher that, according to firecrawl's launch post, lets users describe what to track on a page and notify an AI agent by webhook when that page changes.
• The main product claim in the launch post is change-only ingestion: Firecrawl says monitored pages can use up to 90% fewer LLM tokens because agents only receive deltas instead of reprocessing the full page.
• Firecrawl's own examples in its follow-up post center on monitoring research papers, developer docs, feature announcements, financial filings, government regulations, and competitor pricing.
• The product docs linked in Firecrawl's docs tweet position Monitoring as a web change feed for agents, not just a scraper endpoint you poll manually.

You can watch the product flow in Firecrawl's launch demo, jump straight to the monitoring docs, and Firecrawl's own examples in the use-case list make the target user pretty obvious: teams wiring agents to pages that change often enough to matter, but not often enough to justify constant full-page re-ingestion.

Firecrawl's launch post says the setup is three parts: enter a URL, describe what you want tracked, then let /monitor call a webhook when the site changes. That makes Monitoring look more like a standing trigger for agents than a one-shot crawl job.

The docs link in Firecrawl's thread points to a dedicated Monitoring page, which suggests this shipped as a first-class feature surface rather than a buried parameter on existing crawl APIs.

The sharpest claim in the launch is token reduction. Firecrawl says Monitoring can cut LLM token use by up to 90% by ingesting only what changed on a page, not the entire page on every check.

That matters mechanically because the product couples change detection with webhook delivery. Instead of scheduling repeated scrape, diff, and summarize loops inside an agent stack, Firecrawl is pitching a hosted layer that decides when a page changed first, then forwards the update.

Firecrawl's own examples split neatly into six monitored source types:

• Research papers
• Developer docs
• Feature announcements
• Financial filings
• Government regulations
• Competitor pricing

That list is useful because it shows the intended workload. Firecrawl is aiming at high-value pages with sporadic updates, where the expensive part is not fetching HTML, but repeatedly sending mostly unchanged content back through an LLM.