A browser agent can act on a page once it arrives, but many research tasks begin with a goal rather than a URL. Browserbase argues that sending those tasks directly to a search-engine interface wastes a browser session on page rendering and DOM parsing when the desired output is only a list of links.
The scale of that mismatch is visible in Browserbase’s own traffic. It reports 4.5 million requests to google.com through its proxies during one recent billing cycle. Each request represents a browser being used for discovery before the agent starts the work that needs interaction.
Browserbase Search instead returns structured URLs, titles, and optional publication metadata from a stateless API. Its SDK accepts a natural-language query and up to 25 results. A separate search interface also avoids binding retrieval to whichever model provider happens to supply a built-in search tool.
The useful architecture is a three-step escalation policy. Use Search when the agent has a goal but no URL. Use Fetch when a URL is known and only page content is needed. Start a browser when the page requires authentication, clicking, or client-side execution. A workflow can chain all three while quickly rejecting irrelevant pages before allocating browser concurrency.
The product details establish real operating limits: plans below Scale receive 1,000 search calls per month, a rate limit of two calls per second per project, and paid-plan overage listed at $7 per thousand calls at publication time. Production workflows still need retries, service-unavailable handling, and usage monitoring.
For New Runtime, this validates the scarcity rule already used in source monitoring. Cheap structured discovery should precede extraction, and extraction should precede browser automation. Tool choice becomes a deterministic cost and capability decision rather than a model habit.