Browserbase vs Riveter

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Browserbase
   Browserbase✓fullprobed9/10

   A direct probe confirms llms.txt is live at https://docs.browserbase.com/llms.txt returning HTTP 200 with structured agent-oriented content describing the platform, and this is reinforced by extensive agent-oriented docs content across the docs site. missing for 10: no independent third-party confirmation of agents actually consuming/using the llms.txt file in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”

   proof ↗⚑ flag

   Riveter—none0/10

   Direct probes show llms.txt returns 404 and no OpenAPI spec is discoverable at any standard path, and no evidence pack item claims an agent-oriented docs format exists; while MCP integration is mentioned, that's a separate capability from machine-readable docs for pointing an agent at.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Browserbase
   Browserbase✓fullprobed8/10

   Browserbase is explicitly built for programmatic, headless browser sessions accessible via API/SDK, with docs describing scheduling agents to run 'on a schedule or on demand' and spinning up thousands of concurrent sessions — a core CI/automation use case. missing for 10: independent hands-on CI integration examples/case studies and explicit CI-provider (GitHub Actions, etc.) documentation.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter~partialclaimed6/10

   Riveter exposes a full API with SDKs (Go example shown), webhooks for async completion, dry_run/max_credits safety controls, and scheduling for recurring automation — all of which support headless, non-interactive use in a pipeline. However, there is no explicit CI/CD example, GitHub Actions integration, or CLI documentation demonstrating a documented headless workflow. Missing for 10: explicit CI/CD or pipeline integration guide, CLI headless invocation docs, independent confirmation of automated/scripted runs.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Browserbase
   Browserbase✓fullprobed8/10

   Browserbase documents an official MCP server integration allowing agents to connect directly, confirmed by probe evidence at docs.browserbase.com/integrations/mcp/introduction. Missing for 10: independent/hands-on confirmation of MCP server usage and more detail on setup/config beyond the doc link.

   • [probe] “official MCP server documented at https://docs.browserbase.com/integrations/mcp/introduction”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Docs explicitly describe connecting Riveter to Claude, ChatGPT, Cursor, or any MCP-compatible assistant via two connection methods, including a local Node.js-based server option, indicating an official MCP server offering. Missing for 10: no independent/hands-on corroboration of the MCP server working, and no detail on the remote/hosted connection method's implementation.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Browserbase
   Browserbase~partialprobed6/10

   There's a documented official CLI ('browse-cli') referenced in probe evidence, but the pack lacks detailed first-party documentation content (installation, commands, usage examples) or independent/community corroboration of its use. missing for 10: detailed CLI docs/commands, independent hands-on validation, broader community adoption evidence.

   • [probe] “official CLI documented at https://docs.browserbase.com/integrations/skills/browse-cli”

   proof ↗⚑ flag

   Riveter—none0/10

   Evidence shows SDKs (Go), a local MCP server requiring Node.js, and REST API features, but no mention of an official CLI tool for running enrichments or managing the product. The docs and probes (llms.txt, openapi) surface no CLI reference, so this applicable axis is unmet.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Browserbase
   Browserbase✓fullprobed8/10

   Browserbase documents a public API for creating/controlling/observing browser sessions programmatically, with an llms.txt confirming API-key-based agent access, plus SDKs and integrations (MCP, CLI) built on top of it. Missing for 10: a discoverable OpenAPI/swagger spec (probe found only 404s) and independent third-party confirmation of API robustness beyond vendor docs.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”
   • [probe] “official MCP server documented at https://docs.browserbase.com/integrations/mcp/introduction”

   proof ↗⚑ flag

   Riveter~partialprobed6/10

   Docs describe concrete API mechanics (webhook_url, dry_run, max_credits, SDK auth/retry/pagination handling, Go SDK code sample) showing a real documented public API surface for driving runs programmatically, and MCP/remote-server integration is documented. However, probes for a formal machine-readable spec (openapi.json/swagger.json) and llms.txt all returned 404, so there's no discoverable canonical API reference, undermining full 'documented public API' claims. missing for 10: a public OpenAPI/swagger spec or llms.txt confirming a fully machine-readable API contract, independent third-party confirmation of API usage.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of scoped or least-privilege API key/credential issuance; the only relevant probe explicitly states Browserbase uses a single broad API key ('one API key gives your agent everything it needs'), suggesting no fine-grained scoping exists.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's evidence covers a single API key model, credit caps, and dry-run cost estimation, but there is no mention of scoped or least-privilege credentials, per-agent tokens, or permission scoping for agents. missing for 10: scoped/least-privilege credential issuance, per-agent API key scoping, role/permission-based access control.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Browserbase
   Browserbase✓fullprobed8/10

   Browserbase documents official SDKs and APIs for programmatic session control, plus a dedicated 'Stagehand' SDK for browser agents and a TypeScript-first agent framework, backed by extensive first-party docs. Missing for 10: independent/hands-on developer corroboration of SDK quality and a discoverable OpenAPI spec (probe found 404s), which limits confidence beyond vendor docs.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “TypeScript-first agent framework with built-in Browserbase support.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Riveter ships an official Go SDK (riveterhq/riveter-go) with documented client code (riveter.EnrichParams), and docs describe SDK-level handling of auth, retries, long-polling, and pagination, indicating a first-party SDK layer built for AI-native workflows. Missing for 10: confirmation of additional language SDKs (e.g., Python/JS) beyond Go, and independent/hands-on corroboration of SDK reliability.

   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Riveter
   Browserbase—none0/10

   No evidence pack item mentions webhooks or event subscription mechanisms; docs focus on session control, agent frameworks, and scraping but never describe a webhook/event system. This is a fair capability for a browser automation platform (e.g. session status events), so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

   Riveter~partialclaimed6/10

   Riveter supports webhooks by passing a webhook_url when starting a run, with Riveter POSTing results back on run.completed, run.stopped, and run.finished events — a real event-notification mechanism for agentic workflows. However this is scoped to a single run's lifecycle rather than a general subscription model (no persistent webhook registration/management endpoint, no broader event catalog, no signature/security details). Missing for 10: a dedicated webhook subscription/management API, documentation of additional event types beyond run lifecycle, and payload signing/verification details.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Riveter
   Browserbase—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Riveter✓fullclaimed7/10

   Riveter's core enrichment feature fills columns using AI agents, web search/scrape, and other tools to generate insights directly on user data, and search_agent provides ad hoc AI-researched answers within the product. missing for 10: independent/hands-on corroboration of insight quality, no example of proactive/unprompted suggestions (only prompt-driven enrichment), and no dashboard-level 'insights' UI evidence beyond API/SDK docs.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Browserbase
   Browserbase✓fullclaimed7/10

   Docs explicitly describe deploying browser agents 'on a schedule or on demand,' plus session-scaling and monitoring use cases (uptime checks, price/job tracking) that imply persistent background automation. missing for 10: independent/hands-on confirmation of scheduling reliability and details on failure alerting/retry mechanisms.

   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [claimed-docs] “Run agents that click through your product continuously and alert you the moment something breaks.”
   • [claimed-docs] “Track prices, job listings, product changes, and competitor moves as they happen.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”

   proof ↗⚑ flag

   Riveter~partialclaimed6/10

   Riveter supports scheduling projects to run on a cadence ('every minute' for fast-moving data) and webhook notifications on run completion, which enables autonomous background execution without manual triggering. However, there's no evidence of broader automation orchestration (e.g., conditional triggers, chaining multiple actions, or a dedicated automation/workflow builder) beyond scheduled data refresh. Missing for 10: evidence of multi-step autonomous workflows beyond scheduled enrichment refresh, independent/hands-on confirmation that scheduling works reliably in production, and any automation trigger types beyond time-based schedules.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Riveter
   Browserbase—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Riveter~partialclaimed6/10

   Riveter ships an internal 'agent loop' (search_agent, enrichment AI) that autonomously researches, scrapes, and fills data on request, which functions as a built-in AI assistant for delegated research tasks rather than a conversational general-purpose assistant. Missing for 10: evidence of a general chat/task interface for arbitrary delegation, independent hands-on validation, and clarity on how broadly the agent can handle tasks beyond enrichment/search/scrape.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Riveter
   Browserbase~partialprobed6/10

   Browserbase's Stagehand SDK supports 'natural language selectors' for browser actions, and the platform offers MCP server and CLI integrations that let AI agents operate it via natural-language-driven commands rather than raw code. However, this is developer/SDK-mediated natural language (act/extract commands within code) rather than a conversational end-user NL interface, and there's no independent hands-on evidence confirming reliability of the NL selector feature. Missing for 10: independent verification of natural-language selector accuracy, evidence of a direct end-user chat/NL interface (vs SDK-embedded NL), and quality/reliability benchmarks from third parties.

   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “TypeScript-first agent framework with built-in Browserbase support.”
   • [probe] “official MCP server documented at https://docs.browserbase.com/integrations/mcp/introduction”
   • [probe] “official CLI documented at https://docs.browserbase.com/integrations/skills/browse-cli”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Riveter explicitly supports building enrichments from natural-language prompts (riveter-docs-2), offers a search_agent that answers questions in natural language without setup (riveter-docs-5), and can be operated via MCP-compatible AI assistants like Claude, ChatGPT, and Cursor (riveter-docs-9), which is the core mechanism for natural-language control. Missing for 10: independent/hands-on confirmation of NL command reliability, and no evidence of a broader NL command surface beyond enrichment/search (e.g., NL-driven scheduling or config changes).

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

5. ai-native userApply a preset configuration tuned for research agents that returns structured, citable output

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase offers general agent tooling (web search, URL-to-markdown/JSON fetching, session control) but there is no evidence of a dedicated 'research agent' preset or configuration that returns structured, citable output with sources. missing for 10: a documented research-agent preset, citation/source-tracking output format, or structured schema tailored to research tasks.

   • [claimed-docs] “Web search, built for agents. Let your Agent quickly find relevant websites based on a single query.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter offers enrichment, search_agent, and scrape tools with structured outputs, but there is no evidence of a preset/template configuration specifically tuned for research agents or citable output formatting; missing for 10: a named preset or template targeting research-agent workflows, citation/source-attribution formatting in outputs, and any documentation referencing 'research agent' presets.

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Browserbase—none0/10

   Evidence shows general documentation pages (docs.browserbase.com) and feature descriptions, but no mention of an interactive API reference or runnable code examples; a probe for OpenAPI/swagger specs (which typically power such interactive docs) returned 404 on all candidate paths, indicating no such interactive reference is exposed.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence of an interactive API reference or runnable examples; probes for llms.txt and OpenAPI/Swagger specs both returned 404s, and docs snippets are static text/code examples only, not interactive/runnable.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Browserbase—none0/10

   A direct probe for OpenAPI/Swagger spec files at common paths returned 404 across all candidates, indicating no downloadable machine-readable API spec is exposed; docs mention an API but not a spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter—none0/10

   Probes for llms.txt and OpenAPI/swagger spec files all returned 404s, and no documentation mentions a downloadable machine-readable API spec despite having a REST API and SDKs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Riveter
   Browserbase—none0/10

   The evidence describes Browserbase's core browser-session and agent-automation capabilities but contains no mention of a distinct sandbox/staging mode, test API keys, or any mechanism to isolate testing from production data. Since API/dev platforms commonly offer such sandbox environments, the axis is applicable, but nothing in the pack demonstrates it.

   ⚑ flag

   Riveter~partialclaimed4/10

   Riveter offers a dry_run mode that validates a request and returns a credit estimate without creating or charging anything, and a max_credits cap that blocks runs before they execute — both function like a lightweight 'test without side effects' capability. However, there's no explicit documentation of a separate sandbox environment or synthetic/test dataset distinct from production data sources (Riveter always operates against live web/data sources when actually run). Missing for 10: a documented sandbox/staging environment, sample or mock datasets, and explicit guidance on testing enrichments without touching real production data sources.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of API versioning scheme (e.g., v1/v2 paths) or any documented deprecation policy; the OpenAPI spec probe even returned 404s, and no changelog or deprecation notes appear in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; probes for OpenAPI/spec discovery returned 404s, and docs mention SDKs/features but nothing about version numbers or deprecation guarantees. Missing for 10: versioned endpoint scheme (e.g., /v1/), a published deprecation/sunset policy, changelog or migration guides.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

5. data-engineerThe documented rate limit (requests per second or minute) enforced on my API key before throttling kicks in

   weight 3 · round drawn
   Browserbase—none0/10

   No evidence in the pack documents specific API rate limits (requests per second/minute) or throttling behavior for Browserbase API keys; the OpenAPI spec probe even returned 404s, and no docs page addresses rate limiting.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter—none0/10

   There is a mention of SDKs handling retries on 429s, implying rate limiting exists, but no documented numeric rate limit (requests per second/minute) is given anywhere in the evidence pack, and probes for API spec/docs return 404s.

   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

Block evasion

1. ai-native userHave an agent automatically get past a CAPTCHA, login, or form wall without my manual intervention

   weight 2 · round to Browserbase
   Browserbase~partialclaimed6/10

   Vendor docs explicitly claim automatic handling of forms, CAPTCHAs, and logins ('When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled' and 'Your agent logs in, navigates, and pulls data from any website, login walls included'), directly matching the story. However, this is first-party marketing copy without independent hands-on verification or technical detail on CAPTCHA-solving mechanics/success rates, and community evidence is generic praise unrelated to this specific capability. Missing for 10: independent/hands-on confirmation that CAPTCHA bypass works reliably, technical documentation of the anti-bot mechanism, and any real-world case study demonstrating unattended login-wall bypass.

   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”
   • [claimed-docs] “Job applications, vendor portals, government forms. Agents that act on the web, not just read it.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. data-engineerAutomatically retry through a chain of different proxies when anti-bot detection blocks a request

   weight 2 · round drawn
   Browserbase—none0/10

   Evidence shows Browserbase offers CAPTCHA handling, proxy support, and session management generally, but there is no mention of automatic retry chaining across multiple proxies upon anti-bot detection failures.

   ⚑ flag

   Riveter—none0/10

   No evidence of proxy rotation, IP chaining, or anti-bot-specific retry logic; only generic SDK retries for 429s/transient failures are mentioned, which is unrelated to proxy chaining against anti-bot blocks.

   ⚑ flag

3. developerUse an undetected browser mode to bypass sophisticated bot detection systems

   weight 3 · round to Browserbase
   Browserbase~partialclaimed4/10

   Evidence shows Browserbase handles CAPTCHAs and login walls automatically (docs-8, docs-10), which relates to the anti-bot theme, but there is no explicit mention of a dedicated 'undetected'/stealth browser mode, fingerprint spoofing, or claims about bypassing sophisticated bot-detection systems specifically. Missing for 10: explicit stealth/undetected mode documentation, fingerprint randomization details, and independent evidence of successfully evading bot-detection systems like Cloudflare/PerimeterX.

   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence mentions undetected browser mode, bot-detection bypass, proxies, or stealth automation features; Riveter's evidence only covers enrichment, scraping, and search tooling. Missing for 10: any mention of anti-bot/stealth browser capabilities, CAPTCHA handling, or evasion of bot detection.

   ⚑ flag

Proxy rotation

1. developerRequest a proxy from a specific country to get geolocation-appropriate content

   weight 2 · round drawn
   Browserbase—none0/10

   The evidence pack contains no mention of proxy configuration, geolocation targeting, or country-specific proxy selection features—only general session/agent capabilities and unrelated community commentary.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. developerUse premium residential or datacenter proxies to bypass sites that are hard to scrape

   weight 3 · round drawn
   Browserbase—none0/10

   The evidence pack describes browser automation, CAPTCHA handling, login walls, and agent tooling, but contains no mention of residential or datacenter proxy offerings for bypassing anti-bot measures. Since proxy infrastructure is a plausible feature for a browser automation platform, the axis applies, but no evidence supports it.

   ⚑ flag

   Riveter—none0/10

   No evidence mentions proxy support (residential or datacenter) or IP rotation for anti-bot bypass; the docs describe scraping and AI agent interpretation but never address proxy infrastructure.

   ⚑ flag

3. developerRoute requests through a rotating pool of proxy IPs to avoid blocks

   weight 3 · round drawn
   Browserbase—none0/10

   The evidence pack contains no mention of proxy IP support, rotation, or anti-blocking proxy features for Browserbase—only general browser automation, agent, and session capabilities are documented. Since proxy routing is a plausible and common feature for a browser automation platform, its absence here counts as 'none' rather than 'na'.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. developerRoute multiple requests through the same proxy IP using a session identifier to maintain a consistent identity

   weight 2 · round drawn
   Browserbase—none0/10

   Evidence pack contains only generic Browserbase product descriptions and community sentiment; nothing documents sticky-session proxy identity or session-ID-based proxy routing. Missing for 10: any mention of proxy session persistence, sticky IP configuration, or session-identifier-based proxy routing in docs or hands-on reports.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Riveter
   Browserbase✓fullclaimed7/10

   Browserbase explicitly advertises spinning up thousands of concurrent browser sessions to return answers immediately, plus scheduled/on-demand agent deployment and monitoring across many tracked items (prices, listings, competitors), directly matching bulk cross-item automation for AI agents. Missing for 10: independent/hands-on benchmarks validating claimed concurrency at scale, and more detail on rate limits/orchestration patterns for very large batch jobs.

   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Track prices, job listings, product changes, and competitor moves as they happen.”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”

   proof ↗⚑ flag

   Riveter✓fullclaimed8/10

   Riveter's core enrichment model operates on many rows at once (bulk input data with AI-filled columns), supports batch generation from a prompt/spec, scheduling for ongoing refresh, and examples like pulling every dentist from every practice in a city in one request. Missing for 10: independent/hands-on verification of large-scale bulk runs and no explicit documentation of per-run item limits or throughput benchmarks.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Browserbase~partialclaimed4/10

   Browserbase supports scheduled/on-demand agent deployment and continuous monitoring use cases (e.g., alerting on breakage, tracking price/job changes), which implies some event-triggered automation, but there's no documented rule-engine or explicit event-trigger/webhook-condition system for defining 'if X happens, do Y' automation. missing for 10: explicit rule-definition interface, event-trigger/webhook configuration docs, condition-action automation examples, independent verification of trigger-based workflows.

   • [claimed-docs] “Run agents that click through your product continuously and alert you the moment something breaks.”
   • [claimed-docs] “Track prices, job listings, product changes, and competitor moves as they happen.”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”

   proof ↗⚑ flag

   Riveter~partialclaimed4/10

   Riveter supports scheduled refresh of projects (time-based automation) and webhook events (run.completed/stopped/finished) that can notify external systems, giving some automation-on-events capability, but there is no evidence of a rules/condition engine that lets users define arbitrary triggers (e.g., 'if data matches X, then do Y') beyond scheduling and run-completion notifications. missing for 10: conditional rule definitions, event-driven branching logic, multi-condition triggers, and any UI/API for building custom automations beyond schedule+webhook.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Browserbase~partialclaimed6/10

   Docs explicitly mention deploying and running browser agents 'on a schedule or on demand' (browserbase-docs-14), directly supporting recurring job scheduling, but there is no detailed documentation of scheduling syntax, retry/monitoring, or independent hands-on confirmation of this feature working in practice. missing for 10: detailed scheduling API/config docs, independent verification of scheduled job reliability, monitoring/alerting details for scheduled runs.

   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [claimed-docs] “Run agents that click through your product continuously and alert you the moment something breaks.”

   proof ↗⚑ flag

   Riveter~partialclaimed6/10

   Docs state you can 'schedule any project to monitor for changes and keep your data fresh' and refresh as often as every minute, indicating recurring job/workflow scheduling support. However, details are thin — no documentation on schedule configuration (cron-like syntax, timezone, pause/resume), no UI/API endpoint specifics for managing schedules, and no independent or hands-on corroboration. Missing for 10: scheduling API/UI details, configuration options, independent verification of reliability at scale.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Browserbase—none0/10

   No evidence of versioning, review workflows, or rollback capabilities for automations; the docs cover session control, scraping, agent frameworks, and scheduling but nothing about version history or reverting changes to automations.

   ⚑ flag

   Riveter—none0/10

   No evidence of version history, review workflows, or rollback capability for automations/enrichments; the pack only covers run execution, credit control, and data enrichment features. Missing for 10: versioning of automation configs, review/approval workflow, rollback/undo mechanism.

   ⚑ flag

Collaboration

1. developerShare scrapers with teammates and manage organizations and role-based permissions

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack mentions team/organization management, sharing scrapers with teammates, or role-based access control features; all evidence covers browser session automation, agent tooling, and integrations. This is a plausible axis for a dev platform with team accounts, but no supporting documentation or community evidence exists.

   ⚑ flag

   Riveter—none0/10

   No evidence pack items mention team sharing, organizations, workspaces, or role-based access control for Riveter; all evidence covers scraping/enrichment functionality and API mechanics only. Missing for 10: any mention of teams, org management, invites, or RBAC/permissions.

   ⚑ flag

Deployment flexibility

1. developerBuild and deploy custom serverless scraping scripts on the platform without managing my own infrastructure

   weight 2 · round to Browserbase
   Browserbase✓fullprobed7/10

   Browserbase's docs explicitly describe programmatic session creation/control, full browser automation, 30+ starter templates, and deploying/running agents 'on a schedule or on demand' without infrastructure management, directly matching the story of building and deploying custom scraping scripts serverlessly. Missing for 10: independent developer testimonials confirming ease of deploying custom scripts, and detailed docs/tutorials specifically on writing/deploying custom scraping code (vs. general agent framing).

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Start building right away with 30+ ready-made templates.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter~partialclaimed6/10

   Riveter's docs show fully managed, serverless-style capabilities (enrichments, scrapes, quick_search, search_agent) that developers configure via natural-language prompts or structured specs and trigger via API/SDK/webhooks with no server management (riveter-docs-1,2,3,4,5,6,11,12). However, this is closer to configuring built-in AI-driven tools than deploying arbitrary custom scraping code/scripts — there's no evidence of a code-upload or custom-script execution environment. Missing for 10: evidence of arbitrary custom code/script deployment (vs. prompt/spec-based enrichment configuration), and independent confirmation of the serverless execution model.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

2. developerDeploy the scraping service via a Docker container for production use

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase is presented throughout its docs as a hosted, serverless browser API/platform (spin up sessions via API key, no infrastructure to manage) rather than a self-hostable container image; no evidence pack item mentions a Docker image, self-hosted deployment, or on-prem installation. Community discussion even frames a separate open-source project as the alternative for self-hosting, implying Browserbase itself doesn't offer this.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [community] “Discussion positioned BrowserStation explicitly as an open-source alternative to Browserbase, implying users seek self-hosted options instea…”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. developerSelf-host an open-source version of the scraper instead of relying on a hosted cloud service

   weight 2 · round drawn
   Browserbase—none0/10

   All evidence describes Browserbase as a hosted cloud API/platform (session management, agent tooling, MCP, CLI) with no mention of an open-source or self-hostable version; community discussion explicitly frames a separate project (BrowserStation) as 'an open-source alternative to Browserbase,' implying Browserbase itself is not self-hostable.

   • [community] “Discussion positioned BrowserStation explicitly as an open-source alternative to Browserbase, implying users seek self-hosted options instea…”
   • [community] “A commenter's terse reaction ('Cool') to the open-source Browserbase alternative suggests casual approval of having a non-commercial option.”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter is presented as a hosted API/service (with a local MCP connector for client access to the remote service), but there is no evidence of an open-source, self-hostable version of the scraper itself; docs only describe running a local MCP bridge that still relies on the remote API key.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

Integrations

1. developerConnect the scraping API to no-code automation platforms like n8n or Zapier through a prebuilt connector

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of a prebuilt n8n or Zapier connector; the pack shows SDKs, MCP server, CLI, and agent framework integrations but nothing about no-code automation platforms.

   ⚑ flag

   Riveter—none0/10

   No evidence of a prebuilt n8n or Zapier connector; only webhook support and MCP/AI-assistant integrations are documented, which are not no-code automation platform connectors.

   ⚑ flag

Library compatibility

1. developerBuild scrapers using popular open-source automation libraries like Playwright, Puppeteer, Selenium, or Scrapy

   weight 2 · round drawn
   Browserbase—none0/10

   The evidence pack describes Browserbase's own control APIs, agent framework integrations, and web-scraping use cases, but never mentions compatibility or connection methods (e.g., CDP endpoints) for Playwright, Puppeteer, Selenium, or Scrapy specifically.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Migration lock in

1. developerExport my scraped data and job configurations in a portable format to migrate to another provider without lock-in

   weight 3 · round drawn
   Browserbase—none0/10

   No evidence of any export/migration feature for scraped data or job configurations in a portable format; documentation covers session control, agent SDKs, and MCP/CLI integrations but nothing about data portability or avoiding lock-in.

   ⚑ flag

   Riveter—none0/10

   No evidence of any export/portability feature for scraped data or job configs, nor any mention of migration support or standard/open config formats; API docs focus on running enrichments, webhooks, and SDKs, not data portability.

   ⚑ flag

Quickstart

1. developerPublish my custom scraper to a public marketplace and earn revenue when others use it

   weight 1 · round drawn
   Browserbase—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. developerRun a ready-made scraper from a marketplace instead of building one from scratch

   weight 2 · round to Browserbase
   Browserbase~partialclaimed4/10

   Browserbase advertises '30+ ready-made templates' to start building quickly, which is the closest evidence to a marketplace of pre-built scrapers, but this is framed as starter templates for building agents/browser automations rather than a curated marketplace of finished, run-as-is scrapers. Missing for 10: explicit scraper marketplace, evidence of running a template unmodified to scrape a target site, and any community/hands-on account of using a template instead of coding one.

   • [claimed-docs] “Start building right away with 30+ ready-made templates.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. developerStart building immediately using a library of ready-made project templates

   weight 1 · round to Browserbase
   Browserbase✓fullclaimed7/10

   First-party docs explicitly state '30+ ready-made templates' to start building right away, directly matching the story. Quality is capped since there's no independent/hands-on corroboration of the template library's breadth or ease of use. missing for 10: independent verification of template quality/quantity, examples of specific templates or hands-on developer feedback using them.

   • [claimed-docs] “Start building right away with 30+ ready-made templates.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Ai extraction

1. developerExtract structured data from a page using natural language instructions instead of writing selectors

   weight 3 · round to Riveter
   Browserbase~partialclaimed5/10

   Browserbase's ecosystem includes Stagehand, described as 'Natural language selectors, self-healing actions, and caching at scale,' which directly supports natural-language-driven extraction instead of manual selectors, and other docs mention agents 'pulling data from any website.' However, the evidence is thin first-party marketing copy with no concrete extraction API examples, no structured-data-specific documentation, and no independent/hands-on corroboration of extraction quality. Missing for 10: detailed extraction API docs/examples, structured-output schema support details, and independent verification of extraction accuracy.

   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Riveter's core enrichment feature lets developers build extraction jobs from a natural-language prompt with target attributes instead of writing selectors, and AI agents interpret pages semantically so configs survive redesigns, directly matching the story. missing for 10: independent/hands-on verification of extraction accuracy and no live API schema (openapi/llms.txt probes 404) to confirm behavior beyond vendor docs.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ flag

2. developerPass a JSON schema so the API returns structured data matching that schema

   weight 2 · round to Riveter
   Browserbase—none0/10

   Evidence mentions fetching web context and converting URLs into HTML/JSON/markdown, but nothing describes accepting a JSON schema parameter to enforce structured output matching that schema. Missing for 10: any documentation of a schema-based extraction API, parameter naming, or example request/response validating against a user-supplied schema.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter~partialclaimed4/10

   Riveter lets you define enrichments via a natural-language prompt or a 'structured spec' with named attributes/columns (riveter-docs-2, riveter-docs-12), which produces structured output, but there is no documented mechanism for passing an arbitrary JSON Schema that the API validates/returns against. missing for 10: explicit JSON Schema input parameter, schema validation of output, and any example showing schema-conformant responses.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ flag

3. ai-native userHave an LLM read a page and decide what structured fields to pull out without pre-written selectors

   weight 2 · round to Riveter
   Browserbase~partialclaimed6/10

   Browserbase's ecosystem includes Stagehand, described as an SDK with 'natural language selectors, self-healing actions' (browserbase-docs-5) and URL-to-JSON/markdown conversion (browserbase-docs-3), which supports LLM-driven extraction without hardcoded selectors. However, there's no explicit documentation of a schema-based 'extract structured fields' API or example showing an LLM inferring fields dynamically. Missing for 10: a dedicated extraction API/schema example, independent hands-on validation of extraction accuracy without selectors.

   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”

   proof ↗⚑ flag

   Riveter✓fullclaimed8/10

   Docs describe enrichments where AI agents interpret pages and fill arbitrary attribute columns from a natural-language prompt or structured spec (no selectors), with scraping/search tools feeding an AI agent loop that adapts to page structure and redesigns. This directly matches the story of an LLM reading a page and deciding what fields to extract without pre-written selectors. Missing for 10: independent hands-on verification of extraction accuracy and no example showing the LLM's field-selection reasoning in practice.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

4. developerPlug in a local or self-hosted LLM as the extraction backend instead of a cloud-only model

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence that Browserbase allows configuring a local or self-hosted LLM as the extraction backend; all documented extraction features (e.g., Stagehand, web search, URL-to-markdown) reference cloud-based agent tooling with no mention of BYO-model or self-hosted model support.

   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence anywhere in the docs suggests Riveter allows swapping in a local or self-hosted LLM as the extraction engine; the product is presented as a cloud-only enrichment/extraction service with API keys, credits, and hosted agents. Missing for 10: any mention of local model support, self-hosted backend configuration, or BYO-model options.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

Basic scraping

1. developerScrape a web page with a single API call and get its raw HTML back

   weight 3 · round to Browserbase
   Browserbase~partialprobed6/10

   Docs describe a URL-to-content endpoint that can convert any URL into HTML, JSON, or markdown, directly supporting single-call scraping with raw HTML output, but this is framed as 'fetch web context' rather than a dedicated documented scrape API with clear parameters/examples. Missing for 10: explicit API reference/example showing a single call returning raw HTML, independent hands-on verification of output fidelity, and confirmation of an OpenAPI spec (openapi probe returned 404s).

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's scrape endpoint explicitly returns 'easily parseable text' from a URL, not raw HTML — the opposite of what this story asks for, and no evidence shows an option to retrieve unprocessed HTML.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   proof ↗⚑ flag

Data safety

1. data-engineerAutomatically detect and filter personally identifiable information out of scraped content before it reaches storage

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of any PII detection, redaction, or filtering capability in Browserbase's docs or community sources; the product focuses on browser session control, automation, and data extraction infrastructure without mentioning content sanitization or privacy filtering before storage.

   ⚑ flag

   Riveter—none0/10

   No evidence anywhere in the pack mentions PII detection, filtering, redaction, or compliance controls for scraped/enriched data; Riveter's documented features cover scraping, enrichment, search, and workflow orchestration but nothing about identifying or removing personal data before storage.

   ⚑ flag

Document extraction

1. data-engineerExtract text content from PDFs, Word, Excel, and PowerPoint files without hosting them myself

   weight 2 · round to Riveter
   Browserbase—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Riveter~partialclaimed4/10

   Riveter is delivered as a hosted API/SaaS (no self-hosting required) and docs state it 'reads PDFs and images' as part of enrichment workflows, but there is no evidence it extracts text from Word, Excel, or PowerPoint files specifically. missing for 10: explicit support for .docx/.xlsx/.pptx extraction, any extraction-quality benchmarks or examples for Office file formats.

   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

Multimodal extraction

1. ai-native userGet automatic captions for images on a page so a text-only model can reason about visual content

   weight 2 · round to Riveter
   Browserbase—none0/10

   No evidence Browserbase provides automatic image captioning/alt-text generation for text-only model reasoning; docs mention browser control, scraping, markdown/HTML/JSON extraction but nothing about vision-to-text captioning of images.

   ⚑ flag

   Riveter~partialclaimed3/10

   Riveter's docs mention it 'reads PDFs and images' and combines results with web data (riveter-docs-18), implying some visual-content ingestion, but there is no explicit description of generating captions or text descriptions of images for downstream reasoning by a text-only model. Missing for 10: explicit captioning/description output format, example enrichment showing image-to-text extraction, and any confirmation this text is usable standalone by a text-only model.

   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

Search integration

1. developerSearch the web and get full page content from results in a single call instead of just links and snippets

   weight 3 · round to Browserbase
   Browserbase~partialclaimed5/10

   Browserbase separately advertises a 'Web search' tool for finding relevant URLs (docs-2) and a distinct 'Contents' tool to convert a URL into HTML/JSON/markdown (docs-3), but the evidence never shows these unified into a single call that returns full page content directly from search results. Missing for 10: documentation of a combined search+extract endpoint, example code showing one call returning both links and full content, and independent verification of extraction quality/accuracy.

   • [claimed-docs] “Web search, built for agents. Let your Agent quickly find relevant websites based on a single query.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's quick_search explicitly returns only urls, titles, and snippets (not full page content), and its scrape tool requires a specific URL rather than combining search+content in one call. search_agent returns a single synthesized answer, not full page content per search result, so no evidenced single-call capability matches the story's exact requirement.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”

   proof ↗⚑ flag

Selector extraction

1. developerExtract specific fields from a page using CSS or XPath selector rules

   weight 3 · round drawn
   Browserbase—none0/10

   Browserbase's evidence describes full browser control, natural-language selectors, and general data extraction, but nothing explicitly confirms support for CSS or XPath selector-based field extraction. Missing for 10: explicit documentation or example of CSS/XPath selector usage for extraction, API reference showing selector parameters.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “The SDK for browser agents. Natural language selectors, self-healing actions, and caching at scale.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's docs describe AI-driven page interpretation and scraping (turning URLs into parseable text, agents reading pages 'the way a person would') rather than CSS/XPath selector rules; no evidence pack item mentions selector-based extraction at all, and one item explicitly frames the AI approach as an alternative to fragile configuration that would break on redesign, which is the kind of setup selectors typically require.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”

   proof ↗⚑ flag

Structured data handling

1. data-engineerExtract data from very large tables using intelligent chunking so it fits within processing limits

   weight 1 · round drawn
   Browserbase—none0/10

   Browserbase's evidence covers browser session infrastructure, agent tooling, scraping, and automation, but there is no mention of intelligent chunking of large tables or any mechanism to fit extracted data within processing/context limits.

   ⚑ flag

   Riveter—none0/10

   Riveter's evidence covers enrichment, scraping, search, and workflow automation, but there is no mention of chunking large tables, row batching, pagination for extraction limits, or handling of very large datasets to fit processing constraints. missing for 10: any mention of chunking strategy, table size limits, batching large extractions, or row-splitting logic.

   ⚑ flag

Headless rendering

1. developerRender JavaScript-heavy single-page applications and get the fully rendered HTML

   weight 3 · round to Browserbase
   Browserbase✓fullclaimed7/10

   Browserbase runs real browser sessions (docs-1, docs-4) and explicitly offers converting any URL into HTML/JSON/markdown (docs-3), which requires rendering JS-heavy pages in a real browser before extraction—directly matching the story. Missing for 10: explicit mention of SPA-specific rendering guarantees and independent hands-on verification of rendered HTML fidelity.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter is a data-enrichment/scraping/AI-agent tool focused on turning URLs into text and filling data columns; there is no evidence it renders JS-heavy SPAs into fully rendered HTML (e.g., headless browser rendering, DOM snapshot output). The 'scrape' feature converts URLs to 'easily parseable text', not full rendered HTML, so this capability is unevidenced.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   proof ↗⚑ flag

2. developerHave the API wait for a specific selector to appear before returning the rendered page

   weight 2 · round to Browserbase
   Browserbase~partialclaimed3/10

   Browserbase docs mention 'auto-waits' as part of full browser control (docs-4), implying the underlying Playwright/Puppeteer session supports waiting for elements, but no explicit documentation of a selector-wait API or parameter is provided. Missing for 10: explicit API/parameter documentation for waiting on a specific selector, code examples, and independent confirmation of this exact behavior.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Interactive automation

1. developerAccess a managed remote browser sandbox for interactive, manual browsing workflows

   weight 2 · round to Browserbase
   Browserbase~partialprobed5/10

   Browserbase clearly provides managed remote browser sessions that can be created, controlled and observed via API (browserbase-docs-1, browserbase-docs-4), and a CLI/skill integration exists (browserbase-probe-4) that could support manual, interactive use. However, the evidence is overwhelmingly focused on programmatic/agent-driven automation rather than a human-in-the-loop, manual browsing experience (e.g., a live-view iframe or interactive debugger), which is never explicitly documented. Missing for 10: explicit documentation of a live/interactive session viewer for manual human browsing, and independent corroboration that developers actually use it for hands-on manual sessions rather than purely automated agent tasks.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [probe] “official CLI documented at https://docs.browserbase.com/integrations/skills/browse-cli”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. developerKeep interacting with an already-scraped page, clicking and filling forms to reach content behind a login wall

   weight 2 · round to Browserbase
   Browserbase✓fullclaimed7/10

   Browserbase provides persistent programmatic sessions with full browser control (auto-waits, network interception, multi-tab), and docs explicitly describe agents logging in, navigating, and pulling data behind login walls, with forms/CAPTCHAs/logins handled. This directly supports interacting further with an already-scraped page to reach gated content. Missing for 10: independent hands-on verification of session persistence across multi-step interactions and concrete code examples showing continued interaction post-scrape.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”
   • [claimed-docs] “Job applications, vendor portals, government forms. Agents that act on the web, not just read it.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. developerScript page interactions like clicking, filling inputs, and scrolling before content is returned

   weight 3 · round to Browserbase
   Browserbase~partialclaimed7/10

   Browserbase's docs describe full programmatic browser control—auto-waits, network interception, multi-tab support, and agents that log in, fill forms, and navigate pages—implying developers can script click/fill/scroll actions before returning content, and it integrates with frameworks like Playwright/Stagehand for such control. However, the evidence pack lacks explicit code examples or docs naming click/fill/scroll actions directly, and there's no independent hands-on confirmation of these specific interactions. missing for 10: explicit API/code snippets demonstrating click, fill, and scroll actions; independent developer corroboration of these specific interactions.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Render configuration

1. developerControl the browser viewport width and height when rendering a page

   weight 1 · round drawn
   Browserbase—none0/10

   The evidence pack contains no documentation or mention of session creation parameters such as viewport width/height, browser dimensions, or rendering resolution controls; it only covers general browser control, agent frameworks, and integrations. Missing for 10: any docs page, API parameter, or example showing viewport configuration during session creation.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Session persistence

1. developerPass my own session cookies so the API fetches pages requiring authentication

   weight 2 · round drawn
   Browserbase—none0/10

   Evidence shows Browserbase can handle logins, CAPTCHAs, and full browser control (network interception, multi-tab) but never mentions a documented API/param for developers to inject their own session cookies to bypass authentication. Missing for 10: explicit cookie-injection/session-context API docs, code sample showing custom cookies passed to a session, and independent confirmation it works for authenticated fetches.

   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence in the pack mentions passing custom session cookies, auth headers, or cookie jars for scraping/enrichment requests; the docs describe scrapes, quick_search, and enrichments but not authenticated-page access via user-supplied cookies.

   ⚑ flag

2. developerReuse a persistent browser profile with saved cookies and login state across multiple requests

   weight 2 · round drawn
   Browserbase—none0/10

   The evidence pack contains no mention of persistent browser profiles, contexts, or reusable cookie/login state across sessions—only generic mentions of handling logins/login walls during a single session (browserbase-docs-8, browserbase-docs-10). No documentation of a profile/context object, storage of cookies, or reuse across multiple requests is present. missing for 10: any mention of a persistent context/profile object, cookie storage/reuse mechanism, or documentation showing login state persisting across separate sessions.

   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence Riveter offers persistent browser profiles, saved cookies, or login-state reuse across requests; its scraping is described as AI-agent page interpretation, not a session/profile management feature.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Browserbase
   Browserbase~partialprobed6/10

   Browserbase is fundamentally API-first ('one API key gives your agent everything it needs') with docs showing session creation, control, and observability programmatically, suggesting the dashboard largely mirrors API capabilities rather than gating features behind UI-only workflows. However, there is no explicit documentation stating full UI/API parity, and the openapi spec probe returned 404s at all candidate locations, undermining confidence that a complete, discoverable API surface matches every UI capability. Missing for 10: explicit UI/API parity documentation, a public OpenAPI spec, and independent confirmation that no dashboard-only features exist.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browserbase.com/openapi.json, https://docs.browserbase.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   Riveter~partialprobed5/10

   Docs show many core capabilities (building enrichments via prompt/spec, scraping, quick_search, search_agent, webhooks, dry_run) are all API-accessible, suggesting broad parity, but there is no explicit statement of full UI/API parity and some UI-highlighted features like scheduling refresh (riveter-docs-13, riveter-docs-17) aren't confirmed as API-exposed. Additionally, probes show no discoverable OpenAPI spec (riveter-probe-2) or llms.txt (riveter-probe-1), undermining confidence that the API surface is fully documented/openly specified. missing for 10: explicit parity statement, API access to scheduling/monitoring feature, published OpenAPI spec for verification.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Browserbase—none0/10

   No evidence of any data export feature, open-format download, or account portability tooling in Browserbase's docs; the only related community signal is that users seeking self-hosted/open alternatives turn to a separate third-party project (BrowserStation), not an export path from Browserbase itself.

   • [community] “Discussion positioned BrowserStation explicitly as an open-source alternative to Browserbase, implying users seek self-hosted options instea…”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence of any data export feature or open-format export capability; the evidence only covers enrichment, scraping, search, and API integration features, with no mention of exporting data or portability guarantees. missing for 10: export functionality documentation, supported open formats (CSV/JSON/etc), any data-portability or account-closure workflow.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence Browserbase source code is available under any open license; documentation only describes hosted API/SDK features. Community discussion explicitly frames another project (BrowserStation) as 'an open-source alternative to Browserbase', implying Browserbase itself is closed-source/proprietary.

   • [community] “Discussion positioned BrowserStation explicitly as an open-source alternative to Browserbase, implying users seek self-hosted options instea…”
   • [community] “A commenter's terse reaction ('Cool') to the open-source Browserbase alternative suggests casual approval of having a non-commercial option.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Browserbase—none0/10

   Browserbase is offered exclusively as a hosted cloud API/service; no docs or product pages mention a self-hosted or on-prem deployment option. Community evidence even points to a separate open-source project (BrowserStation) as the self-hosted alternative, underscoring that Browserbase itself cannot be self-hosted.

   • [community] “Discussion positioned BrowserStation explicitly as an open-source alternative to Browserbase, implying users seek self-hosted options instea…”
   • [community] “A commenter's terse reaction ('Cool') to the open-source Browserbase alternative suggests casual approval of having a non-commercial option.”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter is presented as a hosted API/SaaS product (with local MCP server option only for connecting AI clients, not for self-hosting the core enrichment engine); no evidence of open-source code, self-hosting instructions, or a downloadable core product exists in the pack.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

Content formats

1. developerReceive scraped content as clean markdown instead of raw HTML

   weight 3 · round to Browserbase
   Browserbase~partialclaimed6/10

   Browserbase's URL-fetch/context tool explicitly supports converting any URL into HTML, JSON, or markdown, directly enabling clean markdown output instead of raw HTML. However, evidence is limited to a single doc snippet with no detail on markdown fidelity, cleaning quality, or independent validation. Missing for 10: detailed docs/examples showing markdown extraction quality, independent/hands-on confirmation of clean output, and coverage across the main scraping API (not just the URL-context tool).

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Docs state a scrape 'turns a URL into easily parseable text,' implying cleaned output rather than raw HTML, but there's no explicit mention of markdown formatting or output schema. Missing for 10: explicit confirmation that scrape output is markdown-formatted, example output showing markdown structure, independent verification of output cleanliness.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   proof ↗⚑ flag

2. developerChoose exactly which output format is returned, such as markdown, HTML, text, or frontmatter

   weight 2 · round to Browserbase
   Browserbase~partialclaimed5/10

   Browserbase's URL-to-context tool explicitly converts pages into HTML, JSON, or markdown, showing some format choice, but there is no evidence of a full selectable set including plain text or frontmatter, nor documentation of a unified output-format parameter across its APIs. missing for 10: explicit text/frontmatter options, unified API-level format parameter documentation, independent confirmation of format selection.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's evidence pack covers enrichment, scraping, search, webhooks, and credit controls but never mentions selectable output formats like markdown, HTML, text, or frontmatter for returned data.

   ⚑ flag

3. developerReceive scraped content as structured JSON

   weight 3 · round to Riveter
   Browserbase~partialclaimed5/10

   Docs mention converting URLs into HTML, JSON, or markdown (browserbase-docs-3), which directly supports structured JSON output for scraped content, but there's no detailed schema documentation, examples of JSON output format, or independent verification of this capability. missing for 10: detailed JSON schema/response examples, API reference documentation, independent hands-on confirmation of JSON output quality.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Riveter's enrichments and scrapes explicitly return structured, parseable data (columns, urls/titles/snippets, webhook payloads of 'full results'), and SDK examples show structured attribute objects returned from calls, indicating outputs are consumable as structured JSON rather than raw text. missing for 10: an explicit statement of JSON schema/response format in docs, and independent/hands-on confirmation of the JSON structure (API docs endpoints 404 in probes).

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

Llm ready output

1. ai-native userGet clean LLM-ready text directly instead of dealing with blocking, rendering, and messy HTML myself

   weight 3 · round to Browserbase
   Browserbase✓fullprobed7/10

   Browserbase explicitly offers a URL-to-content conversion feature that outputs HTML, JSON, or markdown, directly targeting the LLM-ready text use case, and provides an llms.txt for agent consumption. This clearly addresses avoiding messy HTML/rendering, though there's no independent hands-on validation of output cleanliness or completeness. Missing for 10: independent/third-party verification of extraction quality, and more detail on how CAPTCHA/login-walled content is cleaned before conversion.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browserbase.com/llms.txt # Browserbase Documentation > Browserbase is the Browser Agent Platform: …”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Docs claim a scrape converts any URL into 'easily parseable text' and that AI agents interpret pages 'the way a person would', directly addressing the ask for clean, LLM-ready text instead of raw HTML. However, all evidence is vendor documentation with no independent hands-on verification of output cleanliness, no example output shown, and no explicit mention of handling JS rendering/blocking obstacles beyond the general claim. Missing for 10: independent corroboration of scrape text quality, concrete example output, and explicit handling of anti-bot/rendering blockers.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”

   proof ↗⚑ flag

2. ai-native userRequest semantically chunked output instead of one large content blob, so it feeds cleanly into a retrieval pipeline

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase's docs mention converting URLs into HTML/JSON/markdown (browserbase-docs-3) but there is no evidence of a semantic-chunking output mode or configurable chunk size for retrieval pipelines specifically.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter—none0/10

   Riveter's evidence describes enrichments, scrapes, searches, and structured row outputs, but nothing indicates a semantic-chunking output mode designed for retrieval pipelines (e.g., configurable chunk size/overlap, chunk metadata). Structured rows/columns are not the same as semantic chunking for RAG ingestion, and no such feature is documented.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”

   proof ↗⚑ flag

Visual capture

1. developerCapture a screenshot of a full page or a specific selected area

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase's evidence pack covers session control, web search, data extraction, and agent tooling, but nothing explicitly documents full-page or selector-based screenshot capture. Missing for 10: any documentation or docs snippet referencing screenshot/image capture APIs, selector-based capture options, or hands-on confirmation of this output format.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Cost optimization

1. developerLet the API automatically pick the cheapest configuration that still succeeds

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack indicates any feature for automatic cost-optimized configuration selection; Browserbase docs focus on session control, agent tooling, and scaling but never mention cost-aware auto-selection of configurations.

   ⚑ flag

   Riveter—none0/10

   Riveter offers cost controls like dry_run estimates and max_credits caps that refuse overpriced requests, but there is no evidence the API automatically searches for or selects the cheapest configuration that still succeeds — it only estimates/caps, it doesn't auto-optimize. Missing for 10: any documentation of automatic configuration search/optimization for cost, fallback logic that retries cheaper options, or an API parameter that lets Riveter choose the minimal successful config itself.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

2. developerBlock ads on the target page to speed up scraping requests

   weight 1 · round drawn
   Browserbase—none0/10

   The evidence pack mentions general network interception capability (browserbase-docs-4) but no explicit ad-blocking feature, flag, or documentation is cited that lets developers block ads on target pages to speed up scraping. Missing for 10: dedicated ad-blocking API/flag, performance benchmarks showing speed gains, and any documentation referencing ad or resource blocking specifically.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. developerBlock images and CSS resources by default to reduce bandwidth and speed up requests

   weight 1 · round drawn
   Browserbase—none0/10

   The evidence only mentions generic 'network interception' capability (browserbase-docs-4) but nowhere documents blocking images/CSS by default to reduce bandwidth or speed up requests; missing for 10: explicit resource-blocking config, default image/CSS blocking behavior, bandwidth-savings documentation.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”

   proof ↗⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userSet how much reasoning effort an autonomous agent spends on a data-gathering task (low, medium, high)

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase provides browser session infrastructure, scraping, and agent deployment tools, but no evidence describes any 'reasoning effort' control (low/medium/high) for agent tasks — this is a model-level parameter, not something exposed in Browserbase's docs. Missing for 10: any mention of reasoning-effort settings, task budget controls, or configurable agent 'thinking' levels.

   ⚑ flag

   Riveter—none0/10

   No evidence anywhere in the pack of a control that lets users set reasoning effort (low/medium/high) for an agent's data-gathering task; only credit caps and dry-run cost estimation are documented, which are cost controls, not reasoning-effort controls.

   ⚑ flag

Cost transparency

1. developerWhether exceeding my plan's monthly credit or request quota triggers overage charges or a hard cutoff

   weight 3 · round drawn
   Browserbase—none0/10

   No evidence in the pack addresses billing behavior when plan quotas are exceeded—nothing on overage charges vs hard cutoffs is documented.

   ⚑ flag

   Riveter—none0/10

   The evidence describes credit estimation, dry_run, and max_credits cap that refuses requests at 422 before charging, but there is no mention of plan-level monthly credit/request quotas, nor whether exceeding them triggers overage billing or a hard cutoff. missing for 10: any documentation of monthly plan quotas, overage billing policy, or hard-cutoff behavior when a subscription limit is exceeded.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

2. developerWhether failed, blocked, or empty-result requests still consume my billing quota

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack addresses billing treatment of failed, blocked, or empty-result sessions—pricing docs, session lifecycle, or FAQ content on quota consumption for unsuccessful requests are absent.

   ⚑ flag

   Riveter—none0/10

   The docs describe dry_run cost estimation and max_credits caps that prevent overage, but nothing states whether a failed, blocked, or empty-result run still consumes credits. Missing for 10: explicit policy on billing for failed/empty/blocked runs, any refund or non-charge guarantee for zero-result enrichments.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

3. developerSet a spending cap or usage alert so proxy/credit consumption doesn't silently blow past my budget

   weight 3 · round to Riveter
   Browserbase—none0/10

   No evidence of spending caps, budget alerts, or usage-limit controls anywhere in the docs or community pack; all citations concern browser automation features, not billing/usage controls.

   ⚑ flag

   Riveter~partialclaimed6/10

   Riveter offers per-request cost control via dry_run (credit estimate before charging) and max_credits (hard ceiling that returns 422 credit_cap_exceeded with nothing charged), which directly prevents a single run from blowing past a set budget. However, there's no evidence of an account-wide spending cap, recurring usage alerts, or a dashboard/notification system for cumulative consumption across runs. Missing for 10: account/org-level budget cap, proactive usage alerts/notifications, historical spend tracking dashboard.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

Performance tuning

1. developerTrade off latency against completeness by controlling exactly when content is returned

   weight 1 · round to Riveter
   Browserbase—none0/10

   Browserbase's evidence covers session control, auto-waits, and content extraction generally, but nothing describes developer-facing controls for choosing when to return content (e.g., wait strategies, streaming vs full-page load, timeout tuning) to trade latency for completeness. missing for 10: explicit wait/timeout configuration options, streaming or partial-content return APIs, documentation on latency-completeness tradeoffs.

   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”

   proof ↗⚑ flag

   Riveter✓fullclaimed7/10

   Riveter explicitly exposes multiple latency/completeness tradeoffs: quick_search returns fast synchronous structured snippets, search_agent runs a fuller AI research loop for one question, and full enrichments can be tracked via wait_for_result long-polling or async webhook callbacks — giving a developer direct control over when and how complete the returned content is. missing for 10: no independent/hands-on benchmarks or third-party confirmation of actual latency differences between these modes.

   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”

   proof ↗⚑ flag

Plan scale limits

1. data-engineerThe maximum concurrent sessions or requests allowed on my pricing tier and the cost to raise that cap

   weight 2 · round drawn
   Browserbase—none0/10

   The evidence pack contains no pricing page, tier comparison, or concurrency-cap documentation; only marketing claims about spinning up 'thousands of concurrent sessions' with no tier-specific limits or upgrade costs cited. No mention of what concurrency cap applies at each plan or how much raising it costs.

   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence pack items mention pricing tiers, concurrency/rate limits, or the cost to raise such caps; only credit-cap controls (max_credits) and dry-run estimates are documented, which address per-request cost, not concurrent session limits or tier-based upgrade pricing.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location controls for Browserbase sessions or data; all evidence covers browser automation features and community sentiment unrelated to data location.

   ⚑ flag

   Riveter—none0/10

   No evidence in the pack mentions data residency, regional storage options, or compliance controls for where data is stored; the docs focus entirely on enrichment features and API mechanics. Missing for 10: any mention of region selection, data residency options, or storage location controls.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack addresses data retention policies, session data deletion controls, or privacy/compliance settings for stored session artifacts. The docs focus entirely on browser automation capabilities, not data lifecycle management.

   ⚑ flag

   Riveter—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for Riveter's stored enrichment data, run results, or scraped content.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence pack item mentions telemetry, usage tracking, opt-out settings, or privacy controls for Browserbase; the axis is applicable to a cloud service handling browser sessions/data but no supporting documentation is present.

   ⚑ flag

   Riveter—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or any opt-out mechanism for Riveter; the docs focus entirely on enrichment, scraping, and API features. Missing for 10: any mention of telemetry practices, privacy policy, or opt-out settings.

   ⚑ flag

Ai driven crawling

1. ai-native userRely on adaptive crawling that automatically stops once enough information has been gathered to answer my query

   weight 2 · round to Riveter
   Browserbase—none0/10

   Browserbase offers browser automation, session infrastructure, web search, and URL-to-content extraction, but no evidence describes adaptive crawling logic that autonomously determines when 'enough' information has been gathered to stop crawling further.

   ⚑ flag

   Riveter~partialclaimed3/10

   Riveter's search_agent and enrichment agent loop imply some autonomous research process that fills a cell with an AI-researched answer, suggesting the agent decides when it has enough data, but there is no explicit documentation of stopping criteria or adaptive crawling behavior tied to query sufficiency. missing for 10: explicit description of adaptive stopping/crawling logic, evidence of how the agent determines 'enough information', independent confirmation of this behavior in practice.

   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ flag

Batch processing

1. data-engineerBatch scrape thousands of URLs asynchronously

   weight 3 · round drawn
   Browserbase~partialclaimed6/10

   Browserbase docs claim it can spin up thousands of concurrent browser sessions and return answers immediately, directly supporting async batch scraping at scale, plus scheduling/deploying agents on demand. However, there is no explicit documentation of a batch-job API, queueing semantics, rate-limit/backoff guidance, or independent hands-on evidence confirming reliability at thousands-of-URL scale. missing for 10: dedicated batch/queue API docs, independent benchmarks or case studies validating thousands-of-URL scraping, and error-handling/retry guarantees at scale.

   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”

   proof ↗⚑ flag

   Riveter~partialclaimed6/10

   Riveter's enrichment engine explicitly processes rows of URLs with scraping, runs asynchronously (webhook_url on completion), and SDKs handle retries, long-polling, and pagination — all core pieces for async batch scraping. However, there's no explicit documentation of scale limits, concurrency handling, or a tested example at thousands-of-URLs volume. Missing for 10: explicit large-scale (thousands of URLs) benchmarks or case studies, concurrency/rate-limit guidance for very large batches.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”

   proof ↗⚑ flag

2. developerApply different crawl configurations to different URL patterns within a single batch job

   weight 1 · round drawn
   Browserbase—none0/10

   Browserbase's evidence covers session management, agent tooling, scraping/search APIs, and scheduling, but nothing describes a batch job mechanism where different crawl configurations can be applied per URL pattern within one job. This is a plausible axis for a browser automation platform, but no feature or doc supports it.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”

   proof ↗⚑ flag

   Riveter—none0/10

   No evidence describes applying different crawl configurations per URL pattern within one batch/enrichment job; docs mention scraping, searching, and enrichment generally but not per-pattern configuration rules. missing for 10: any mention of per-URL-pattern rules or configuration scoping within a single job, examples or docs showing mixed crawl settings in one batch.

   ⚑ flag

Concurrency

1. data-engineerSpin up many concurrent scraping sessions to gather data at scale

   weight 3 · round to Browserbase
   Browserbase✓fullclaimed8/10

   Docs explicitly claim ability to 'spin up thousands of concurrent browser sessions' with programmatic session creation/control and scraping-focused features (login walls, CAPTCHAs, data extraction), directly matching the story. Missing for 10: independent/hands-on benchmarks validating concurrency at scale and no third-party performance corroboration beyond vendor docs.

   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Full browser control with auto-waits, network interception, and multi-tab support.”
   • [claimed-docs] “Your agent logs in, navigates, and pulls data from any website, login walls included.”
   • [claimed-docs] “When your workflow requires a form, a CAPTCHA, or a login prompt, it's handled.”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Riveter's enrichment engine processes many rows in a single run and can chain scrapes/searches (e.g., finding every dental practice then every dentist in one request), implying built-in batch/bulk scraping at scale, and SDKs handle retries/pagination for large jobs. However, there is no explicit documentation of concurrency limits, parallel session management, or throughput guarantees for scraping specifically. Missing for 10: explicit concurrency/session limits, performance benchmarks, and independent evidence of scaling to many simultaneous scrape sessions.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”

   proof ↗⚑ flag

Crawl compliance

1. data-engineerConfigure the crawler to respect robots.txt rules and target-site rate limits automatically

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence in the pack mentions robots.txt compliance, rate-limit configuration, or crawl politeness controls; Browserbase docs focus on session control, agent tooling, and captcha/login handling but nothing about respecting robots.txt or throttling requests to target sites.

   ⚑ flag

   Riveter—none0/10

   No evidence anywhere in the docs mentions robots.txt compliance or rate-limit configuration; the pack only covers scraping features, retries, credits, and MCP integration. This is a fair axis for a web-scraping/crawling product, but absence of evidence means it cannot be credited as delivered.

   ⚑ flag

Fault tolerance

1. data-engineerResume a crashed deep crawl from a saved checkpoint instead of restarting from scratch

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of checkpointing or resumable crawl functionality; Browserbase docs describe session creation, control, and scaling but nothing about saving/restoring crawl state after a crash.

   ⚑ flag

   Riveter—none0/10

   No evidence describes checkpointing or resuming a crashed deep crawl; the docs mention webhooks, dry runs, and credit caps but nothing about saving/resuming crawl state after a crash.

   ⚑ flag

Operational transparency

1. data-engineerCheck a public status page showing uptime history and past incident postmortems before committing to the service

   weight 2 · round drawn
   Browserbase—none0/10

   No evidence of a public status page, uptime history, or incident postmortems anywhere in the evidence pack; only product feature docs and unrelated community comments are provided.

   ⚑ flag

   Riveter—none0/10

   No evidence of a public status page, uptime history, or incident postmortems anywhere in the evidence pack; only product feature docs and API references are present.

   ⚑ flag

Scheduling monitoring

1. data-engineerMonitor target pages for content changes, such as price or listing updates, and get notified as they happen

   weight 2 · round to Riveter
   Browserbase~partialclaimed5/10

   Marketing copy explicitly promises tracking price/listing changes 'as they happen' and alerting when something breaks, and agents can be scheduled or run on demand, aligning with the monitoring+notify story. However there's no documented notification mechanism (webhooks, email/Slack alerts), no dedicated 'change detection' API, and no independent/hands-on evidence confirming this works in practice. Missing for 10: concrete alerting/notification API or integration docs, hands-on validation of change-monitoring workflows, independent user reports of this specific use case.

   • [claimed-docs] “Run agents that click through your product continuously and alert you the moment something breaks.”
   • [claimed-docs] “Track prices, job listings, product changes, and competitor moves as they happen.”
   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”

   proof ↗⚑ flag

   Riveter~partialclaimed7/10

   Riveter explicitly supports scheduling projects to monitor for changes, refreshing as often as every minute, and can POST results to a webhook_url when a run finishes, which together deliver change-monitoring plus notification. However, the webhook fires on run completion rather than a dedicated 'content changed' diff event, and there's no independent/hands-on evidence of this workflow in production. Missing for 10: independent corroboration of the schedule+webhook pipeline in practice, and explicit diff/change-detection logic distinguishing 'changed' vs 'unchanged' pages.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

2. data-engineerMonitor job performance, validate data quality, and receive alerts when something fails

   weight 2 · round drawn
   Browserbase~partialclaimed5/10

   Browserbase supports observing browser sessions (browserbase-docs-1) and explicitly offers agents that 'click through your product continuously and alert you the moment something breaks' (browserbase-docs-11), which covers basic failure alerting for scraping/monitoring jobs. However, there is no evidence of structured job performance dashboards, metrics, or explicit data-quality validation tooling for extracted data. Missing for 10: dedicated job performance monitoring/metrics dashboard, data quality validation checks, and integration with alerting channels (email/Slack/webhooks) beyond a generic marketing claim.

   • [claimed-docs] “Create, control, and observe browser sessions programmatically.”
   • [claimed-docs] “Run agents that click through your product continuously and alert you the moment something breaks.”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Riveter supports webhook alerts on run completion/stop/finish events and scheduled monitoring for data freshness, giving some job-status alerting and monitoring capability, but there is no explicit data-quality validation feature (e.g., schema/anomaly checks) or job performance dashboards described. missing for 10: explicit data quality validation tooling, job performance metrics/dashboard, and independent confirmation of alerting reliability.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

3. developerMonitor live system metrics and worker/browser pool status through a real-time dashboard

   weight 1 · round drawn
   Browserbase—none0/10

   Evidence covers session control, agent frameworks, and scraping use cases but contains no mention of a real-time dashboard for monitoring live system metrics or worker/browser pool status; no dashboard UI, metrics endpoint, or observability feature is documented.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. developerSchedule scraping jobs to run automatically at specific times

   weight 2 · round to Browserbase
   Browserbase~partialclaimed6/10

   Docs explicitly state agents can be deployed 'on Browserbase, on a schedule or on demand,' directly supporting scheduled scraping jobs, but there's no detail on scheduling configuration, cron-like syntax, retry/failure handling, or independent hands-on confirmation. missing for 10: detailed scheduling API/config docs, examples of recurring job setup, independent verification of schedule reliability.

   • [claimed-docs] “Deploy and run browser agents on Browserbase, on a schedule or on demand.”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”
   • [claimed-docs] “Track prices, job listings, product changes, and competitor moves as they happen.”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Riveter supports scheduling projects to monitor for changes and refresh data as often as every minute, which implies automatic recurring scraping jobs, but there's no detail on specifying exact times/cron-like scheduling, timezone control, or a documented scheduling API/UI. missing for 10: explicit scheduling configuration details (time-of-day, cron syntax, timezone), independent/hands-on confirmation of scheduling reliability, and API endpoint documentation for creating/managing schedules.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   proof ↗⚑ flag

Site crawling

1. data-engineerRun a deep crawl using a breadth-first strategy with a configurable maximum page limit

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase provides browser session infrastructure, session control, and agent tooling, but there is no evidence of a deep-crawl feature with breadth-first traversal or a configurable max page limit; crawling logic would need to be built by the customer on top of the raw browser sessions.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. developerCrawl an entire website and get content from all its pages with one request

   weight 3 · round to Riveter
   Browserbase—none0/10

   Browserbase's docs describe session control, single-URL-to-content conversion, web search, and scaling concurrent sessions, but no evidence describes a one-request whole-site crawl capability that traverses all pages and aggregates content.

   • [claimed-docs] “Quickly fetch web context for your agent by converting any URL into HTML, JSON or markdown”
   • [claimed-docs] “Spin up thousands of concurrent browser sessions and return answers immediately”

   proof ↗⚑ flag

   Riveter~partialclaimed5/10

   Riveter's docs describe single-URL 'scrape' and 'quick_search' calls, but the marketing example of finding every dental practice in a city and pulling data from each one in a single request shows it can aggregate content across multiple pages/sources in one enrichment run, which approximates whole-site crawling. There is no explicit sitemap-style 'crawl entire website' feature or evidence of full-domain page enumeration. missing for 10: explicit full-site/sitemap crawl feature, evidence of automatically discovering and traversing all pages of a single domain, independent confirmation of multi-page crawl behavior.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

3. developerInstantly discover all URLs on a website without fully crawling it

   weight 2 · round drawn
   Browserbase—none0/10

   Browserbase's docs cover session control, web search, URL-to-content conversion, and full browsing/automation, but nothing describes a lightweight URL-discovery or sitemap-extraction capability that avoids full crawling. Missing for 10: any sitemap parsing, link-graph extraction, or 'list all URLs' feature distinct from full page rendering/crawling.

   ⚑ flag

   Riveter—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag