Observed facts: Parallel's announcement says it is now the default provider for Browserbase Search API and Browserbase Agents. It specifies that /v1/search and bb.search.web use Parallel unless another provider is selected, and says provider choice can be set per request. It also identifies fast and advanced search modes. These are the documented changes, not independent measurements.
Mechanism: Browserbase describes a sequence of search for candidate URLs, fetch for page content, and browser sessions for complex pages or actions such as portal login. Search supplies the starting points for later work, so the default can influence retrieval while per-request selection preserves an escape hatch.
Why now: This announcement makes that default concrete across both the Search API and Browserbase Agents, connecting retrieval to the broader browsing workflow.
Implications: Builders using Browserbase can start with Parallel search without separately choosing a provider for each request, while retaining the ability to override it. The announcement's rationale is that better URLs may mean fewer browser sessions and fewer tokens spent on irrelevant pages; it does not substantiate that with comparative results.
Evidence boundary: The source is Parallel's product announcement; it verifies the integration and configuration options, but offers no independent benchmark, measured savings, or customer outcome.
Watch condition: Watch for independent measurements of result relevance, latency, cost, or downstream browser-session use, and for whether Browserbase users retain meaningful provider alternatives.
This is a distinct analytical record because no prior New Runtime analysis record was supplied; the available source supports a specific default-provider change, not a claim of measured performance.