Model Gateways & Routers Arena
Cloudflare AI Gateway vs Requesty
Cloudflare AI Gateway wins · 13–8 (20 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to RequestyCloudflare'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”
Requesty's docs site serves a working llms.txt (HTTP 200) with a structured index, plus .md variants of docs pages that explicitly point agents to llms.txt for the full documentation index, directly enabling an agent to be pointed at agent-oriented docs. missing for 10: no independent/third-party confirmation of agents actually consuming this successfully, and no dedicated docs page describing the llms.txt feature itself.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.requesty.ai/quickstart.md > ## Documentation Index > Fetch the complete documentation index at: http…”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round drawnAI 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`.”
Requesty is an OpenAI-compatible API gateway accessed via simple base_url swap, meaning any script or CI pipeline using the OpenAI SDK can call it headlessly without a UI, and BYOK/API-key auth supports non-interactive use. However, there is no explicit documentation or example showing CI/automation setup (e.g., GitHub Actions, headless auth flow, or CLI for pipelines). Missing for 10: explicit CI/automation docs or examples, headless auth/token provisioning guidance, independent confirmation of CI usage.
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
ai-native userConnect an agent via an official MCP server
weight 3 · round to RequestyCloudflare AI Gatewaynone0/10Cloudflare 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.
Requesty is a gateway/router (not itself an agent), and it documents an official 'MCP Gateway' that lets AI coding assistants like Claude Code, Cursor, and Roo Code securely connect to MCP servers through Requesty's unified API, directly matching the story. Missing for 10: independent/hands-on corroboration beyond first-party docs and more detail on setup/config specifics.
- [claimed-docs] “The MCP (Model Context Protocol) Gateway enables AI coding assistants like Claude Code, Cursor, and Roo Code to securely connect to MCP serv…”
- [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
ai-native userUse an official CLI
weight 2 · round drawnCloudflare AI Gatewaynone0/10No 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.
Requestynone0/10Requesty is presented as a unified LLM gateway/router with SDK compatibility and integrations (Claude Code, Cursor, etc.), but no evidence mentions an official Requesty CLI tool. Evidence only covers API routing, policies, MCP gateway, and dashboard features—no CLI is documented or probed.
ai-native userDrive the product through a documented public API
weight 3 · round to RequestyCloudflare 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”
Requesty exposes a documented, OpenAI-compatible public API (base_url swap, quickstart docs) plus a rich set of documented API-level features (fallback policies, load balancing, caching, structured outputs, BYOK) that let an AI-native user drive the product programmatically. missing for 10: an actual OpenAPI/swagger spec (probe found all candidate spec paths 404) and independent third-party corroboration of API robustness.
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnCloudflare AI Gatewaynone0/10The 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.
Requestynone0/10Requesty's docs mention BYOK (bringing your own provider keys), analytics, and 'centralized governance,' but there is no evidence of issuing scoped or least-privilege Requesty API keys/credentials specifically for individual agents. No mention of key scoping, permission levels, or per-agent credential issuance appears anywhere in the evidence pack.
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
ai-native userBuild against official SDKs
weight 2 · round drawnAI 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", },”
Requesty documents OpenAI-SDK compatibility (point the OpenAI SDK's base_url at Requesty) so developers can build using the OpenAI SDK's standard interfaces, but there is no evidence of a dedicated first-party Requesty SDK package (e.g., a requesty-python or requesty-node client) or SDKs for other languages beyond OpenAI-compatible clients. missing for 10: dedicated official Requesty-branded SDKs, multi-language SDK coverage, and independent confirmation of SDK maintenance/versioning.
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnCloudflare AI Gatewaynone0/10No 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'.
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnCloudflare AI Gatewaynone0/10Evidence 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…”
Requestynone0/10The evidence pack shows only markdown-based quickstart docs and code snippets; explicit probes for an OpenAPI/swagger spec all returned 404, and there is no mention of an interactive, runnable API reference or playground.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to Cloudflare AI GatewayCloudflare 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.
Requestynone0/10Requesty is an API/gateway product where a downloadable OpenAPI spec would be a natural and expected artifact, so the axis applies, but a direct probe found all candidate OpenAPI/swagger paths returning 404 and no docs page references a spec file. No first-party mention of an OpenAPI spec exists anywhere in the docs pack.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnCloudflare AI Gatewaynone0/10Evidence 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”
Requestynone0/10No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes all returned 404, and none of the docs mention version numbers, changelogs, or deprecation timelines.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnCloudflare AI Gatewaynone0/10The 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).
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnAI 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 …”
Requesty provides several automatic policy mechanisms that act as event-triggered rules: Fallback Policies automatically retry with different models on failure events, Load Balancing Policies route by defined weights, and Guardrails automatically scan/act on content before reaching a provider. These are rule-based automations tied to conditions/events, but they are fixed policy types rather than a general-purpose custom event/action rule engine that an AI-native user could freely define. Missing for 10: a general rules/automation builder allowing arbitrary custom triggers and actions beyond the predefined fallback/load-balancing/guardrail policy types, and independent evidence of this automation working in production.
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
Caching performance — stories about caching performance in this arenaCaching performance
Stories about caching performance in this arena
Caching
developerCache responses at the gateway to cut cost and latency on repeated requests
weight 2 · round to Cloudflare AI GatewayDocs 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`.”
Requesty documents automatic gateway-level caching of long system prompts and repeated content to reduce costs, with usage analytics tracking cache savings and latency in real-time, directly matching the story's intent. missing for 10: independent/hands-on benchmarks confirming actual latency/cost reduction, and detail on cache TTL/configurability.
- [claimed-docs] “Requesty's auto caching automatically caches long system prompts and repeated content to reduce costs on any provider that supports prompt c…”
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
Latency
platform engineerRun traffic through gateway infrastructure that adds minimal latency overhead to provider calls
weight 2 · round to RequestyCloudflare AI Gatewaynone0/10The 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`.”
Requesty is a gateway/router with caching, fallback, and analytics features that imply performance-conscious design, and analytics dashboard tracks latency, but there is no explicit benchmark or claim quantifying gateway-added latency overhead. missing for 10: published latency benchmarks or overhead numbers, independent performance testing, and any explicit low-latency architecture documentation.
- [claimed-docs] “Requesty's auto caching automatically caches long system prompts and repeated content to reduce costs on any provider that supports prompt c…”
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Cost controls — stories about cost controls in this arenaCost controls
Stories about cost controls in this arena
Agent guardrails
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 Cloudflare AI GatewayAI 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…”
Requestynone0/10Requesty is an LLM gateway product where issuing scoped API keys with spend/rate limits would be a natural and expected capability, but the evidence pack only shows BYOK (using your own provider keys), content-safety 'guardrails' (sensitive-data scanning, not spend limits), and usage analytics dashboards for visibility — none of which describe issuing an agent its own key with a budget cap or rate limit to prevent runaway spend.
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
Budgets
platform engineerSet hard budgets and spend limits per key, team, or user
weight 3 · round to Cloudflare AI GatewayAI 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.”
Requestynone0/10The evidence pack shows analytics/usage tracking and BYOK/governance mentions, but no documentation of setting hard budgets or spend limits per API key, team, or user. This is a plausible and expected axis for an LLM gateway product like Requesty, so absence of evidence yields 'none'.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Spend tracking
platform engineerTrack spend per model, key, team, or user across all providers in one place
weight 3 · round drawnAI 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.”
Requesty's analytics dashboard tracks costs, requests, tokens, cache savings, and latency across all models/providers in real-time, and trace_id/user_id tagging plus BYOK support per-key tracking, which covers most of the story. missing for 10: explicit documentation of per-team breakdowns/team-level grouping, per-user cost attribution dashboards, and independent/hands-on corroboration of the analytics dashboard's granularity beyond vendor docs.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Key management — stories about key management in this arenaKey management
Stories about key management in this arena
Byok
developerBring my own provider API keys and have the gateway use them for my traffic
weight 2 · round drawnDocs 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…”
Requesty explicitly documents a BYOK feature allowing developers to use personal API keys from various providers with the gateway, alongside the standard OpenAI-compatible routing setup. Missing for 10: independent/hands-on confirmation of BYOK working in practice and details on key storage/security guarantees.
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
Programmatic admin
ai-native userProvision gateways, keys, and budgets programmatically through an admin API
weight 3 · round to Cloudflare AI GatewayDocs 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”
Requestynone0/10No evidence of an admin API for programmatically provisioning gateways, keys, or budgets; docs cover BYOK (manual key entry), analytics dashboard, and routing policies, but nothing about API-driven account/key/budget provisioning. The OpenAPI/swagger probe returned 404 for all candidate paths, further indicating no discoverable admin API surface.
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
Virtual keys
platform engineerMint gateway-managed keys for teams and apps without exposing raw provider keys
weight 3 · round drawnCloudflare AI Gatewaynone0/10The 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.
Requestynone0/10Evidence covers BYOK (users supplying their own provider keys into Requesty) and general governance/analytics claims, but nothing describes an admin/platform-engineer flow for minting distinct gateway-managed keys per team or app that shield the underlying provider keys. Missing for 10: documentation of virtual/scoped key issuance, team/app-level key scoping, or key rotation/management APIs.
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Observability — seeing what the system is doing — logs, metrics, traces, alertsObservability
Seeing what the system is doing — logs, metrics, traces, alerts
Integrations
developerExport gateway logs and traces to my own observability stack
weight 1 · round drawnCloudflare AI Gatewaynone0/10Evidence 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).
Requestynone0/10Requesty documents an internal analytics dashboard for usage visibility, but there is no evidence of any export mechanism (webhooks, OpenTelemetry, log/trace export API, or third-party observability integrations like Datadog/Grafana) that would let a developer send gateway logs/traces to their own observability stack.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
Logs
platform engineerInspect logged requests and responses with latency, token counts, and cost attached
weight 3 · round to Cloudflare AI GatewayDocs 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.”
Requesty's analytics dashboard docs confirm tracking of costs, requests, tokens, cache savings, and latency in real-time, which covers most of the story, but there is no evidence of inspecting individual logged request/response payload content (bodies) rather than aggregate metrics. missing for 10: evidence of per-request log inspection with full request/response bodies, screenshots or independent corroboration of the dashboard UI, and confirmation of per-call cost/latency drill-down rather than aggregate analytics.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to Cloudflare AI GatewayAI 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”
Requesty's core inference path (chat completions, model routing) is fully API-driven via an OpenAI-compatible endpoint, and features like fallback/load-balancing policies, BYOK, and guardrails are described as usable at request time. However, there's no evidence of a management/admin API for configuring these policies, keys, or viewing analytics programmatically, and the OpenAPI spec probe returned 404s across all candidate paths, suggesting dashboard-only configuration for policy setup and analytics viewing. missing for 10: a documented admin/management API for configuring fallback policies, load balancing, guardrails, BYOK keys, and pulling analytics data programmatically; a published OpenAPI spec confirming full API parity with the dashboard.
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
ai-native userExport all of my data in open formats and leave
weight 3 · round drawnCloudflare AI Gatewaynone0/10Evidence 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.
Requestynone0/10The evidence pack covers routing, caching, guardrails, analytics dashboard, and pricing, but nothing describes exporting usage data, logs, or configuration in open formats or a data-portability/account-deletion path. This is a fair question for a gateway that stores analytics/usage data, so absence of evidence yields 'none' rather than 'na'.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
ai-native userRead the product's source under an open license
weight 2 · round drawnCloudflare AI Gatewaynone0/10Cloudflare 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.
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to RequestyCloudflare AI Gatewaynone0/10No 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.
Requesty offers an explicit EU-routing option (Frankfurt, AWS eu-central-1) keeping processing and storage within the EU, giving users some data-residency choice. However, evidence only shows one alternative region (EU vs default), not a broader set of selectable regions/residency options. Missing for 10: documentation of additional region choices (e.g., US-only, APAC), enterprise data-residency controls, and independent verification of enforcement.
- [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
ai-native userPrevent my data from being used to train AI models
weight 3 · round drawnCloudflare AI Gatewaynone0/10The 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 …”
ai-native userControl data retention and deletion
weight 2 · round to Cloudflare AI GatewayAI 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,…”
Requestynone0/10The evidence pack shows EU data-residency routing and guardrails for sensitive content scanning, but nothing about data retention periods, deletion controls, or user-initiated data purge/export mechanisms. Missing for 10: documented retention policy, deletion/erasure API or dashboard control, retention configuration options.
- [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
- [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round to Cloudflare AI GatewayAI 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,…”
Requestynone0/10The evidence pack shows analytics/usage dashboards and EU data routing but contains no mention of a telemetry/usage-tracking opt-out setting or privacy control for disabling data collection. As a hosted API gateway that logs requests, this is a fair axis to expect documentation on, but none is present.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
- [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
Routing resilience — stories about routing resilience in this arenaRouting resilience
Stories about routing resilience in this arena
Fallbacks
platform engineerConfigure automatic fallback to another model or provider when one fails
weight 3 · round to Cloudflare AI GatewayCloudflare 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.”
Requesty's Fallback Policies feature explicitly documents automatic retry to a different model/provider when the primary fails (timeout, rate limit, error), directly matching the story. Missing for 10: independent/hands-on corroboration beyond vendor docs and detail on configuration granularity (e.g., how fallback chains are set up in the dashboard/API).
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
Load balancing
platform engineerLoad-balance traffic across providers, deployments, or keys by weight, latency, or cost
weight 2 · round drawnAI 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.”
Requesty documents weight-based Load Balancing Policies that distribute requests across multiple models/providers, plus session affinity via trace_id/user_id, and separate Fallback Policies for failure-driven rerouting. However, there is no evidence of latency-based or cost-based load balancing—only weight is explicitly supported. missing for 10: latency-based routing/balancing, cost-based routing/balancing, explicit per-key (not just per-model/provider) balancing.
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
Policy routing
ai-native userMy agent can switch models mid-task by policy — cost, capability, or availability — through gateway routing rules
weight 3 · round drawnCloudflare 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.”
Requesty's gateway supports fallback policies (retry with different models on failure/rate limit/error), load-balancing policies (distribute across models by weight, sticky routing by trace/user), and access to 300+/600+ models via a single API, directly enabling policy-based mid-task model switching for cost, capability, or availability reasons. missing for 10: no independent/hands-on corroboration of dynamic policy switching in a live agent task, and no explicit example combining cost+capability+availability rules in one policy config.
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
- [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Rate limits
platform engineerSmooth provider rate limits by spreading traffic across keys and queuing or throttling requests
weight 2 · round to Cloudflare AI GatewayAI 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…”
Requesty's Fallback Policies explicitly retry on rate-limit errors by switching models, and Load Balancing Policies distribute requests across multiple models/providers by weight, which can smooth rate-limit pressure; BYOK lets users supply multiple provider keys. However, there is no documented queuing/throttling mechanism or explicit per-key round-robin/rate-limit-aware routing across multiple keys for the same provider. Missing for 10: explicit request queuing/throttling controls, documented multi-key rotation within a single provider, and rate-limit-specific load-balancing logic (vs. general failure retries).
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
- [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
Retries
platform engineerSet automatic retry policies for transient provider errors
weight 2 · round to Cloudflare AI GatewayCloudflare 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.”
Requesty's Fallback Policies explicitly retry requests on a different model when the primary fails due to timeout, rate limit, or error, which directly addresses transient provider errors. However, this is model-fallback rather than a configurable retry policy (e.g., retry counts, backoff intervals, retry-same-provider-first) explicitly for transient errors. missing for 10: documentation of configurable retry counts/backoff on the same provider before failover, independent/hands-on confirmation of retry behavior, and explicit mention of 'transient error' handling distinct from full model fallback.
- [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
- [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
Streaming tools — stories about streaming tools in this arenaStreaming tools
Stories about streaming tools in this arena
Streaming
developerStream token-by-token responses through the gateway from any provider
weight 3 · round to RequestyCloudflare AI Gatewaynone0/10The 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…”
Requesty claims full OpenAI-SDK compatibility with no code changes (drop-in base_url swap), which implies standard SDK streaming (stream=True) would work across any of its 300+ models, but no evidence pack item explicitly confirms streaming/token-by-token behavior or documents a streaming example. missing for 10: explicit streaming documentation/example, confirmation across multiple providers, and any independent/hands-on verification of streaming behavior.
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Tool calling
developerRequest structured JSON-schema outputs across providers
weight 1 · round to RequestyCloudflare AI Gatewaynone0/10Cloudflare 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.”
Requesty explicitly documents structured outputs, stating it makes 'every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode,' directly addressing cross-provider JSON-schema support via its unified OpenAI-compatible API. Missing for 10: independent/hands-on verification across multiple providers and no explicit list of which of the 300+ models fully honor strict schema enforcement.
- [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
developerMake tool and function calls across different providers with a consistent schema
weight 3 · round to RequestyAI 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.”
Requesty's OpenAI-compatible unified API (docs-1, docs-2, docs-16) implies that developers can use the same OpenAI SDK request format—including tool/function-call schema—across 300+/600+ models, and structured-outputs docs (docs-14) show JSON/schema-enforced output support across providers. However, there is no explicit documentation or example showing tool/function-call payloads being translated or normalized for non-OpenAI-native providers, nor any hands-on confirmation that function calling works uniformly across all providers. Missing for 10: explicit function/tool-calling schema documentation, cross-provider tool-call examples, and independent verification of consistent behavior across providers.
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
Unified api — stories about unified api in this arenaUnified api
Stories about unified api in this arena
Catalog
developerBrowse or query a catalog of available models with pricing and context-window metadata
weight 2 · round drawnCloudflare AI Gatewaynone0/10The 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…”
Requestynone0/10Evidence confirms Requesty routes across 300–600+ models via a unified API, but nothing in the pack documents a browsable/queryable model catalog exposing pricing or context-window metadata (no /models endpoint, no models page, and the OpenAPI probe returned 404s). missing for 10: a models catalog page or API endpoint, per-model pricing data, per-model context-window metadata.
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
- [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
Compatibility
developerPoint existing OpenAI-compatible code at the gateway by changing only the base URL and key
weight 3 · round drawnDocs 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.”
Docs explicitly show swapping only base_url (to router.requesty.ai/v1) and API key while keeping OpenAI SDK unchanged, directly matching the story. Missing for 10: independent/hands-on third-party confirmation beyond vendor docs and a formal OpenAPI spec (probe found 404s).
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
One endpoint
developerCall many model providers through one consistent API
weight 3 · round to Cloudflare AI GatewayDocs 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.”
Requesty is explicitly documented as an OpenAI-compatible unified API/gateway supporting 300+ (or 600+) models via a single base_url swap, with routing, fallback, load balancing, and BYOK across providers, all first-party documented and corroborated by an llms.txt probe describing it as a unified LLM gateway. Missing for 10: independent/hands-on third-party verification beyond docs, and no public OpenAPI spec found (404s on probe).
- [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
- [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
- [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
- [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is an LLM proxy/observability layer for routing, caching, rate-limiting and logging requests to model providers — it is not an agent that consumes tools, and there is no evidence of MCP server integration in the pack. This axis is a category error for this type of product.
Requesty's MCP Gateway explicitly lets AI coding assistants (Claude Code, Cursor, Roo Code) connect to MCP servers through Requesty's unified API, directly matching the story. missing for 10: deeper documentation on configuring specific MCP servers and independent/hands-on corroboration of the gateway working in practice.
- [claimed-docs] “The MCP (Model Context Protocol) Gateway enables AI coding assistants like Claude Code, Cursor, and Roo Code to securely connect to MCP serv…”
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is an infrastructure/observability layer for routing and monitoring calls to AI providers, not a product that surfaces AI-generated insights or suggestions from a user's own data. This story is a category error for this type of product.
Requestynone0/10Requesty's docs describe a real-time analytics dashboard for usage/cost/latency tracking, but nowhere is there evidence of AI-generated insights, recommendations, or suggestions derived from that data — the dashboard is purely observational reporting.
- [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
ai-native userSet up automations that run autonomously in the background
weight 2 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is a request-routing/observability proxy layer sitting between an application and LLM providers (caching, rate limiting, fallbacks, logging) — it processes calls reactively as they occur rather than running independent background automations. This axis (autonomous background automation) fits agent/automation platforms, not a gateway product, so it does not apply to this product category.
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is an infrastructure/proxy layer for routing, caching, logging and observability of AI API calls — it is not itself an AI assistant product with a built-in agent persona to delegate tasks to. This story applies to conversational/agentic assistant products, not to a gateway/middleware tool, making it a category mismatch.
ai-native userOperate the product with natural-language commands
weight 2 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is an infrastructure/proxy layer for routing, caching, logging and rate-limiting LLM API calls, configured via dashboard, JSON, or headers — it is not an interface a user interacts with via natural-language commands. This axis is a category error for a gateway/proxy product, not a missing feature.
ai-native userTest against a sandbox environment without touching production data
weight 1 · not comparableCloudflare AI Gatewaynone0/10No 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.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is a proxy/observability layer for AI API requests (caching, routing, rate limiting, fallbacks, logging); it is not a workflow/job scheduling product, so scheduling recurring jobs is a category error for this product type.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableDocs mention that dynamic routing lets you 'publish a new route version' without touching application code, implying some versioning of routing configs, but there is no documented review/diff interface or explicit rollback mechanism for automations. missing for 10: explicit rollback/undo functionality, change-review or diff UI, versioning of prompts/logic beyond routing config.
- [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] “Dynamic routing enables you to create request routing flows through a **visual interface** or a **JSON-based configuration**.”
- [claimed-docs] “A/B and gradual rollouts while making it accessible to both developers and non-technical team members.”
ai-native userSelf-host the core product
weight 3 · not comparableCloudflare AI Gatewayn/aCloudflare AI Gateway is a managed, hosted cloud service built into Cloudflare's edge network; there is no evidence of, or plausible path to, self-hosting the core product outside Cloudflare's infrastructure. Self-hosting is a category error for this SaaS/edge-service product type.