OpenRouter vs Cloudflare AI Gateway

Agent access

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

   weight 2 · round to OpenRouter
   OpenRouter✓fullprobed9/10

   OpenRouter serves a working llms.txt at openrouter.ai/llms.txt (HTTP 200, agent-oriented summary), plus an OpenAPI spec and MCP server that expose docs/data programmatically to agents. This directly satisfies pointing an agent at llms.txt or agent-oriented docs. Missing for 10: independent/community confirmation that agents successfully consume llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”
   • [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialprobed5/10

   Cloudflare's developer docs (which cover AI Gateway) expose a working llms.txt at developers.cloudflare.com/llms.txt, letting an agent discover agent-oriented documentation; an OpenAPI spec is also available. However, the AI Gateway-specific docs page itself returns 404 for the .md variant, so agent-native markdown access is inconsistent at the product-specific level. Missing for 10: a dedicated llms.txt or .md endpoint scoped to AI Gateway docs specifically, and confirmation the top-level llms.txt indexes AI Gateway pages.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/ai-gateway/.md”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round to OpenRouter
   OpenRouter✓fullprobed7/10

   OpenRouter is fundamentally a headless REST API (single endpoint, OpenAI-SDK compatible, streaming, programmatic API key management) that requires no UI and can be called from any script or pipeline, making it inherently suited to CI/automation use; the keyless models endpoint and management API keys reinforce programmatic, non-interactive use. Missing for 10: no explicit CI/CD pipeline examples (e.g., GitHub Actions), no dedicated 'headless/automation' documentation section, and no independent report of someone running it in a CI pipeline.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
   • [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
   • [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
   • [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway is API/header-driven by design (OpenAI-compatible endpoint, JSON-based dynamic routing config, header-based controls like cf-aig-cache-status and cf-aig-collect-log), which naturally supports headless/programmatic use in scripts or CI pipelines. However, there is no explicit documentation of CI/CD integration, automation examples, or a CLI for pipeline use. Missing for 10: explicit CI/CD workflow examples, dedicated CLI/SDK for automation, documented non-interactive auth/setup flow for pipelines.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “The \`cf-aig-collect-log\` header allows you to bypass the default log setting for the gateway.”
   • [claimed-docs] “To check whether a response comes from cache or not, **cf-aig-cache-status** will be designated as `HIT` or `MISS`.”

   proof ↗⚑ flag

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

   weight 3 · round to OpenRouter
   OpenRouter✓fullprobed8/10

   OpenRouter publishes an official MCP server that lets AI assistants/agents connect and pull live OpenRouter data (models, prices, credits, rankings, docs) directly from within the editor, confirmed both in docs and via a live probe of the documentation page. Missing for 10: independent/hands-on community validation of the MCP server's real-world reliability beyond first-party docs.

   • [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”
   • [claimed-docs] “The **OpenRouter MCP server** plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter da…”
   • [claimed-docs] “Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages…”
   • [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   Cloudflare AI Gateway is a proxy/gateway for routing and observing LLM API calls; the evidence pack contains no mention of an MCP server, MCP protocol, or agent connectivity via MCP. This is an applicable axis (a gateway product could plausibly ship an MCP server for agentic access) but no evidence supports it.

   ⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   OpenRouter—none0/10

   OpenRouter is an API/model-routing platform for which an official CLI would be a plausible ecosystem tool, but the evidence pack contains no mention of any official OpenRouter CLI — only SDK compatibility, REST API, MCP server, and web UI are documented.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   No evidence in the pack mentions an official CLI for AI Gateway (e.g., Wrangler or a dedicated AI Gateway CLI); all evidence covers dashboard, API headers, and configuration features. missing for 10: any mention of a CLI tool, command-line usage, or CLI-based configuration for AI Gateway.

   ⚑ flag

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

   weight 3 · round to OpenRouter
   OpenRouter✓fullprobed10/10

   OpenRouter is fundamentally an API product: extensive first-party docs cover the unified chat completions endpoint, streaming, tool calling, model routing/fallbacks, key management, and an OpenAPI spec plus a live, keyless /api/v1/models endpoint confirm a documented, programmatically accessible public API. Community evidence corroborates real-world programmatic use (switching models, key minting, billing caps) reinforcing that it is driven via API in production.

   • [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
   • [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
   • [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
   • [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullprobed7/10

   Cloudflare AI Gateway exposes a documented public API surface: an OpenAI-compatible /chat/completions endpoint, native provider passthroughs, a Universal endpoint for fallbacks, control headers (cf-aig-*), and a patchLog method for feedback/metadata, all described in first-party docs, and Cloudflare's platform-wide openapi.json confirms a machine-readable API schema exists. missing for 10: independent/hands-on third-party corroboration of API usage and a dedicated AI-Gateway-specific OpenAPI reference beyond the platform-wide one.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “Manage all your costs with one simple bill and access every provider through a single API.”
   • [claimed-docs] “The patchLog method allows you to send feedback, score, and metadata for a specific log ID.”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round to OpenRouter
   OpenRouter~partialcommunity7/10

   OpenRouter offers a documented Management API for creating/rotating API keys, workspace spend budgets, and per-key limits/expiry, which supports issuing distinct, capped credentials for agents (openrouter-docs-8, openrouter-docs-10, openrouter-comm-12, openrouter-comm-11). However, there's no explicit documentation of fine-grained scoping (e.g., restricting a key to specific models, tools, or actions) beyond spend caps, so 'least-privilege' is only partially realized. Missing for 10: explicit per-key model/tool/action scoping, granular permission controls beyond spend limits, and independent hands-on verification of the key-management API's robustness.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence pack covers AI Gateway's routing, caching, rate limiting, logging, and fallback features, but there is no mention of issuing scoped or least-privilege API credentials/tokens for agents (e.g., per-agent API keys with restricted permissions). Rate limiting and per-user/project quotas are traffic controls, not credential scoping mechanisms.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   OpenRouter~partialprobed5/10

   OpenRouter documents an OpenAI-compatible API and explicitly recommends using the OpenAI SDK as a drop-in replacement, plus offers an OpenAPI spec and request builder for generating client code, which supports building against it programmatically. However, there is no evidence of dedicated first-party OpenRouter SDK packages (e.g., official Python/Node/Go libraries) beyond OpenAI SDK compatibility. Missing for 10: dedicated official multi-language SDKs, independent developer corroboration of SDK usage (only OpenAI-SDK compatibility and generic API docs are cited).

   • [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
   • [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed5/10

   AI Gateway is compatible with OpenAI-style SDKs and providers' native APIs (via the OpenAI-compatible /chat/completions endpoint and native API pass-through), and Workers AI bindings imply SDK-like integration, but the evidence pack never explicitly names or documents an official Cloudflare AI Gateway SDK for major languages (e.g., a dedicated 'cloudflare-ai-gateway' npm/python package) with API references. missing for 10: explicit official SDK documentation/package listing, multi-language SDK examples, independent confirmation of SDK reliability/maintenance.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”
   • [claimed-docs] “gateway: { id: "my-gateway", },”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   OpenRouter—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms of any kind for OpenRouter; the documented features (routing, caching, key management, MCP server) do not include webhook support.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   No evidence in the pack mentions webhooks or any event-subscription mechanism; AI Gateway's documented features are logging, caching, rate limiting, fallbacks, and dynamic routing, none of which describe outbound webhook notifications for events. This is a plausible axis for a gateway product (it could offer webhook callbacks on events like errors or budget thresholds), so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

Api quality

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

   weight 2 · round to OpenRouter
   OpenRouter✓fullprobed8/10

   OpenRouter's docs explicitly mention an interactive Request Builder for generating API requests in any language, plus a live OpenAPI spec is served and confirmed by probe, and the docs site is extensively organized with runnable-style examples across guides. Missing for 10: X, Y — no independent/hands-on account of actually running the interactive Request Builder or evidence of embedded runnable code sandboxes beyond the Request Builder claim.

   • [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   Evidence shows only static documentation pages with code snippets and an openapi.json file, but no interactive API reference, playground, or runnable-example explorer is described anywhere in the pack.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Better yet - it only takes one line of code to get started.”
   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”

   proof ↗⚑ flag

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

   weight 2 · round to OpenRouter
   OpenRouter✓fullprobed9/10

   A probe confirms https://openrouter.ai/openapi.json returns HTTP 200 with an actual "openapi" key, giving a downloadable machine-readable OpenAPI spec, and docs also mention an interactive Request Builder and llms.txt for AI-native consumption. missing for 10: independent/community confirmation that the spec is actively used or kept in sync with the API by third-party developers.

   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
   • [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullprobed8/10

   Cloudflare publishes a machine-readable OpenAPI spec at a public, verifiable endpoint (openapi.json containing an 'openapi' key), covering the Cloudflare API including AI Gateway configuration/management endpoints, plus an llms.txt for AI-native discovery. missing for 10: no dedicated AI-Gateway-specific OpenAPI file (it's part of the broader Cloudflare API spec) and no independent/community confirmation of completeness.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   OpenRouter—none0/10

   OpenRouter's evidence describes production routing, billing, BYOK, and caching features but nothing about a sandbox/test environment isolated from production data or billing. The keyless models endpoint (openrouter-probe-4) only exposes a public catalog, not an isolated test mode for requests. No documentation of test/staging keys, sandbox mode, or non-production data isolation exists in the pack.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   No evidence of a sandbox/test environment feature separate from production; AI Gateway docs focus on routing, caching, rate limiting, logging, and fallbacks, with no mention of a sandbox mode or test-data isolation from production.

   ⚑ flag

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

   weight 2 · round drawn
   OpenRouter—none0/10

   The evidence pack covers routing, fallbacks, caching, BYOK, key management, and privacy settings, but nowhere documents API versioning (e.g., v1/v2 endpoints) or a formal deprecation policy/timeline for endpoints or models. The 'latest alias' for models is about model freshness, not API version stability guarantees.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   Evidence covers AI Gateway's features (caching, rate limiting, fallbacks, logging) but nowhere mentions API versioning schemes or a documented deprecation policy for the AI Gateway API itself; the openapi.json probe confirms an API spec exists but says nothing about version lifecycle or deprecation commitments. Missing for 10: explicit versioning scheme documentation, deprecation policy/timeline, changelog or migration guides for breaking changes.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   OpenRouter—none0/10

   The evidence pack shows OpenRouter provides a single-request API, model routing/fallbacks, and programmatic key management, but there is no documentation of a batch/bulk inference endpoint or any mechanism to submit many items/prompts in one bulk operation. missing for 10: batch API or bulk job submission endpoint, evidence of processing many items in a single call, bulk data/export operations.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence pack covers per-request features (rate limiting, caching, fallbacks, logging, dynamic routing) but contains no mention of bulk or batch operations across multiple items (e.g., batch API calls, bulk config management, or multi-item processing).

   ⚑ flag

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

   weight 3 · round to Cloudflare AI Gateway
   OpenRouter—none0/10

   OpenRouter is an LLM routing/API gateway; nothing in the evidence describes user-defined event-driven rules or triggers (e.g., webhooks, if-this-then-that automations) that fire actions automatically. Model fallback and provider routing are static request-time configs, not event-triggered automation rules.

   ⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway supports rule-based automation like dynamic routing that evaluates conditions and triggers fallback/model-switching actions, rate limiting, and cache overrides via headers, which are event-triggered automated behaviors. However, this is narrowly scoped to request routing/traffic control rather than a general-purpose 'define custom rules that trigger arbitrary actions on events' system (e.g., no evidence of user-defined triggers for alerts, webhooks, or custom workflows beyond routing/fallback/caching/rate-limits). missing for 10: evidence of arbitrary custom event-action rule definitions (e.g., webhook/alert triggers on thresholds), independent/hands-on corroboration of dynamic routing behavior, and confirmation of a general automation/rules engine beyond routing, caching, and rate limiting.

   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “Directing different segments (paid/not-paid user) to different models”
   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”
   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “Rate limiting controls the traffic that reaches your application, which prevents expensive bills and suspicious activity.”
   • [claimed-docs] “You can define rate limits as the number of requests that get sent in a specific time frame. For example, you can limit your application to …”

   proof ↗⚑ flag

Caching

1. developerCache responses at the gateway to cut cost and latency on repeated requests

   weight 2 · round to Cloudflare AI Gateway
   OpenRouter✓fullclaimed7/10

   OpenRouter's docs explicitly describe gateway-level response caching that returns cached results with zero billable usage (cutting cost) and near-instant latency, plus provider sticky routing specifically designed to maximize cache hit rates on subsequent requests. This directly matches the story's ask for gateway-side caching to reduce cost/latency on repeated calls. Missing for 10: independent or hands-on community confirmation that caching actually reduces cost/latency in practice, and more detail on cache TTL/configurability beyond the sticky-routing mechanism.

   • [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
   • [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
   • [claimed-docs] “OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a cached request.”
   • [claimed-docs] “OpenRouter uses **provider sticky routing** to route your subsequent requests to the same provider endpoint after a cached request.”
   • [claimed-docs] “To maximize cache hit rates, OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed9/10

   Docs clearly describe gateway-level caching that serves responses from Cloudflare's cache instead of calling the model provider (cost/latency savings), with per-request header overrides and a cf-aig-cache-status HIT/MISS indicator for verification. Missing for 10: independent/hands-on benchmark corroborating actual latency/cost savings.

   • [claimed-docs] “Serve requests directly from Cloudflare's cache instead of the original model provider for faster requests and cost savings.”
   • [claimed-docs] “AI Gateway allows you to override default cache behaviors on a per-request basis using specific HTTP headers.”
   • [claimed-docs] “To check whether a response comes from cache or not, **cf-aig-cache-status** will be designated as `HIT` or `MISS`.”

   proof ↗⚑ flag

Latency

1. platform engineerRun traffic through gateway infrastructure that adds minimal latency overhead to provider calls

   weight 2 · round to OpenRouter
   OpenRouter~partialcommunity5/10

   OpenRouter's docs describe latency-reducing features (response caching bypasses billing and reduces latency, sticky routing to maximize cache hits, load-balanced provider selection, streaming support) that imply a gateway designed for low overhead, but there is no explicit benchmark or first-party claim quantifying the gateway's own latency overhead versus direct provider calls. Community feedback is mixed—some praise ease of switching models and reliability (comm-2), while others report unexplained inconsistency and debugging difficulty (comm-8)—but none of this directly measures gateway latency overhead. Missing for 10: quantified latency-overhead benchmarks (vendor or independent), explicit performance comparison vs. direct provider calls, and hands-on latency testing evidence.

   • [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
   • [claimed-docs] “OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a cached request.”
   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
   • [community] “I had consistent problems (5 months back) with OpenRouter and other providers. And very hard to debug. I used the provider directly (Google)…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence pack documents caching, rate limiting, fallbacks, and analytics features but contains no benchmarks, latency figures, or explicit claims about the gateway's own processing overhead added to provider calls. Caching (docs-4, docs-31) improves speed only for cache hits and says nothing about baseline pass-through latency. Missing for 10: any latency benchmark, p50/p99 overhead numbers, or first-party/independent claim that the proxy adds minimal delay to non-cached requests.

   • [claimed-docs] “Serve requests directly from Cloudflare's cache instead of the original model provider for faster requests and cost savings.”
   • [claimed-docs] “To check whether a response comes from cache or not, **cf-aig-cache-status** will be designated as `HIT` or `MISS`.”

   proof ↗⚑ flag

Agent guardrails

1. ai-native userGive an autonomous agent its own key with budget and rate guardrails so it cannot run away on spend

   weight 2 · round to OpenRouter
   OpenRouter✓fullcommunity8/10

   OpenRouter supports programmatic API key management (creation, per-key limits/expiry) and workspace-level budget caps (daily/weekly/monthly/lifetime) that auto-block requests once reached, directly enabling an agent to be given its own scoped key with hard spend guardrails; community confirms billing caps and per-key limits are a valued differentiator. missing for 10: explicit per-key rate-limit (requests/sec) controls beyond spend caps, and independent hands-on verification that runaway agent spend is actually blocked in practice.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed5/10

   AI Gateway's dynamic routing explicitly supports 'restricting each user/project/team with budget/rate limits' and its rate-limiting feature lets you cap requests per time window (fixed/sliding), which maps to giving an agent bounded spend/rate guardrails when configured as its own route/project. However, the evidence never describes issuing a distinct API key per agent tied to a dollar-denominated budget cap — the mechanism shown is request-count rate limiting plus routing-level quotas, not a native 'agent key + $ budget' guardrail. missing for 10: explicit per-agent key issuance, dollar-based spend caps (not just request counts), and independent confirmation the budget/rate restriction in dynamic routing enforces hard spend caps.

   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “Rate limiting controls the traffic that reaches your application, which prevents expensive bills and suspicious activity.”
   • [claimed-docs] “You can also select if you would like a **fixed** or **sliding** rate limiting technique.”
   • [claimed-docs] “You can define rate limits as the number of requests that get sent in a specific time frame. For example, you can limit your application to …”
   • [claimed-docs] “Control how your application scales by limiting the number of requests your application receives.”
   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”

   proof ↗⚑ flag

Budgets

1. platform engineerSet hard budgets and spend limits per key, team, or user

   weight 3 · round to OpenRouter
   OpenRouter~partialcommunity6/10

   OpenRouter's docs clearly show hard, auto-enforced 'workspace budgets' with configurable daily/weekly/monthly/lifetime dollar caps that block requests once reached (openrouter-docs-10), covering team-level budgets. Per-key limits are only supported by an informal community mention of 'expiry/limits per key' (openrouter-comm-12, openrouter-comm-11) rather than first-party documentation, and per-user budget controls are not evidenced at all. Missing for 10: official docs confirming per-key hard spend limits, explicit per-user budget/quota controls, and independent verification of enforcement.

   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed5/10

   AI Gateway supports rate limiting per app/gateway and dynamic routing docs mention 'restricting each user/project/team with budget/rate limits,' but there's no dedicated documentation on setting a hard dollar spend cap or budget limit per API key, team, or user that blocks requests once exceeded — the budget/rate-limit reference is a single bullet without configuration detail. missing for 10: dedicated budget-limit configuration docs (dollar-amount caps), per-key/per-user budget enforcement examples, and evidence of automatic cutoff/alerting when a hard budget is reached.

   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “You can define rate limits as the number of requests that get sent in a specific time frame. For example, you can limit your application to …”
   • [claimed-docs] “Rate limiting controls the traffic that reaches your application, which prevents expensive bills and suspicious activity.”
   • [claimed-docs] “Control how your application scales by limiting the number of requests your application receives.”

   proof ↗⚑ flag

Spend tracking

1. platform engineerTrack spend per model, key, team, or user across all providers in one place

   weight 3 · round drawn
   OpenRouter~partialcommunity6/10

   OpenRouter provides key management (creation, limits per key), workspace budgets with dollar caps by interval, and BYOK cost control, plus community confirmation of billing caps and per-key limits — but the evidence pack lacks explicit documentation of a unified spend dashboard broken down by model, team, or user across providers in one place. missing for 10: consolidated analytics/dashboard showing spend segmented by model, by team, and by individual user; documentation of team-level spend attribution; independent confirmation of cross-provider spend reporting granularity.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway logs per-request cost, tokens, provider, and model, and supports dynamic routing with per-user/project/team budget and rate limits, giving a foundation for spend tracking across providers in one dashboard. However, there is no explicit evidence of built-in aggregated spend dashboards or reports broken down by 'team' or 'user' as first-class filters/rollups, or per-API-key spend attribution beyond raw logs. missing for 10: dedicated cost-aggregation/reporting UI by team/user/key, evidence of budget alerts tied to spend thresholds, independent/hands-on confirmation of cross-provider spend rollups.

   • [claimed-docs] “View metrics such as the number of requests, tokens, and the cost it takes to run your application.”
   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “Your AI Gateway dashboard shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status,…”
   • [claimed-docs] “Manage all your costs with one simple bill and access every provider through a single API.”

   proof ↗⚑ flag

Byok

1. developerBring my own provider API keys and have the gateway use them for my traffic

   weight 2 · round to OpenRouter
   OpenRouter✓fullcommunity9/10

   OpenRouter's docs explicitly describe BYOK (bring your own provider keys), letting developers use their own provider API keys for direct control over rate limits and costs, and this is corroborated by community testimony citing consolidated billing/key management as a core benefit. Missing for 10: independent hands-on verification specifically of BYOK traffic routing (most community evidence discusses OpenRouter credits/key management generally rather than BYOK specifically).

   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK). ... Using provider keys enables direct co…”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK).”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed8/10

   Docs confirm AI Gateway proxies requests to providers using the developer's own API key (e.g. 'Switch providers by changing the model and apiKey parameters' and passthrough pricing with no markup, meaning the developer's own provider account/key is billed directly), and it connects to native provider APIs and OpenAI-compatible endpoints for many providers. missing for 10: no explicit first-party doc section titled 'bring your own key' explaining storage/security of BYO keys, and no independent/hands-on confirmation of this exact flow.

   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “Inference pricing from providers is passed through with no markup — you pay the same per-token rates as you would directly with the provider…”
   • [claimed-docs] “Workers AI, Anthropic, Google Gemini, OpenAI, Replicate, and more work with AI Gateway.”
   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”

   proof ↗⚑ flag

Programmatic admin

1. ai-native userProvision gateways, keys, and budgets programmatically through an admin API

   weight 3 · round to OpenRouter
   OpenRouter~partialcommunity6/10

   OpenRouter documents a management API for provisioning and rotating API keys programmatically (openrouter-docs-8) and community users confirm the ability to mint/limit keys (openrouter-comm-12, openrouter-comm-11). Workspace budgets are documented as a feature to cap spend (openrouter-docs-10), but the evidence doesn't explicitly confirm budgets are settable via the same admin API, and there's no mention of provisioning 'gateways' as a distinct programmable resource. Missing for 10: explicit API endpoint documentation for setting/adjusting workspace budgets programmatically, and any concept of provisioning separate 'gateways' via API.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialprobed4/10

   Docs show gateways can be identified/configured programmatically (e.g., gateway id in code) and budgets/rate limits can be set via JSON-based dynamic routing config, suggesting some programmatic provisioning, and Cloudflare's general openapi.json exists. However there is no explicit documentation of an admin API for creating gateways, issuing/rotating API keys, or setting budgets outside the dashboard/JSON routing config. Missing for 10: explicit AI Gateway REST/GraphQL API endpoints for gateway CRUD, key provisioning, and budget management with request/response examples.

   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”
   • [claimed-docs] “gateway: { id: "my-gateway", },”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Virtual keys

1. platform engineerMint gateway-managed keys for teams and apps without exposing raw provider keys

   weight 3 · round to OpenRouter
   OpenRouter✓fullcommunity8/10

   OpenRouter's docs explicitly describe programmatic key management endpoints for creating/managing/rotating API keys for apps without exposing provider keys (docs-8), backed by BYOK for provider key control (docs-9/24/32) and workspace budgets to cap spend per workspace/team (docs-10). Community corroborates ease of minting and limiting keys (comm-12, comm-11). Missing for 10: independent verification of team/app-scoped key isolation guarantees and no first-hand platform-engineer account of using the management API at scale.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
   • [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence covers rate limiting, dynamic routing, fallbacks, caching, and logging, but nowhere describes a mechanism for minting gateway-managed keys that abstract or hide raw provider API keys for teams/apps.

   ⚑ flag

Integrations

1. developerExport gateway logs and traces to my own observability stack

   weight 1 · round drawn
   OpenRouter—none0/10

   Evidence pack shows OpenRouter's API gateway features (routing, fallbacks, caching, key management, privacy settings) but contains no mention of exporting logs/traces, webhooks, log streaming, or integration with observability stacks like Datadog, OpenTelemetry, or similar. missing for 10: log/trace export mechanism, OpenTelemetry or webhook integration, documentation of any observability-stack connector.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   Evidence describes Cloudflare's own dashboard logging, metrics, and header-based controls for log collection (e.g., cf-aig-collect-log, patchLog), but there is no mention of exporting logs/traces to an external observability stack (e.g., via Logpush, webhook, or third-party integration).

   ⚑ flag

Logs

1. platform engineerInspect logged requests and responses with latency, token counts, and cost attached

   weight 3 · round to Cloudflare AI Gateway
   OpenRouter—none0/10

   The evidence pack covers routing, caching, BYOK, budgets, and key management, but contains no mention of a request/response log viewer, latency dashboards, or per-request token/cost breakdowns that a platform engineer could inspect. missing for 10: activity/logs dashboard documentation, per-request latency metrics, per-request token count and cost attribution evidence.

   ⚑ flag

   Cloudflare AI Gateway✓fullclaimed9/10

   Docs explicitly state the dashboard shows per-request logs including user prompt, model response, provider, timestamp, status, token usage, cost, duration, and user agent, plus aggregate metrics for requests/tokens/cost. This directly matches the story's requirement to inspect logged requests/responses with latency, token counts, and cost. Missing for 10: independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Your AI Gateway dashboard shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status,…”
   • [claimed-docs] “View metrics such as the number of requests, tokens, and the cost it takes to run your application.”
   • [claimed-docs] “Create comprehensive monitoring and alerting systems using AI Gateway's rich logging and metrics data.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   OpenRouter~partialprobed6/10

   OpenRouter's core capabilities—model routing, fallbacks, provider selection, key management, workspace budgets, privacy settings, and even the model catalog—are all documented as programmatically accessible via the API (openrouter-docs-8, 10, 12, 21, 35, openapi.json probe), suggesting strong API/UI parity for a product that is API-first. However, there's no explicit vendor claim of full UI-API parity, and dashboard-only features like rankings/analytics visualizations aren't confirmed as API-exposed. Missing for 10: explicit parity statement, evidence that UI-exclusive features (e.g., rankings, usage analytics dashboards) are also fully API-accessible, and independent confirmation from hands-on API users of complete feature parity.

   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
   • [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
   • [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
   • [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
   • [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialprobed6/10

   AI Gateway configuration such as caching, rate limiting, fallbacks, and dynamic routing can be set via headers, API/JSON config, and the OpenAI-compatible endpoint, and an OpenAPI spec exists confirming broad API coverage. However, some features like dynamic routing are explicitly described as configurable via a 'visual interface' as an alternative to JSON, and there's no explicit confirmation that every dashboard capability (e.g., A/B rollouts, log feedback via patchLog, full analytics views) is fully API-exposed with parity to the UI. missing for 10: explicit statement of full UI/API parity, evidence that dashboard-only features (analytics visualizations, visual routing builder) have equivalent API endpoints, independent confirmation of complete parity.

   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “AI Gateway allows you to override default cache behaviors on a per-request basis using specific HTTP headers.”
   • [claimed-docs] “The \`cf-aig-collect-log\` header allows you to bypass the default log setting for the gateway.”
   • [claimed-docs] “The patchLog method allows you to send feedback, score, and metadata for a specific log ID.”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   OpenRouter—none0/10

   The evidence pack covers API routing, model access, MCP server, and billing features, but contains no mention of any user data export capability (usage logs, account data, chat history) in open formats or account portability/closure process — the axis is applicable to a SaaS platform storing usage/billing data, but no supporting evidence exists.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   Evidence pack covers logging, caching, fallback, rate-limiting, and routing features, but nowhere mentions a data export capability or open-format export/data portability for users leaving the platform. No documentation of bulk export, data download, or migration tooling is present.

   ⚑ flag

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

   weight 2 · round drawn
   OpenRouter—none0/10

   No evidence that OpenRouter's own source code (the API service, routing platform, or website) is published under an open license; evidence pack only covers API docs, features, and OpenAPI spec, not source availability. missing for 10: any repository link, open-source license file, or statement that OpenRouter's codebase is publicly available.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   Cloudflare AI Gateway is a closed, proprietary hosted service; the evidence pack contains only documentation and probes, with no mention of an open-source license or public source repository for the product itself.

   ⚑ flag

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

   weight 2 · round to OpenRouter
   OpenRouter~partialcommunity6/10

   OpenRouter documents EU/US in-region routing for enterprise customers and per-request/account-wide data-policy restrictions, giving users some control over where data is processed, but this is gated to enterprise accounts rather than available to all AI-native users, and community comments note there's no true ZDR/data-sovereignty guarantee in practice. missing for 10: general-tier (non-enterprise) region selection, independent verification that in-region routing works as claimed, and clarity on residency guarantees beyond enterprise contracts.

   • [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
   • [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
   • [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   No evidence in the pack mentions data residency, region selection, or data storage location controls for AI Gateway; only logging opt-out toggles for payload/prompt data are documented. This applicable privacy axis lacks any supporting evidence. missing for 10: region/residency selection settings, data localization guarantees, documentation on where logs/cache/metadata are stored.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to OpenRouter
   OpenRouter~partialcommunity6/10

   OpenRouter lets users restrict requests/account-wide to providers with certain data policies and opt out of routing to providers that may train on data, plus EU/US in-region processing for enterprise, which directly supports preventing training-data use; however community evidence notes there is 'no ZDR' (zero data retention) and 'no true guarantees of ZDR/privacy/data sovereignty,' indicating limits to how absolute this protection is. missing for 10: independent verification that opt-out settings are consistently honored by all providers, clarity on default behavior, and resolution of the ZDR gap raised by users.

   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
   • [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy.”
   • [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
   • [community] “No ZDR. No dice.”
   • [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence shows AI Gateway can control its own logging/storage of prompts (e.g., disabling payload logging) but nothing indicates it can prevent downstream AI providers from using submitted data to train their models — that policy is controlled by the provider (OpenAI, Anthropic, etc.), not by the gateway. No documentation ties Cloudflare's logging controls to opting out of provider-side training use.

   • [claimed-docs] “This is useful when you want to maintain visibility into usage metrics and request metadata without persisting sensitive prompt or completio…”
   • [claimed-docs] “Protect your AI applications from leaking or sending sensitive information.”
   • [claimed-docs] “The `cf-aig-collect-log-payload` header allows you to control whether the raw request and response bodies (payloads) are stored for a given …”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Cloudflare AI Gateway
   OpenRouter~partialcommunity5/10

   OpenRouter lets users restrict routing to providers with certain data policies (e.g. no-training, zero-retention) both per-request and account-wide, and offers EU/US in-region processing for enterprise, which are real retention/data-policy controls. However there is no documented mechanism for deleting already-retained data or setting explicit retention periods, and community comments (e.g. 'No ZDR. No dice') indicate the zero-data-retention toggle has real-world limitations/gaps rather than full guaranteed retention control. Missing for 10: explicit data deletion/erasure endpoint, documented retention-period settings, and independent confirmation that ZDR/data-policy filters reliably cover all providers.

   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
   • [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
   • [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy.”
   • [community] “No ZDR. No dice.”
   • [community] “Since it's only discounted on the standard 'OpenAI,' non-ZDR route (old pricing on Azure), a lot of users won't see this benefit since many …”
   • [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway offers concrete controls relevant to data retention: per-request headers to bypass logging (cf-aig-collect-log) or exclude storing raw prompt/completion payloads (cf-aig-collect-log-payload), letting users limit what sensitive data is persisted. However, there's no documented data deletion mechanism, retention period/TTL settings, or bulk/account-level data purge capability. missing for 10: explicit data retention duration controls, a documented deletion/purge workflow for stored logs, and independent confirmation that opt-out headers fully prevent persistence.

   • [claimed-docs] “This is useful when you want to maintain visibility into usage metrics and request metadata without persisting sensitive prompt or completio…”
   • [claimed-docs] “The \`cf-aig-collect-log\` header allows you to bypass the default log setting for the gateway.”
   • [claimed-docs] “The `cf-aig-collect-log-payload` header allows you to control whether the raw request and response bodies (payloads) are stored for a given …”
   • [claimed-docs] “Your AI Gateway dashboard shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status,…”

   proof ↗⚑ flag

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

   weight 2 · round to Cloudflare AI Gateway
   OpenRouter~partialcommunity4/10

   OpenRouter documents privacy controls—restricting requests to providers with certain data policies, disallowing providers that may train on your data, and EU/US in-region routing for enterprise—which give users some control over how their prompt data is handled downstream, but this is about provider-side data handling, not an explicit opt-out of OpenRouter's own telemetry/usage tracking. Community evidence directly notes 'No ZDR. No dice' and 'no true guarantees of ZDR/privacy/data sovereignty,' indicating real limits on data-handling assurances. Missing for 10: an explicit telemetry/usage-tracking opt-out toggle for OpenRouter's own platform analytics, and independent confirmation that opting out actually stops tracking.

   • [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
   • [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
   • [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
   • [community] “No ZDR. No dice.”
   • [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed5/10

   AI Gateway exposes per-request headers (cf-aig-collect-log, cf-aig-collect-log-payload) that let a user bypass logging or avoid storing raw prompt/completion payloads, and docs note this is 'useful when you want to maintain visibility into usage metrics... without persisting sensitive prompt or completion data.' However, these are opt-outs for log/payload storage only, not for the underlying usage/metrics tracking (tokens, cost, request counts) that the gateway inherently collects for billing and rate limiting. missing for 10: a global/account-level telemetry opt-out toggle, documentation of disabling usage-metrics tracking entirely, independent confirmation that opting out actually stops Cloudflare-side usage tracking.

   • [claimed-docs] “The \`cf-aig-collect-log\` header allows you to bypass the default log setting for the gateway.”
   • [claimed-docs] “The `cf-aig-collect-log-payload` header allows you to control whether the raw request and response bodies (payloads) are stored for a given …”
   • [claimed-docs] “This is useful when you want to maintain visibility into usage metrics and request metadata without persisting sensitive prompt or completio…”
   • [claimed-docs] “Your AI Gateway dashboard shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status,…”

   proof ↗⚑ flag

Fallbacks

1. platform engineerConfigure automatic fallback to another model or provider when one fails

   weight 3 · round drawn
   OpenRouter✓fullcommunity9/10

   OpenRouter documents explicit model fallback via a priority-ordered `models` array that auto-retries the next model on error, plus provider-level fallback/load balancing across top providers, and community confirms this works ('They also support fallback by default so you don't have to write wrappers'). This directly matches the platform engineer's story of configuring automatic fallback across models/providers on failure. Missing for 10: independent quantitative reliability data or a documented edge-case failure of the fallback mechanism itself.

   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed9/10

   Cloudflare AI Gateway explicitly documents automatic fallback to another model or provider on request errors or timeouts via the Universal endpoint, with clear examples (e.g., Workers AI failing over to OpenAI) and a response header (cf-aig-step) to identify which step succeeded. This is a well-documented, first-party feature with configuration details and dynamic routing support for fallbacks. Missing for 10: independent/hands-on verification beyond vendor docs, and no evidence of fallback behavior nuances (e.g., latency impact, partial failure handling) from real-world usage.

   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “Specify model or provider fallbacks with your Universal endpoint to handle request failures and ensure reliability.”
   • [claimed-docs] “the response header `cf-aig-step` indicates which model successfully processed the request by returning the step number.”

   proof ↗⚑ flag

Load balancing

1. platform engineerLoad-balance traffic across providers, deployments, or keys by weight, latency, or cost

   weight 2 · round to OpenRouter
   OpenRouter✓fullcommunity7/10

   Docs show default load balancing across top providers, customizable provider routing (sort by price/throughput), and ordered model fallbacks, plus BYOK for provider-key control, corroborated by community mentions of built-in fallback behavior. Missing for 10: explicit documentation of weighted routing across specific API keys and independent benchmarks validating latency/cost-based routing performance in practice.

   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
   • [claimed-docs] “You can customize how your requests are routed using the provider object in the request body for Chat Completions.”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway supports dynamic routing (conditions, quotas, A/B/gradual rollouts, segment-based routing) and fallback chains across providers/models with sequential retry-on-error, but the evidence describes rule-based/conditional routing and ordered fallback sequences rather than true weighted, latency-based, or cost-based load balancing across providers/keys. missing for 10: explicit weighted traffic splitting, latency-based routing decisions, cost-based routing logic, and any independent/hands-on verification of these mechanisms.

   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “Directing different segments (paid/not-paid user) to different models”
   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “A/B and gradual rollouts while making it accessible to both developers and non-technical team members.”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”
   • [claimed-docs] “Specify model or provider fallbacks with your Universal endpoint to handle request failures and ensure reliability.”

   proof ↗⚑ flag

Policy routing

1. ai-native userMy agent can switch models mid-task by policy — cost, capability, or availability — through gateway routing rules

   weight 3 · round drawn
   OpenRouter✓fullcommunity8/10

   OpenRouter's docs and community evidence confirm model fallback lists (priority order, automatic retry on error/rate-limit/down), provider-selection routing rules, load balancing across providers, a 'latest' alias for staying current, and an auto-routing 'meta' model that picks capability-appropriate models to control cost — directly matching policy-based mid-task model switching by cost/capability/availability. missing for 10: no first-party documentation or hands-on evidence of dynamically switching models *within* a single in-flight task/conversation (vs. per-request fallback/config), and no independent benchmark validating routing-rule reliability in production.

   • [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
   • [claimed-docs] “a latest alias that always resolves to the newest OpenAI flagship model, so your code keeps using the freshest version without redeploying”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
   • [community] “One thing I really like about OpenRouter is their 'meta' model that automatically routes the prompt to an appropriately capable model. Saves…”
   • [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed8/10

   Cloudflare AI Gateway explicitly supports policy-driven model switching via Dynamic Routing (visual/JSON config for segment-based routing, budget/rate limits, A/B rollouts) and Fallbacks (automatic switch to another model/provider on error or timeout, with cf-aig-step header indicating which model handled the request). These directly satisfy switching by cost, capability, or availability without app code changes. missing for 10: independent/hands-on evidence of this working in production agent workflows, and explicit documentation of capability-based (not just error/availability-based) routing logic.

   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
   • [claimed-docs] “Directing different segments (paid/not-paid user) to different models”
   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “the response header `cf-aig-step` indicates which model successfully processed the request by returning the step number.”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “A/B and gradual rollouts while making it accessible to both developers and non-technical team members.”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”
   • [claimed-docs] “Specify model or provider fallbacks with your Universal endpoint to handle request failures and ensure reliability.”

   proof ↗⚑ flag

Rate limits

1. platform engineerSmooth provider rate limits by spreading traffic across keys and queuing or throttling requests

   weight 2 · round to Cloudflare AI Gateway
   OpenRouter~partialcommunity5/10

   OpenRouter's default load balancing across providers and automatic model/provider fallbacks (docs-3,4,19) inherently smooths provider-side rate limits, and its key-management API (docs-8) plus BYOK (docs-9,24,32) let engineers create/distribute multiple keys with per-key limits (echoed by comm-12). But there is no explicit documentation of client-side request queuing or throttling, or of deliberately spreading traffic across multiple OpenRouter keys for load smoothing — the evidence covers provider-side resilience, not key-pool traffic shaping. Missing for 10: explicit queuing/throttling mechanism, documented multi-key load-balancing pattern, independent confirmation of rate-limit smoothing at scale.

   • [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
   • [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed6/10

   AI Gateway provides rate limiting (fixed/sliding, request-per-time-window) and fallback/retry to alternate providers/models, which helps smooth provider limits and errors, and dynamic routing can enforce per-user/team quotas. However, there is no explicit documentation of key rotation/spreading traffic across multiple API keys for the same provider, nor of a request queuing mechanism (rate limiting appears to reject/throttle rather than queue). missing for 10: explicit multi-key load balancing/rotation across provider keys, documented request queuing behavior (vs. simple throttling/rejection), independent evidence of this working at scale.

   • [claimed-docs] “Rate limiting controls the traffic that reaches your application, which prevents expensive bills and suspicious activity.”
   • [claimed-docs] “You can also select if you would like a **fixed** or **sliding** rate limiting technique.”
   • [claimed-docs] “You can define rate limits as the number of requests that get sent in a specific time frame. For example, you can limit your application to …”
   • [claimed-docs] “Control how your application scales by limiting the number of requests your application receives.”
   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “Specify model or provider fallbacks with your Universal endpoint to handle request failures and ensure reliability.”
   • [claimed-docs] “Restricting each user/project/team with budget/rate limits”
   • [claimed-docs] “you compose a small flow that evaluates conditions, enforces quotas, and chooses models with fallbacks. You can iterate without touching app…”

   proof ↗⚑ flag

Retries

1. platform engineerSet automatic retry policies for transient provider errors

   weight 2 · round to Cloudflare AI Gateway
   OpenRouter~partialcommunity7/10

   OpenRouter's model-fallbacks and provider load-balancing features automatically retry a request against alternate providers/models when the primary is down, rate-limited, or errors out, and this is corroborated by community reports of built-in fallback behavior (openrouter-docs-3, openrouter-docs-4, openrouter-docs-17, openrouter-docs-19, openrouter-comm-2). However, this is provider/model-level fallback rather than a granular, configurable retry policy (e.g., retry count, backoff intervals, specific transient-error codes) that a platform engineer might expect. Missing for 10: explicit retry-count/backoff configuration options, granular control over which transient error codes trigger retries, and independent verification of retry behavior under real outages.

   • [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
   • [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
   • [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”
   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed8/10

   Cloudflare AI Gateway explicitly supports request retries and fallbacks triggered by errors or timeouts (docs-7, docs-20, docs-33), with response headers indicating which step/model succeeded (docs-17). This directly satisfies automatic retry policies for transient provider errors. missing for 10: no evidence of configurable retry counts/backoff intervals specifically for 'retry' (vs fallback) and no independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Improve resilience by defining request retry and model fallbacks in case of an error.”
   • [claimed-docs] “Sends a request to Workers AI Inference API. 2. If that request fails, proceeds to OpenAI.”
   • [claimed-docs] “the response header `cf-aig-step` indicates which model successfully processed the request by returning the step number.”
   • [claimed-docs] “Cloudflare can trigger your fallback provider in response to request errors or predetermined request timeouts.”
   • [claimed-docs] “Specify model or provider fallbacks with your Universal endpoint to handle request failures and ensure reliability.”

   proof ↗⚑ flag

Streaming

1. developerStream token-by-token responses through the gateway from any provider

   weight 3 · round to OpenRouter
   OpenRouter✓fullcommunity8/10

   OpenRouter's docs explicitly state streaming is supported for any model through the gateway API, and community feedback corroborates using a single API/key across many providers with model switching in production. missing for 10: independent hands-on confirmation specifically of token-by-token streaming behavior (e.g., latency/chunking quality) and any provider-specific streaming caveats or limitations.

   • [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
   • [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
   • [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence describes AI Gateway as a proxy supporting multiple providers, an OpenAI-compatible /chat/completions endpoint, and native API pass-through, but nowhere explicitly confirms token-by-token streaming support or documents how streaming responses are handled through the gateway. missing for 10: explicit documentation or example of streaming/SSE support, confirmation that streaming works uniformly across all connected providers.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”

   proof ↗⚑ flag

Tool calling

1. developerRequest structured JSON-schema outputs across providers

   weight 1 · round drawn
   OpenRouter—none0/10

   The evidence pack covers tool-calling standardization, streaming, routing, fallbacks, and key management, but contains no mention of structured JSON-schema/response_format output support across providers. missing for 10: any documentation or example of JSON-schema response_format, schema validation, or structured output enforcement across providers.

   ⚑ flag

   Cloudflare AI Gateway—none0/10

   Cloudflare AI Gateway is a proxy/observability layer that passes requests through to native or OpenAI-compatible provider APIs; the evidence describes routing, caching, fallbacks, logging, and rate limiting, but nothing about enforcing or normalizing structured JSON-schema output across providers. Missing for 10: any mention of JSON-schema/response_format enforcement, schema validation, or cross-provider structured-output normalization.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”

   proof ↗⚑ flag

2. developerMake tool and function calls across different providers with a consistent schema

   weight 3 · round to OpenRouter
   OpenRouter✓fullcommunity8/10

   OpenRouter explicitly documents a standardized tool-calling interface across models/providers (docs-5), consistent with its single-API model access across 500+ models and providers (docs-1, docs-16), and community confirms using the same API key/request format to switch models seamlessly (openrouter-comm-2). Streaming is also documented as working across any model (docs-11/20), supporting the streaming-tools theme. Missing for 10: no independent hands-on verification specifically of function/tool-call schema consistency across multiple providers, and no detailed example showing identical tool-call JSON working unchanged across e.g. OpenAI vs Anthropic vs Google models.

   • [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
   • [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
   • [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
   • [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway~partialclaimed5/10

   AI Gateway provides an OpenAI-compatible /chat/completions endpoint and unified switching between providers via model/apiKey parameters, plus native API pass-through, which supports a consistent schema for chat-style requests across providers. However, the evidence never explicitly discusses tool/function-calling schema normalization (e.g., translating tool_call formats between Anthropic, Gemini, OpenAI, etc.) — it only covers general chat completion routing, caching, logging, and fallback headers. missing for 10: explicit documentation or examples of function/tool-call schema normalization across providers, evidence of consistent tool-call response parsing, and independent/hands-on confirmation that function calling works uniformly across all supported providers.

   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”
   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “Workers AI, Anthropic, Google Gemini, OpenAI, Replicate, and more work with AI Gateway.”

   proof ↗⚑ flag

Catalog

1. developerBrowse or query a catalog of available models with pricing and context-window metadata

   weight 2 · round to OpenRouter
   OpenRouter✓fullprobed9/10

   OpenRouter documents a browsable model catalog at openrouter.ai/models and a programmatic GET /api/v1/models endpoint listing model slugs, and a live probe confirms this endpoint returns 426 models with pricing/context-window metadata unauthenticated. Community feedback corroborates ease of comparing/switching models via the unified catalog. Missing for 10: no independent third-party review specifically validating completeness/accuracy of pricing or context-window fields beyond the probe.

   • [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
   • [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
   • [claimed-docs] “300T+ Monthly Tokens 10M+ Global Users 80+ Providers 500+ Models”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”

   proof ↗⚑ flag

   Cloudflare AI Gateway—none0/10

   The evidence pack shows AI Gateway supports multiple providers, per-token pricing pass-through, logging, caching, and routing, but there is no mention of a browsable/queryable catalog of models with pricing and context-window metadata—developers must know provider/model names themselves and check pricing docs separately (docs-16 only states pricing pass-through policy, not a queryable catalog).

   • [claimed-docs] “Workers AI, Anthropic, Google Gemini, OpenAI, Replicate, and more work with AI Gateway.”
   • [claimed-docs] “Inference pricing from providers is passed through with no markup — you pay the same per-token rates as you would directly with the provider…”

   proof ↗⚑ flag

Compatibility

1. developerPoint existing OpenAI-compatible code at the gateway by changing only the base URL and key

   weight 3 · round to OpenRouter
   OpenRouter✓fullprobed9/10

   Docs explicitly state the OpenAI SDK can be pointed at OpenRouter as a drop-in replacement, and community users corroborate using 'the same api key and same request' across models, confirming base-URL/key swap works in practice. Missing for 10: no explicit first-party code snippet showing the exact base_url/api_key change in the evidence pack, only the general drop-in claim.

   • [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
   • [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed8/10

   Docs confirm an OpenAI-compatible /chat/completions endpoint that allows switching providers by only changing model/apiKey parameters against a single URL, directly matching the story. missing for 10: independent/hands-on developer confirmation outside Cloudflare's own docs, and explicit example showing literal drop-in replacement of OpenAI SDK base_url with no other code changes.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”
   • [claimed-docs] “Manage all your costs with one simple bill and access every provider through a single API.”

   proof ↗⚑ flag

One endpoint

1. developerCall many model providers through one consistent API

   weight 3 · round drawn
   OpenRouter✓fullprobed9/10

   OpenRouter's core value proposition is a single API endpoint (OpenAI-SDK compatible) that routes to hundreds of models across 80+ providers, with fallback, load-balancing, standardized tool calling, and streaming for any model — corroborated by live probes (426-model catalog, openapi.json) and community testimonials confirming 'same API key and same request' across providers with automatic fallback. Minor gaps: community notes some inconsistencies (missing sampling params, occasional reliability complaints), missing for 10: fully independent benchmark of API consistency across all providers and resolution of reported debugging/latency complaints.

   • [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
   • [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
   • [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
   • [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
   • [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
   • [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
   • [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
   • [community] “It's definitely the best way to try out new models without fiddling with each providers distinct APIs. That said, I don't understand people …”

   proof ↗⚑ flag

   Cloudflare AI Gateway✓fullclaimed9/10

   Docs clearly show a unified OpenAI-compatible /chat/completions endpoint and a Universal endpoint that route to many providers (Workers AI, Anthropic, Gemini, OpenAI, Replicate, etc.) via consistent APIs, with model/provider switching via simple parameter changes and pass-through pricing. Missing for 10: independent/hands-on developer corroboration beyond first-party docs.

   • [claimed-docs] “Cloudflare's AI Gateway offers an OpenAI-compatible `/chat/completions` endpoint, enabling integration with multiple AI providers using a si…”
   • [claimed-docs] “Workers AI, Anthropic, Google Gemini, OpenAI, Replicate, and more work with AI Gateway.”
   • [claimed-docs] “This feature simplifies the integration process, allowing for seamless switching between different models without significant code modificat…”
   • [claimed-docs] “Switch providers by changing the \`model\` and \`apiKey\` parameters.”
   • [claimed-docs] “Connect to AI providers using their native API formats through AI Gateway.”
   • [claimed-docs] “Manage all your costs with one simple bill and access every provider through a single API.”

   proof ↗⚑ flag