Monitor-driven automation finds its footing

Smarter watching with Firecrawl’s /monitor

Firecrawl shipped what may be the week’s most consequential release: a new /monitor endpoint that flips the usual crawl-scrape-repeat model on its head. Instead of polling entire pages, you describe in plain English what you need to track — a price, a status badge, a table row — and Firecrawl configures the URLs, schema, and schedule itself. The savings are hard to ignore: agents that previously re-ingested full page content can now consume only what actually changed, cutting LLM token usage by up to 90%. For anyone running continuous scraping pipelines, that’s the difference between a viable product and a bankrupting one. The endpoint supports any cadence from every five minutes to custom cron schedules, and surfaces cost upfront so there are no billing surprises. It’s a clear bet that the future of web automation is event-driven, not batch-oriented.

Stagehand adds eyes to extraction

Stagehand made two releases this week, with the headline feature landing in v3.7.0: a new screenshot option on the Extract command. Previously, Stagehand’s extraction logic relied entirely on the page’s DOM and accessibility tree — strong signals, but blind to visual layout. Now you can optionally include a screenshot as input, letting the underlying model reason about positioning, color, and rendered state. This closes a real gap for pages where crucial information exists only in CSS-rendered text, dynamically styled elements, or canvas-based content. The same release also introduced a verifier evaluator backend facade and began publishing evaluation results, hinting at deeper observability for Stagehand’s extraction quality. The following day’s v3.7.1 was quieter, adding only a --version flag to the SEA environment, but that small polish matters for CI workflows that need deterministic version reporting.

Apify SDK tightens run and type rigor

Apify SDK’s 3.4.1 was a targeted patch release, but the fixes address two pain points that compound in production. The run-kwargs forwarding fix means that Actor.start, Actor.call, and Actor.call_task now correctly pass through additional keyword arguments to the underlying run. If you’ve ever had a remote actor silently ignore your maxRetries or memory parameter because it wasn’t being forwarded, this is the fix. Separately, the push_data method’s type annotation was tightened from Any to JsonSerializable, letting type checkers catch malformed data before it reaches Apify’s storage layer. Neither change is flashy, but together they reduce the class of “ran fine locally, broke on the platform” bugs that eat up debugging hours.