Jina Reader vs Riveter

Agent access

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

   weight 2 · round to Jina Reader
   Jina Reader~partialprobed5/10

   Jina Reader's core function—converting any URL to LLM-friendly markdown (r.jina.ai/<url>)—technically lets an agent fetch llms.txt or agent-oriented docs pages and get clean text, and the 'research' preset is explicitly aimed at AI research agents needing structured, citable output. But there is no evidence of llms.txt-specific parsing/discovery, sitemap-style agent doc crawling, or first-party guidance for this workflow, and a probe shows Jina's own site lacks an llms.txt (404), undercutting any implied endorsement of the convention. missing for 10: explicit llms.txt/agent-doc support or examples, first-party documentation naming this use case, evidence Jina practices llms.txt on its own docs.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”

   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 drawn
   Jina Reader~partialcommunity6/10

   Jina Reader is a plain HTTP endpoint and also ships a self-hostable Docker image bundling headless Chrome/LibreOffice, making it straightforward to script and run in CI pipelines (curl, headers for output control). However, community reports show real-world automation attempts hitting 401/404 errors, and there is no first-party CI/automation guide or examples. missing for 10: explicit CI/CD documentation or examples, rate-limit/reliability guarantees for unattended use, and resolution of the reported auth/404 failures in automated contexts.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   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 drawn
   Jina Reader✓fullprobed7/10

   Jina explicitly documents an official MCP server repository (jina-ai/MCP) that would expose Reader's capabilities to agents, but the evidence pack lacks first-party details on setup, tool list, or hands-on/independent corroboration of its use. missing for 10: detailed MCP server docs/tool schema, hands-on or community verification of the MCP server working end-to-end.

   • [probe] “official MCP server documented at https://github.com/jina-ai/MCP”

   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 drawn
   Jina Reader—none0/10

   The evidence pack shows Jina Reader as an HTTP API/service (curl-based usage, headers like x-respond-with, x-preset) and a self-hostable Docker image, but there is no mention of an official dedicated CLI tool for interacting with Reader. No evidence names a packaged command-line binary or npm/pip CLI client.

   ⚑ 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 Jina Reader
   Jina Reader✓fullprobed8/10

   Jina Reader ships an extensively documented public HTTP API (r.jina.ai) with numerous header-controlled options (output format, presets, chunking, cookies, JSON schema extraction, proxy routing) all detailed in first-party GitHub docs, directly enabling programmatic/agentic use. Missing for 10: a discoverable machine-readable spec (OpenAPI/swagger probes returned 404, llms.txt 404), and independent confirmation beyond community auth-error reports which reflect expected key requirements rather than API failure.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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
   Jina Reader—none0/10

   No evidence of scoped or least-privilege API key/credential issuance for agents; the pack only shows a single API key auth requirement and no mention of scoped tokens, permissions, or credential management.

   ⚑ 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 Riveter
   Jina Reader—none0/10

   The evidence pack documents Jina Reader purely as an HTTP endpoint (curl-style requests with custom headers like x-respond-with, x-preset, x-json-schema) and an OpenAPI/llms.txt probe that both 404'd — there is no mention of an official Python/JS/other SDK package for building against it.

   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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
   Jina Reader—none0/10

   No evidence anywhere in the pack of Jina Reader supporting webhooks or event subscriptions; it's a synchronous URL-to-text conversion API with no mention of push/callback mechanisms.

   ⚑ 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
   Jina Reader—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 Riveter
   Jina Reader—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 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
   Jina Reader—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
   Jina Reader~partialclaimed6/10

   The `x-instruction` header lets users give natural-language instructions to extract specific fields (via ReaderLM-v2), and the `x-preset: research` bundle is tailored for AI agents, showing some natural-language-driven operation. However, this is limited to extraction/formatting rather than full natural-language control of the whole reading/search pipeline, and there's no independent corroboration of reliability. Missing for 10: broader NL control across all Reader operations (search, fetch, formatting) and third-party validation that x-instruction works robustly.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”

   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 to Jina Reader
   Jina Reader✓fullclaimed8/10

   The `x-preset: research` option is explicitly documented as being 'for AI research agents needing structured, citable output,' directly matching the story, and complements related features like frontmatter/YAML output and JSON schema extraction for structured data. Missing for 10: independent or hands-on verification that the research preset's output quality/citability holds up in practice beyond the first-party docs.

   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   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
   Jina Reader—none0/10

   There is no evidence of an interactive API reference or runnable examples; probes explicitly found no OpenAPI/swagger spec (404s) and no llms.txt, and the documentation snippets only describe headers/params in prose form, not an interactive playground.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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
   Jina Reader—none0/10

   Direct probes for OpenAPI/Swagger spec files and llms.txt all returned 404, and no evidence pack item shows a downloadable machine-readable API spec being published.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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
   Jina Reader—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 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
   Jina Reader—none0/10

   There is no evidence of API versioning (e.g., /v1/ paths) or a published deprecation policy; probes for OpenAPI spec and llms.txt both 404, and no docs mention version lifecycle commitments. missing for 10: versioned endpoint scheme, documented deprecation/sunset policy, changelog or migration guide.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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
   Jina Reader—none0/10

   Community evidence explicitly states the website does not mention an API rate limit, and probes for API spec/docs (openapi, llms.txt) return 404s, so no documented RPS/RPM throttling threshold is available.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   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 Jina Reader
   Jina Reader~partialclaimed3/10

   Reader's SaaS proxy claims to 'handle common anti-bot challenges automatically' and supports forwarding session cookies via X-Set-Cookie for login-walled pages, but neither is documented as solving CAPTCHAs, and cookie-based login still requires the user to manually obtain and supply valid session cookies beforehand. Missing for 10: explicit CAPTCHA-solving capability, fully automatic login/form-wall traversal without any pre-supplied credentials, and independent evidence confirming these anti-bot claims work in practice.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”

   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 to Jina Reader
   Jina Reader~partialclaimed4/10

   Jina Reader offers a single hosted proxy option (`x-proxy: auto`) that rotates residential/datacenter IPs and handles common anti-bot challenges, but there is no evidence of an automatic retry mechanism chaining through multiple distinct proxy providers/configs on failure. missing for 10: documented retry/fallback logic across a chain of different proxies, evidence of automatic re-attempt after a block, independent confirmation of anti-bot bypass success.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ 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 drawn
   Jina Reader—none0/10

   Evidence shows a rotating IP proxy pool that 'handles common anti-bot challenges automatically' (x-proxy: auto), but there is no mention of an undetected/stealth browser mode, fingerprint spoofing, or bypassing sophisticated bot detection like Cloudflare/Datadome-style challenges. This is a distinct, more specific capability than generic proxy rotation and is unevidenced.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   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
   Jina Reader—none0/10

   Evidence shows a proxy toggle (x-proxy: auto) that rotates residential/datacenter IPs and bypasses anti-bot challenges, but no capability to select or request a proxy from a specific country/geolocation.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   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. developerUse premium residential or datacenter proxies to bypass sites that are hard to scrape

   weight 3 · round to Jina Reader
   Jina Reader✓fullclaimed7/10

   Jina Reader offers a hosted SaaS proxy pool (`x-proxy: auto`) that rotates residential/datacenter IPs and auto-handles anti-bot challenges, directly matching the story. Missing for 10: independent/hands-on confirmation of proxy effectiveness against hard-to-scrape sites, and detail on choosing specific proxy types/locations rather than just 'auto'.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ 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 to Jina Reader
   Jina Reader✓fullclaimed7/10

   Reader documents a hosted proxy feature (`x-proxy: auto`) that rotates residential/datacenter IPs and auto-handles anti-bot challenges, directly matching the story. missing for 10: no independent/hands-on confirmation of rotation behavior or effectiveness against blocks, and no detail on pool size or geographic control.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   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. developerRoute multiple requests through the same proxy IP using a session identifier to maintain a consistent identity

   weight 2 · round drawn
   Jina Reader—none0/10

   Evidence shows a proxy rotation feature (x-proxy: auto) that rotates IPs for anti-bot handling, but there is no mention of a session identifier or sticky-IP mechanism to keep the same proxy IP across multiple requests for a consistent identity.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   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

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

   weight 2 · round to Riveter
   Jina Reader~partialclaimed4/10

   The search endpoint fetches and converts the top 5 results in one call (jina-reader-gh-2), showing some multi-item processing, but there's no documented bulk/batch API for submitting many arbitrary URLs or files at once beyond single-item POST endpoints (jina-reader-gh-1, jina-reader-gh-3). missing for 10: a dedicated batch/bulk endpoint accepting arbitrary lists of URLs, documented concurrency/rate limits for bulk jobs, and evidence of large-scale automation use.

   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”

   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 to Riveter
   Jina Reader—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 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 to Riveter
   Jina Reader—none0/10

   Jina Reader is a URL-to-text/API conversion service with no evidence of a scheduler, cron-like trigger, or recurring workflow feature; nothing in the evidence pack describes recurring jobs or workflow automation beyond single-shot fetch requests.

   ⚑ 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

Collaboration

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

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of team/organization management, shared scraper libraries, or role-based access control features; Jina Reader is a URL-to-text API product with no collaboration or RBAC layer mentioned anywhere in the evidence pack.

   ⚑ 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 Riveter
   Jina Reader—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'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 to Jina Reader
   Jina Reader~partialclaimed6/10

   A prebuilt GitHub Container Registry image bundling headless Chrome, LibreOffice, and CJK fonts is documented, enabling self-hosted Docker deployment without building from source. However, missing for 10: no production deployment guidance (scaling, orchestration, resource sizing), no independent hands-on confirmation of running the container in production, and no docs on configuration/env vars for the containerized service.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   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 to Jina Reader
   Jina Reader✓fullclaimed8/10

   GitHub repo explicitly documents an open-source branch with a prebuilt image on GitHub Container Registry bundling headless Chrome, LibreOffice, and CJK fonts so developers can self-host without building from scratch. Missing for 10: independent hands-on report confirming self-hosted deployment works smoothly and details on feature parity vs. the hosted proxy (e.g., anti-bot/x-proxy features noted as SaaS-only).

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   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
   Jina Reader—none0/10

   No evidence of a prebuilt n8n or Zapier connector; the evidence only covers the REST API, headers, self-hosting, and an MCP server, none of which constitute a no-code automation platform connector.

   ⚑ 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
   Jina Reader—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

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
   Jina Reader—none0/10

   Jina Reader outputs markdown/JSON per request but there is no evidence of exportable job configuration bundles, batch export tooling, or any portability/migration feature; the evidence pack never mentions exporting data or configs for migration. missing for 10: export/download of scraped data sets, job configuration export, migration tooling or documentation.

   ⚑ 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
   Jina Reader—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 drawn
   Jina Reader—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

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

   weight 1 · round drawn
   Jina Reader—none0/10

   Jina Reader is a URL-to-text/API service with usage flags and headers, but there is no evidence of any ready-made project templates or starter kits for developers to bootstrap projects with.

   ⚑ 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
   Jina Reader~partialclaimed6/10

   Jina Reader's docs describe an `x-instruction` header that accepts natural-language extraction instructions (alongside a JSON-schema alternative), directly matching the story of skipping selectors, and this is paired with ReaderLM-v2 for field extraction. However, this is a single first-party doc mention with no independent hands-on validation, extraction accuracy examples, or benchmark, and community threads focus on unrelated auth/JS issues rather than confirming this feature's real-world quality. Missing for 10: independent verification of extraction accuracy, example outputs, and confirmation the feature works reliably outside vendor docs.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   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 Jina Reader
   Jina Reader✓fullclaimed8/10

   Docs explicitly describe an x-json-schema header for passing a JSON schema definition that works with ReaderLM-v2 to extract specific fields, directly matching the story. Missing for 10: independent/hands-on verification of schema-conformant output and no worked example showing exact schema-to-output mapping.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   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
   Jina Reader✓fullclaimed7/10

   Reader explicitly supports `x-instruction` (natural language) and `x-json-schema` headers feeding ReaderLM-v2 to extract specific fields, meaning an LLM/instruction can decide what to pull without pre-written CSS/XPath selectors — directly matching the story. Missing for 10: independent/hands-on verification of extraction quality/accuracy beyond the single first-party doc claim, and no community corroboration of this specific feature working reliably.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   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
   Jina Reader—none0/10

   Evidence shows Jina Reader uses fixed VLM captioning and ReaderLM-v2 for structured extraction, with no mention of configuring a local/self-hosted LLM as an alternative extraction backend; the open-source self-hosted image runs Reader's own pipeline (Chrome, LibreOffice) rather than letting users swap in their own LLM.

   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   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 drawn
   Jina Reader—none0/10

   Jina Reader's entire design purpose is to convert pages into LLM-friendly Markdown/JSON/frontmatter output (jina-reader-docs-2, jina-reader-gh-5), not raw HTML; no evidence pack item shows an option to return unprocessed raw HTML, and the docs explicitly frame raw scraping as the problem being solved rather than the deliverable.

   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”

   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
   Jina Reader—none0/10

   No evidence of any PII detection or redaction/filtering feature; Jina Reader's documented capabilities focus on content extraction, formatting, chunking, and structured extraction via schemas, not privacy/PII filtering.

   ⚑ 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 Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly supports POSTing PDFs and MS Office (Word, Excel, PowerPoint) files directly via the `file` body field without needing to host them, and the self-hosted image bundles LibreOffice to process these office formats. Community evidence shows some auth/404 issues but none specifically contradict document-extraction functionality. Missing for 10: independent hands-on verification of extraction quality/fidelity across all four file types and no detail on limits (file size, complex formatting).

   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   proof ↗⚑ 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 Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly auto-captions images lacking alt tags using a VLM and formats them inline as markdown, directly enabling text-only models to reason about visual content. Missing for 10: independent/hands-on verification of caption quality and no mention of configurability or coverage for images with existing (but poor) alt text.

   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”

   proof ↗⚑ 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 Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader's documented behavior explicitly performs a web search, fetches the top 5 results, and converts each to LLM-friendly full text in one call (s.jina.ai flow), with a 'research' preset tailored for citable agent output. Missing for 10: independent hands-on verification specifically of the search+fetch endpoint (the community evidence cited relates to a different third-party wrapper's auth/404 issues, not this feature directly).

   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   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 to Jina Reader
   Jina Reader~partialclaimed4/10

   Jina Reader offers structured field extraction via `x-json-schema` and `x-instruction` headers (backed by ReaderLM-v2), which lets developers pull specific fields, but the evidence never mentions CSS or XPath selector syntax as the extraction mechanism. Missing for 10: explicit CSS selector support, explicit XPath selector support, documentation showing selector-based (not just schema/instruction-based) targeting.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   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 to Jina Reader
   Jina Reader~partialclaimed4/10

   Reader offers an opt-in `x-markdown-chunking` feature that splits markdown output into semantic chunks, which could help fit large content (including tables) within processing limits, but there is no evidence it specifically preserves table structure or handles very large tables intelligently. missing for 10: table-aware chunking logic, evidence of table structure preservation across chunks, benchmarks on large-table extraction accuracy.

   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   proof ↗⚑ 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 Jina Reader
   Jina Reader~partialcommunity6/10

   The self-hosted Reader image bundles headless Chrome (gh-8), and docs claim clean output even for 'complex or dynamic pages' (docs-2), implying SPA/JS rendering support. However, a community commenter explicitly notes the website doesn't clearly document dynamic JS support, and no first-party doc or hands-on test explicitly confirms full SPA rendering works end-to-end. Missing for 10: explicit documentation stating JS/SPA rendering is supported, a hands-on demonstration of a JS-heavy site being fully rendered, and resolution of the community's noted uncertainty about dynamic JS handling.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   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 drawn
   Jina Reader—none0/10

   The evidence shows Reader has timing controls (x-respond-timing to trade latency vs completeness) and general JS-rendering via headless Chrome, but there's no mention of a selector-wait mechanism (e.g., waiting for a specific CSS/XPath selector before returning). Community feedback even notes it's unclear whether/how dynamic JS support works.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   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 drawn
   Jina Reader—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. developerKeep interacting with an already-scraped page, clicking and filling forms to reach content behind a login wall

   weight 2 · round drawn
   Jina Reader—none0/10

   Jina Reader is a stateless URL-to-markdown converter; there's no evidence of interactive session persistence, clicking, or form-filling to navigate behind a login wall. Cookie forwarding (X-Set-Cookie) only supports pre-authenticated single fetches, not interactive multi-step navigation.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   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 drawn
   Jina Reader—none0/10

   Jina Reader offers cookie forwarding, proxy rotation, timing/format controls, and extraction schemas, but no evidence shows any mechanism to script page interactions like clicking, filling inputs, or scrolling before content extraction; community comments explicitly note uncertainty about dynamic JS handling.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   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
   Jina Reader—none0/10

   No evidence pack item mentions viewport width/height control, browser window sizing, or any device-emulation/viewport configuration options for Jina Reader's rendering.

   ⚑ 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 to Jina Reader
   Jina Reader~partialcommunity6/10

   Jina Reader's docs describe an X-Set-Cookie header that forwards developer-supplied session cookies when fetching a URL, directly matching the story. However this is a single claimed-docs citation with no independent/hands-on corroboration, and community evidence shows unrelated auth/reliability issues (401 errors, 404s) that raise doubts about robustness. Missing for 10: independent verification that cookie-based authenticated fetches actually work end-to-end, and documentation depth (e.g., examples, session persistence details).

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   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
   Jina Reader—none0/10

   Jina Reader supports passing session cookies per-request via the X-Set-Cookie header, but there is no evidence of a persistent browser profile that maintains login/cookie state across multiple requests automatically — each request appears stateless, requiring cookies to be re-supplied manually.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”

   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 Jina Reader
   Jina Reader✓fullclaimed7/10

   Jina Reader is fundamentally an API-first product where nearly all functionality (URL-to-markdown conversion, web search, PDF/Office ingestion, VLM image captioning, JSON schema/instruction-based extraction, chunking, proxy routing, cookie forwarding, output presets) is exposed entirely through API endpoints and headers, with no evidence of a richer separate UI holding back features. This suggests the API is the primary and complete interface, matching the AI-native openness story well. Missing for 10: no explicit documentation stating 'everything the UI can do the API can also do' or comparison against a dashboard/UI feature set, and no independent corroboration confirming full parity.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”
   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   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
   Jina Reader—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

   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 to Jina Reader
   Jina Reader~partialclaimed6/10

   Jina Reader has an open-source branch on GitHub with a prebuilt image published to GitHub Container Registry, confirming source availability, but the evidence pack never states the license under which the code is released. missing for 10: explicit license file/name (e.g., Apache/MIT) confirming open-license status, independent confirmation of license terms.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   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 to Jina Reader
   Jina Reader✓fullclaimed8/10

   The open-source branch is self-hostable via a prebuilt Docker image on GitHub Container Registry bundling headless Chrome, LibreOffice, and CJK fonts, so users can run Reader without building it themselves. Missing for 10: independent hands-on confirmation of a successful self-hosted deployment and details on feature parity between self-hosted and SaaS versions.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   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 Jina Reader
   Jina Reader✓fullclaimed9/10

   Jina Reader's core function is converting URLs into clean, LLM-friendly Markdown (r.jina.ai), with additional options like frontmatter YAML, image captioning, and semantic chunking, all well documented in first-party sources. Missing for 10: independent hands-on verification of markdown output quality (community evidence cited focuses on auth/404 issues, not output format fidelity).

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   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 Jina Reader
   Jina Reader✓fullclaimed9/10

   jina-reader-gh-5 documents the `x-respond-with` header explicitly selecting output format including markdown, HTML, text, and frontmatter (Markdown+YAML), directly matching the story; gh-10 adds chunking control as extra format nuance. Missing for 10: independent hands-on confirmation of each format option (community evidence only covers auth errors, not format selection).

   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   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
   Jina Reader~partialclaimed6/10

   Jina Reader supports structured output via `x-json-schema` for schema-defined field extraction and `x-markdown-chunking` for JSON array chunk output, plus frontmatter YAML metadata — showing real structured-output capability beyond plain markdown. However, the default/primary output is markdown/LLM-friendly text, not JSON, and there's no evidence of a dedicated full-page-to-JSON endpoint or independent confirmation these structured modes work reliably in practice. Missing for 10: independent/hands-on verification of x-json-schema output quality, a documented default JSON response mode, and confirmation these features aren't limited/beta.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”

   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 Jina Reader
   Jina Reader✓fullcommunity9/10

   Jina Reader's core purpose is converting any URL into clean, LLM-ready Markdown/text, avoiding manual HTML parsing and handling JS rendering, anti-bot blocking, and headless browsing behind the scenes, with configurable output formats (frontmatter, JSON, chunked) tailored to AI agents. Community reports show some auth/404 errors on certain deployments, but the core capability is well documented and corroborated. Missing for 10: broader independent benchmarking of output quality/reliability across diverse sites beyond one HN anecdote of failure.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”

   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 to Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly supports `x-markdown-chunking`, an opt-in header returning semantically chunked output as a JSON array or delimited text instead of one blob, directly matching the story. Missing for 10: independent hands-on validation of chunk quality/boundaries and no detail on chunking algorithm robustness across document types.

   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   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
   Jina Reader—none0/10

   No evidence in the pack mentions screenshot capture of full pages or selected areas; Jina Reader's documented capabilities focus on converting URLs to Markdown/text, image captioning, and structured extraction, not visual screenshots.

   ⚑ 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
   Jina Reader—none0/10

   No evidence Jina Reader has any automatic cost-optimization logic that selects the cheapest configuration guaranteed to succeed; the options exposed (x-preset, x-respond-timing, x-proxy) are manually set by the developer, not auto-selected for cost minimization, and pricing/limits aren't even documented per community reports.

   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ 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
   Jina Reader—none0/10

   No evidence of any ad-blocking or content-filtering feature to speed up scraping; Reader's evidence covers output formatting, chunking, proxy rotation, and cookie forwarding, but nothing about blocking ads/trackers on the target page.

   ⚑ 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
   Jina Reader—none0/10

   No evidence of an option to block images or CSS resources by default; Reader's documented features focus on content extraction, VLM image captioning, and output formatting, not resource-blocking for bandwidth savings.

   ⚑ 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
   Jina Reader—none0/10

   Jina Reader is a URL-to-text extraction service, not an autonomous reasoning agent; there is no reasoning-effort/low-medium-high control exposed. The closest options (x-respond-timing trading latency vs completeness, x-preset) control fetch behavior, not agentic reasoning depth, so the specific capability is absent.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”

   proof ↗⚑ 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
   Jina Reader—none0/10

   No evidence describes what happens when a plan's monthly credit/request quota is exceeded — no mention of overage billing or hard cutoff behavior; community commentary even notes the site doesn't document API limits at all.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ 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
   Jina Reader—none0/10

   No evidence pack item discusses billing behavior for failed, blocked, or empty-result requests, nor any quota-consumption policy; community notes only mention lack of clarity on API limits and unrelated authentication errors.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ 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
   Jina Reader—none0/10

   No evidence of spending caps or usage alerts; community even notes API limits aren't documented on the website (jina-reader-comm-1), and no billing/quota dashboard or alerting feature is mentioned anywhere in the evidence pack.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ 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 Jina Reader
   Jina Reader✓fullclaimed8/10

   The `x-respond-timing` header is documented explicitly as giving developers explicit control over when Reader returns, directly trading off latency against completeness, which is exactly the story described. Missing for 10: independent/hands-on confirmation of the header's behavior and concrete latency/completeness benchmarks beyond the first-party doc snippet.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”

   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
   Jina Reader—none0/10

   No evidence documents concurrency/request caps per pricing tier or the cost to increase them; community comments explicitly note the website doesn't mention API limits, and authentication errors appear but no rate-limit specifics.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   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
   Jina Reader—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location controls; only self-hosting via a prebuilt container image is mentioned, which is a deployment option not a residency control feature.

   ⚑ 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
   Jina Reader—none0/10

   No evidence pack item addresses data retention policies, data deletion controls, or user-facing settings to manage stored data lifecycle; evidence covers scraping features, formats, and proxying but nothing about retention/deletion posture.

   ⚑ 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
   Jina Reader—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics, or an opt-out mechanism for Jina Reader; the docs focus on API features and scraping, not privacy controls.

   ⚑ 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 Jina Reader
   Jina Reader~partialclaimed4/10

   Reader offers a related knob (`x-respond-timing` to trade off latency vs completeness) and a `research` preset for agentic use, suggesting some adaptive control over when it returns results, but there is no evidence of true query-driven adaptive crawling that stops once 'enough information' has been gathered to answer a specific question — the search flow simply fetches a fixed top-5 results. Missing for 10: explicit query-aware stopping criteria, evidence of dynamic crawl depth/breadth adjustment based on information sufficiency, and independent validation of this behavior.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”

   proof ↗⚑ 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 to Riveter
   Jina Reader—none0/10

   Evidence covers single-URL conversion, search-based fetching, proxy rotation, and format options, but nothing documents a batch/bulk endpoint, job queue, or async processing pipeline for thousands of URLs at once.

   ⚑ 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
   Jina Reader—none0/10

   Jina Reader operates per-URL request with headers/options (e.g. x-preset, x-respond-with) applied uniformly to a single fetch; there's no evidence of a batch-job concept or per-URL-pattern configuration mapping within one job. missing for 10: batch job API, URL-pattern-based rule matching, differentiated configs within a single request/job.

   ⚑ 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 drawn
   Jina Reader~partialcommunity5/10

   Reader offers infrastructure that could support scale (a rotating proxy pool for anti-bot handling, and a self-hostable Docker image bundling headless Chrome so engineers could run many parallel instances), but there is no first-party documentation of concurrency limits, rate limits, or guidance for running many simultaneous scraping sessions. Community commentary explicitly notes the site doesn't mention API limits, adding uncertainty rather than confirmation. missing for 10: documented concurrency/rate limits, guidance or benchmarks for running many parallel sessions, independent evidence of successful large-scale concurrent use.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   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
   Jina Reader—none0/10

   No evidence in the pack mentions robots.txt compliance or configurable rate-limiting; features described relate to output formatting, proxying, and anti-bot bypass, not politeness controls.

   ⚑ 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
   Jina Reader—none0/10

   Jina Reader is a URL-to-markdown conversion API/tool, not a deep-crawl orchestration system with crawl-state checkpointing; no evidence anywhere in the pack mentions crawl checkpoints, resumable crawls, or job-state persistence.

   ⚑ 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
   Jina Reader—none0/10

   No evidence of a public status page, uptime history, or incident postmortems; instead there's community evidence of undocumented failures (404s, auth errors) with no transparency page to check beforehand.

   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   proof ↗⚑ 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
   Jina Reader—none0/10

   Jina Reader converts URLs into LLM-ready content on-demand but there is no evidence of scheduled monitoring, diffing, or change-notification features (webhooks, alerts, polling schedules) that would let a data-engineer track content changes over time.

   ⚑ 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 to Riveter
   Jina Reader—none0/10

   No evidence of job performance monitoring, data quality validation, or failure alerting features; evidence covers content extraction and formatting only, with community reports even noting undocumented API limits and auth errors rather than monitoring/alerting tooling.

   ⚑ 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
   Jina Reader—none0/10

   No evidence of any real-time dashboard, metrics UI, or worker/browser pool status monitoring; evidence only covers content extraction features and API options. This is an applicable axis for a scale-reliability story about a self-hostable service with a browser pool, but nothing in the pack shows such a dashboard exists.

   ⚑ 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 Riveter
   Jina Reader—none0/10

   No evidence of any scheduling, cron, or job-queue feature; Jina Reader is a synchronous URL-to-text API with no mention of automated/recurring execution.

   ⚑ 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
   Jina Reader—none0/10

   No evidence of a deep-crawl feature with breadth-first strategy or configurable page-limit; Jina Reader converts single URLs or performs top-5 search results, not a crawler with BFS/page-limit controls.

   ⚑ 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
   Jina Reader—none0/10

   Jina Reader's evidence describes converting single URLs to LLM-friendly text and a search-then-fetch-top-5 mode, but there is no evidence of a whole-site crawl feature that traverses all pages of a domain in one request.

   ⚑ 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
   Jina Reader—none0/10

   Jina Reader converts individual URLs into clean text/markdown and can search top results, but there is no evidence of a sitemap/URL-discovery feature that lists all URLs on a site without crawling it.

   ⚑ 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