Model Gateways & Routers Arena
Vercel AI Gateway vs Requesty
Vercel AI Gateway
Vercel Inc.
Vercel AI Gateway wins · 23–10 (10 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 Vercel AI GatewayVercel confirms a live llms.txt (probe-1) plus per-page .md documentation endpoints (probe-2) and an OpenAPI spec (probe-3), all machine-readable for agent consumption, and docs explicitly mention coding-agent setup guidance (docs-8, docs-24). Missing for 10: no independent/community confirmation that agents actually use these llms.txt/docs successfully in practice.
- [probe] “PROBE llms.txt: HTTP 200 at https://vercel.com/llms.txt # Vercel > Vercel is a cloud platform for building, deploying, and scaling web appl…”
- [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs/ai-gateway.md --- title: AI Gateway product: vercel url: /docs/ai-gateway canonical_url: …”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [claimed-docs] “vercel ai-gateway coding-agents setup”
- [claimed-docs] “AI Gateway routes requests, manages fallbacks and budgets, monitors usage, and connects supported coding agents.”
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 to Vercel AI GatewayAI Gateway is an API/HTTP gateway with OpenAI-compatible endpoints, unauthenticated model listing, OIDC token auth for deployed apps, and a keyless models endpoint verified live — all of which support pure headless/CI/automation use without any UI dependency. missing for 10: no explicit CI pipeline example (e.g., GitHub Actions) or independent third-party report of CI usage.
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “For applications deployed on Vercel, OIDC tokens are automatically available as `VERCEL_OIDC_TOKEN`. No secrets to manage, no keys to rotate…”
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “For applications deployed on Vercel, OIDC tokens are automatically available as VERCEL_OIDC_TOKEN. No secrets to manage, no keys to rotate. …”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 userPlug MCP servers into this product so it can use their tools
weight 3 · round to RequestyVercel AI Gatewaynone0/10The evidence describes Vercel AI Gateway as a model-routing/proxy layer (provider switching, fallbacks, spend monitoring, caching, coding-agent connections) but contains no mention of MCP server integration or tool-use via MCP anywhere in the docs pack.
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 userConnect an agent via an official MCP server
weight 3 · round to RequestyVercel AI Gatewaynone0/10The docs mention connecting 'supported coding agents' and generic gateway integration, but there is no evidence of an official MCP (Model Context Protocol) server or endpoint that agents can connect to. Missing for 10: explicit MCP server documentation, MCP endpoint URL, and demonstration of an agent connecting via MCP.
- [claimed-docs] “vercel ai-gateway coding-agents setup”
- [claimed-docs] “AI Gateway routes requests, manages fallbacks and budgets, monitors usage, and connects supported coding agents.”
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 to Vercel AI GatewayThe only evidence of a CLI is the fragment 'vercel ai-gateway coding-agents setup', implying an official `vercel` CLI subcommand for configuring the AI Gateway with coding agents, but there is no detailed command reference, install instructions, or broader CLI documentation for AI-native workflows beyond this single mention. Missing for 10: full CLI command reference/docs, examples of CLI usage for model routing/config, independent confirmation of CLI functionality.
- [claimed-docs] “vercel ai-gateway coding-agents setup”
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 Vercel AI GatewayAI Gateway exposes a documented, OpenAI-compatible public API (Chat Completions, models endpoint) with a verified OpenAPI spec, unauthenticated models endpoint, and probe confirming a live JSON API response, enabling programmatic/agentic control via standard SDKs or raw HTTP. missing for 10: independent third-party developer writeups explicitly praising the API's completeness/stability beyond Vercel's own docs and probes.
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 to Vercel AI GatewayDocs show budget caps that can be set per API key, per project, or per team member (docs-16), and per-key usage breakdown in Requests logs (docs-12), plus short-lived OIDC tokens for Vercel-deployed apps that avoid static secrets (docs-14/22). This supports issuing distinct, budget-limited keys for an agent, but there is no documentation of fine-grained permission scoping (e.g. restricting a key to specific models/providers/actions) beyond spend limits. missing for 10: explicit least-privilege scoping controls (model/provider/action restrictions per key), role-based permission model, first-party or independent confirmation of true least-privilege agent credentials
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “For applications deployed on Vercel, OIDC tokens are automatically available as `VERCEL_OIDC_TOKEN`. No secrets to manage, no keys to rotate…”
- [claimed-docs] “For applications deployed on Vercel, OIDC tokens are automatically available as VERCEL_OIDC_TOKEN. No secrets to manage, no keys to rotate. …”
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 to Vercel AI GatewayAI Gateway is designed to be used via existing official SDKs (OpenAI client libraries, Anthropic SDK, Vercel AI SDK) with just a base URL/model-string change, documented in openai-compat and getting-started guides, and confirmed by a live OpenAI-compatible endpoint probe. It also supports agent-building primitives like ToolLoopAgent for agentic workflows. missing for 10: no independent/hands-on developer confirmation beyond vendor docs and one API probe.
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [claimed-docs] “Move existing OpenAI, Anthropic, and AI SDK integrations to AI Gateway with a base URL swap.”
- [claimed-docs] “const agent = new ToolLoopAgent({ model: 'anthropic/claude-sonnet-5', tools: { getWeather: tool({”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 drawnVercel AI Gatewaynone0/10No evidence anywhere in the pack of webhook subscriptions or event-driven notifications from AI Gateway; the product exposes REST APIs, logs, and observability dashboards, but nothing about webhooks for events like request completion, budget alerts, or failures.
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to Vercel AI GatewayThere's a documented OpenAPI spec and a live, keyless models endpoint that returns JSON model data, showing some interactive/runnable API surface, but there's no evidence of an interactive API reference UI (like Swagger/Redoc) with embedded runnable examples or a try-it-now console. missing for 10: an actual interactive API explorer/playground page, runnable code snippets embedded in docs, independent confirmation of a docs UI with live request execution.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
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 Vercel AI GatewayA probe confirms a live OpenAPI JSON spec at vercel.com/openapi.json (contains the 'openapi' key) and the docs also expose a keyless models JSON endpoint and OpenAI-compatible API, all of which are machine-readable and programmatically consumable. Missing for 10: explicit confirmation the openapi.json spec covers AI Gateway endpoints specifically (vs. general Vercel API) and independent third-party validation of the spec's completeness.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
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 drawnVercel AI Gatewaynone0/10Evidence shows an OpenAI-compatible endpoint with a 'v1' path and an openapi.json spec, but nowhere does the pack document an explicit API versioning scheme or a deprecation policy for endpoints/models. Missing for 10: explicit versioning strategy documentation, deprecation/sunset timelines, migration guidance for breaking changes.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
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 drawnVercel AI Gatewaynone0/10The evidence pack covers routing, failover, BYOK, observability, and embeddings, but there is no mention of any batch/bulk request API or capability to process many items in a single operation. Since a gateway product could plausibly offer batch endpoints (e.g., batch inference or bulk embeddings), the axis applies, but no evidence supports it being delivered.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to RequestyThe Gateway supports narrow built-in automation triggers — failover/retry on provider failure, per-provider timeouts triggering fast failover, and budget caps that block spend once a threshold is hit — which are rule-like actions triggered by events (docs-3, docs-10, docs-13, docs-16). However, there's no general-purpose, user-defined rules/event system (e.g., custom conditions, webhooks, arbitrary trigger-action pairs) for AI-native users to configure; the 'rules' are limited to routing, caching, and spend-cap logic. Missing for 10: a configurable rules engine for arbitrary events/actions, webhook or external-trigger support, and evidence of user-defined conditional automation beyond routing/budget defaults.
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “You can use order, only, and sort in providerOptions.gateway to control which providers handle your requests, in what order, and how they ar…”
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 RequestyDocs explicitly describe a `caching: 'auto'` option in providerOptions.gateway that lets the gateway apply provider-appropriate caching automatically, directly supporting cost/latency reduction on repeated requests, and community pricing discussion confirms cache-read pricing exists for at least one model. However, details on cache hit-rate guarantees, TTL, scope, or independent benchmarks of latency/cost savings are absent. Missing for 10: independent hands-on benchmarks showing latency/cost reduction, documentation on cache TTL/invalidation/scope, confirmation caching works uniformly across all providers rather than being provider-dependent.
- [claimed-docs] “You can use `caching: 'auto'` in `providerOptions.gateway` to let AI Gateway automatically apply the appropriate caching strategy based on t…”
- [claimed-docs] “You can use caching: 'auto' in providerOptions.gateway to let AI Gateway automatically apply the appropriate caching strategy based on the p…”
- [community] “Vercel cache read pricing for DeepSeek-v4: $0.01/M for flash, $0.14/M for pro — a 64% discount vs DeepSeek/OpenRouter on flash caching, prom…”
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 RequestyDocs show performance-related controls (per-provider timeouts for fast failover, sort-by-performance metric, automatic caching) that imply attention to latency, but there is no direct benchmark or explicit claim quantifying the gateway's own added latency overhead. Missing for 10: published latency benchmarks or first-party/independent measurements showing the gateway adds minimal overhead versus direct provider calls, and no community corroboration of low added latency.
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “You can also use `sort` to rank providers by a performance or cost metric. The gateway sorts providers by the chosen metric and tries them i…”
- [claimed-docs] “You can use `caching: 'auto'` in `providerOptions.gateway` to let AI Gateway automatically apply the appropriate caching strategy based on t…”
- [claimed-docs] “You can use caching: 'auto' in providerOptions.gateway to let AI Gateway automatically apply the appropriate caching strategy based on the p…”
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 Vercel AI GatewayDocs confirm you can create per-API-key budgets and view spend/usage broken out by API key (docs-16, docs-12, docs-5), which supports giving an agent its own key with a spend cap. However, there is no explicit documentation of rate-limit guardrails (only spend budgets), and community evidence shows real friction around balance-based enforcement even with BYOK keys, so the 'cannot run away on spend' guarantee is only partially evidenced. Missing for 10: explicit per-key rate-limiting controls, clear docs on key-level rate guardrails (not just budget caps), and independent confirmation that budget enforcement reliably halts an autonomous agent before overspend.
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “Spend monitoring. Monitor your spending across different providers”
- [community] “If I bring my own Anthropic/OpenAI key and have usage available, why does Vercel's account balance determine whether my request executes? (V…”
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 Vercel AI GatewayDocs explicitly state budgets can be set to cap spend for a team, project, API key, or team member, directly matching the story, and spend monitoring/usage dashboards support enforcement. missing for 10: independent/hands-on confirmation that hard budgets actually block spend at the limit (community evidence only discusses BYOK balance blocking, not per-key/team/user budget enforcement specifics) and more detail on granularity/configuration UI.
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “Spend monitoring. Monitor your spending across different providers”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “The Usage section displays four metrics to help you monitor your AI Gateway activity.”
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 to Vercel AI GatewayDocs show request/usage summaries broken down by project and API key, budgets settable per team/project/API key/team member, and detailed logs filterable by model/provider/status with CSV/JSON export, directly matching the story's cost-tracking dimensions. Missing for 10: explicit per-user (not just per-team-member/API key) breakdowns and independent third-party confirmation of the dashboard's granularity in practice.
- [claimed-docs] “Spend monitoring. Monitor your spending across different providers”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “open the Logs page, where you can search by request ID, filter by model, provider, or status code, follow requests live, and open one reques…”
- [claimed-docs] “The Usage section displays four metrics to help you monitor your AI Gateway activity.”
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 to RequestyVercel AI Gatewaydisputedcontradicted5/10Vercel's docs clearly describe BYOK support — pass provider credentials per-request via providerOptions.gateway.byok, with no markup on tokens, and even fallback to system credentials on failure — suggesting bring-your-own-key traffic should run on the developer's own credentials (docs-6, docs-13, docs-19, docs-27). However, a concrete community report describes BYOK requests being blocked by Vercel's account balance reaching $0 even when the user's own provider key has available usage, directly contradicting the expectation that BYOK traffic is unaffected by platform account balance (comm-1). missing for 10: independent confirmation resolving the balance-dependency complaint, clearer documentation on how billing/balance interacts with BYOK requests.
- [claimed-docs] “No markup on tokens. Tokens cost the same as they would from the provider directly, with zero markup, including with [Bring Your Own Key (BY…”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “No markup on tokens. Tokens cost the same as they would from the provider directly, with zero markup, including with Bring Your Own Key (BYO…”
- [claimed-docs] “you can pass provider credentials on a per-request basis using the byok option in providerOptions.gateway. This is useful when you need to u…”
- [community] “If I bring my own Anthropic/OpenAI key and have usage available, why does Vercel's account balance determine whether my request executes? (V…”
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 drawnVercel AI Gatewaynone0/10Docs describe setting budgets, API keys, and monitoring spend through the Vercel dashboard/CLI, and a general Vercel OpenAPI spec exists, but there is no evidence of a documented admin API specifically for programmatically provisioning AI Gateway resources, keys, or budgets. Missing for 10: explicit admin/API endpoints for creating gateways, generating keys, or setting budgets programmatically, and any docs or examples showing this workflow.
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.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 to Vercel AI GatewayDocs show a single Gateway-managed API key (or OIDC token) replaces direct provider keys, with per-API-key usage tracking and budget caps that imply teams/apps can have distinct managed keys, and BYOK/system-credential fallback keeps raw provider secrets out of app code. Missing for 10: explicit dashboard walkthrough for creating/rotating multiple named keys per team or app, and documentation of per-key role/permission scoping.
- [claimed-docs] “One key, hundreds of models. Access models from multiple providers with a single API key”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “For applications deployed on Vercel, OIDC tokens are automatically available as `VERCEL_OIDC_TOKEN`. No secrets to manage, no keys to rotate…”
- [claimed-docs] “you can pass provider credentials on a per-request basis using the byok option in providerOptions.gateway. This is useful when you need to u…”
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 to Vercel AI GatewayThe gateway provides a Logs UI with filtering and CSV/JSON export of request logs, which supports manual export of logs, but there's no evidence of native integration with external observability stacks (e.g., OpenTelemetry export, webhook/streaming to Datadog/Grafana, or trace export in standard formats like OTLP). missing for 10: OpenTelemetry/OTLP trace export, native integrations with third-party observability platforms, automated/streaming log export (vs manual CSV/JSON download), independent confirmation of export usability.
- [claimed-docs] “open the Logs page, where you can search by request ID, filter by model, provider, or status code, follow requests live, and open one reques…”
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “The Usage section displays four metrics to help you monitor your AI Gateway activity.”
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 Vercel AI GatewayDocs describe a Logs page with per-request detail, search by request ID, filtering by model/provider/status, and export as CSV/JSON, plus a Requests section with summaries by project/API key and a Usage section with metrics — covering latency, tokens, cost, and routing detail. Missing for 10: independent/hands-on confirmation that latency and cost are explicitly visible per logged request (only vendor docs cited), and no third-party corroboration of the observability UI.
- [claimed-docs] “The Requests section displays summaries by project, API key, and a detailed log of all requests.”
- [claimed-docs] “open the Logs page, where you can search by request ID, filter by model, provider, or status code, follow requests live, and open one reques…”
- [claimed-docs] “The Usage section displays four metrics to help you monitor your AI Gateway activity.”
- [claimed-docs] “Spend monitoring. Monitor your spending across different providers”
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 Vercel AI GatewayThe gateway is largely API-first: model access, provider routing, caching, BYOK, and even a keyless public models endpoint are confirmed to work programmatically (docs-1,2,9,15,25,27; probe-4). However, budgets, spend caps, and the detailed Requests/Logs dashboard are described only as UI features (docs-5,12,16,23,30) without documented API endpoints to set budgets or pull logs programmatically. Missing for 10: budgets/spend-cap management API, log/usage export API parity, team/key management API parity.
- [claimed-docs] “One key, hundreds of models. Access models from multiple providers with a single API key”
- [claimed-docs] “Unified API. Switch between providers and models with minimal code changes”
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
- [claimed-docs] “you can pass provider credentials on a per-request basis using the byok option in providerOptions.gateway. This is useful when you need to u…”
- [claimed-docs] “Spend monitoring. Monitor your spending across different providers”
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [claimed-docs] “open the Logs page, where you can search by request ID, filter by model, provider, or status code, follow requests live, and open one reques…”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 to Vercel AI GatewayVercel documents that the Logs page lets users export request/usage data as CSV or JSON, and its OpenAI-compatible API means you can point clients elsewhere with minimal rewrite, reducing lock-in. However, there's no evidence of a comprehensive account/data export (billing history, configs, keys) beyond request logs, and BYOK behavior tied to Vercel balance (comm-1) suggests some platform dependency remains. Missing for 10: full account/config data export, evidence of exporting all historical usage/billing data, and confirmation that BYOK/API keys are fully portable without gateway dependency.
- [claimed-docs] “open the Logs page, where you can search by request ID, filter by model, provider, or status code, follow requests live, and open one reques…”
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [community] “If I bring my own Anthropic/OpenAI key and have usage available, why does Vercel's account balance determine whether my request executes? (V…”
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 drawnVercel AI Gatewaynone0/10Vercel AI Gateway is a closed, proprietary hosted service; no evidence in the pack points to any open-source repository or open license for its source code — all evidence is documentation and API endpoints, not source availability.
ai-native userSelf-host the core product
weight 3 · round drawnVercel AI Gatewaynone0/10Vercel AI Gateway is a hosted cloud service with no evidence of a self-hostable core product or open-source release; nothing in the docs suggests an on-prem or self-managed deployment option.
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 RequestyVercel AI Gatewaynone0/10No evidence of region/data-residency controls or storage location choices in the AI Gateway docs; the pack covers routing, failover, pricing, and observability but nothing about where data is stored or processed. Missing for 10: any mention of regional data residency options, storage location controls, or compliance certifications addressing data locality.
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 drawnVercel AI Gatewaynone0/10No evidence in the pack addresses data-training opt-out policies, zero-retention agreements, or any explicit statement that prompts/outputs are excluded from model training; the docs focus on routing, pricing, and observability instead. Missing for 10: any privacy policy or training-opt-out statement, zero-data-retention terms, provider-level data-use guarantees.
ai-native userControl data retention and deletion
weight 2 · round drawnVercel AI Gatewaynone0/10No evidence in the pack addresses data retention policies, log/data deletion controls, or retention configuration for requests/prompts processed through AI Gateway; observability docs mention logging/exporting requests but nothing about retention duration or deletion mechanisms.
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 drawnVercel AI Gatewaynone0/10No evidence of any telemetry opt-out or privacy/data-collection controls; the gateway's observability features are about logging usage for the account owner, not about disabling tracking. Missing for 10: any documented telemetry opt-out setting, privacy policy on data retention/training use, or way to disable request logging.
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 Vercel AI GatewayDocs explicitly describe automatic retries to other providers on failure, plus fine-grained control via `order`, `only`, and `sort` in providerOptions.gateway, per-provider timeouts for fast failover, and even BYOK-to-system-credential fallback — directly matching the fallback/routing-resilience story. This is well-documented first-party capability with concrete configuration options, though missing for 10: independent hands-on verification that fallback behaves correctly in production scenarios.
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “You can use order, only, and sort in providerOptions.gateway to control which providers handle your requests, in what order, and how they ar…”
- [claimed-docs] “AI Gateway routes requests, manages fallbacks and budgets, monitors usage, and connects supported coding agents.”
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 drawnDocs confirm ordering/sorting by performance or cost metric (`order`, `only`, `sort`), per-provider timeouts for fast failover, and automatic retries/fallbacks to other providers — covering latency- and cost-based routing and failover. However, explicit weight-based load balancing across providers/deployments/keys is not documented, and there's no evidence of key-level load balancing beyond BYOK fallback to system credentials. missing for 10: explicit weighted load-balancing configuration, per-key routing/balancing control, independent verification of routing behavior under load.
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “You can also use `sort` to rank providers by a performance or cost metric. The gateway sorts providers by the chosen metric and tries them i…”
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
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 to RequestyDocs show routing rules via providerOptions.gateway (order, only, sort, timeouts) that let requests fail over across providers by availability/latency, plus cost/spend visibility and budgets, which supports policy-driven switching. However, there's no explicit evidence of dynamic mid-task capability-based switching or agent-driven runtime policy changes beyond static config, and community evidence flags BYOK requests being blocked once account balance hits $0, undermining pure availability-based routing in some cases. missing for 10: explicit support for capability-based (not just cost/availability) routing rules, evidence of an agent dynamically changing models mid-task at runtime, and independent confirmation that failover/ordering works reliably in production.
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “You can also use `sort` to rank providers by a performance or cost metric. The gateway sorts providers by the chosen metric and tries them i…”
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “To cap how much your team, a project, an API key, or a team member can spend, set [budgets]”
- [community] “If I bring my own Anthropic/OpenAI key and have usage available, why does Vercel's account balance determine whether my request executes? (V…”
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 RequestyThe gateway supports failover/retry across providers, per-provider timeouts for fast failover, and ordering/sorting of providers (docs-3, docs-9, docs-10, docs-13, docs-20, docs-29), which can mitigate a single provider's rate limits by shifting traffic elsewhere. However, there's no documented mechanism for spreading load across multiple API keys for the same provider, nor any explicit request queuing/throttling feature to smooth bursts against rate limits. Missing for 10: multi-key load balancing, explicit request queuing/throttling controls, and any rate-limit-specific documentation or independent verification.
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “You can also use `sort` to rank providers by a performance or cost metric. The gateway sorts providers by the chosen metric and tries them i…”
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 Vercel AI GatewayDocs explicitly describe automatic failover/retry to other providers on failure (docs-3), configurable provider ordering/fallback with `order`, `only`, `sort` (docs-9, docs-29), per-provider timeouts to trigger fast failover (docs-10), and even automatic retry with system credentials when BYOK fails (docs-13). This directly covers automatic retry policies for transient provider errors. Missing for 10: no independent/hands-on confirmation of retry behavior in production, and no explicit documentation of configurable retry counts/backoff intervals distinct from provider ordering.
- [claimed-docs] “High reliability. Automatically retries requests to other providers if one fails”
- [claimed-docs] “You can use `order`, `only`, and `sort` in `providerOptions.gateway` to control which providers handle your requests, in what order, and how…”
- [claimed-docs] “You can set per-provider timeouts to trigger fast failover when a provider is slow to respond.”
- [claimed-docs] “If a query using your credentials fails, AI Gateway will retry the query with its system credentials to improve service availability.”
- [claimed-docs] “You can also use `sort` to rank providers by a performance or cost metric. The gateway sorts providers by the chosen metric and tries them i…”
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 Vercel AI GatewayThe gateway advertises full OpenAI/Anthropic SDK compatibility and AI SDK integration (docs-7, docs-18, docs-28, docs-31), and since streaming is a standard capability of those client libraries, it is implicitly supported when pointing existing clients at the gateway's base URL. However, no evidence explicitly documents streaming/token-by-token responses, SSE support, or shows this working across all providers. Missing for 10: explicit docs on streaming endpoints/parameters, hands-on confirmation of token-by-token streaming across multiple providers, and any independent verification.
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [claimed-docs] “Move existing OpenAI, Anthropic, and AI SDK integrations to AI Gateway with a base URL swap.”
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 RequestyVercel AI Gatewaynone0/10The evidence describes unified APIs, OpenAI-compatibility, provider routing, embeddings, and observability, but nowhere mentions structured JSON-schema/response_format output support or how it is normalized across different providers. Missing for 10: any documentation of JSON-schema/structured-output support, cross-provider schema normalization, or examples using response_format/json_schema.
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 Vercel AI GatewayVercel AI Gateway supports a unified API/schema (OpenAI-compatible and AI SDK) that lets developers call tools/functions across many providers with consistent code, including an explicit ToolLoopAgent example with tool calling, provider routing/fallback, and no-rewrite compatibility with existing OpenAI/Anthropic clients. missing for 10: independent hands-on verification of cross-provider tool-call schema consistency (e.g., confirming tool-calling behaves identically across Anthropic/OpenAI/other models) and any documented edge cases or limitations in function-calling parity across providers.
- [claimed-docs] “Unified API. Switch between providers and models with minimal code changes”
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “const agent = new ToolLoopAgent({ model: 'anthropic/claude-sonnet-5', tools: { getWeather: tool({”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 to Vercel AI GatewayDocs explicitly describe a models endpoint returning model IDs, context windows, and pricing with no authentication required, and a probe independently confirms the live unauthenticated /v1/models endpoint returns a full JSON model catalog. This directly satisfies browsing/querying a model catalog with pricing and context-window metadata. Missing for 10: no evidence of a dedicated visual browsing UI/dashboard for the catalog beyond the API and docs page.
- [claimed-docs] “This endpoint requires no authentication and returns detailed information including model IDs, context windows, and pricing.”
- [claimed-docs] “Query the models endpoint directly to get a JSON list of all available models with pricing and capabilities”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 to Vercel AI GatewayVercel explicitly documents OpenAI-compatible Chat Completions API where developers just swap the base URL and key with existing OpenAI SDKs, with no code rewrites, and a probe confirms the gateway serves an OpenAI-compatible /v1/models JSON response. Community evidence around BYOK balance behavior is unrelated to base-URL compatibility, so it doesn't dispute this. Missing for 10: independent third-party hands-on confirmation of a full migration beyond Vercel's own docs/probes.
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [claimed-docs] “Move existing OpenAI, Anthropic, and AI SDK integrations to AI Gateway with a base URL swap.”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
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 Vercel AI GatewayExtensive first-party docs describe a single unified API/key across hundreds of providers, OpenAI-compatible client support, and provider routing/fallback controls, and a live probe confirms the OpenAI-compatible /v1/models endpoint works unauthenticated. There is a minor community-reported caveat about BYOK requests being blocked when Vercel balance hits $0, which slightly limits the 'bring your own key' flow but doesn't contradict the core unified-API story. Missing for 10: independent hands-on developer confirmation of multi-provider switching in production beyond docs and one probe.
- [claimed-docs] “One key, hundreds of models. Access models from multiple providers with a single API key”
- [claimed-docs] “Unified API. Switch between providers and models with minimal code changes”
- [claimed-docs] “You can use existing OpenAI client libraries, switch to AI Gateway with a URL change, and keep your current tools and workflows without code…”
- [claimed-docs] “Point your existing OpenAI or Anthropic SDK at AI Gateway. Same calls, no rewrites.”
- [claimed-docs] “You can use the AI Gateway's Chat Completions API with existing tools and libraries like the OpenAI client libraries and AI SDK. Point your …”
- [probe] “PROBE keyless-endpoint: GET https://ai-gateway.vercel.sh/v1/models returned HTTP 200 application/json with an OpenAI-compatible {"object":"l…”
- [community] “If I bring my own Anthropic/OpenAI key and have usage available, why does Vercel's account balance determine whether my request executes? (V…”
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 userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableVercel AI Gatewayn/aVercel AI Gateway is developer infrastructure that routes and manages LLM API calls between an application and model providers; it has no end-user product surface or stored user data of its own from which to surface insights. This capability belongs to applications built on top of the gateway, not the gateway itself, so the axis is a category error here.
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 comparableVercel AI Gatewayn/aVercel AI Gateway is a model-routing/API gateway product (unified API, failover, spend monitoring, observability) — it is not an automation/orchestration platform with schedulers, triggers, or persistent background execution. Building or running autonomous background automations is outside its product category; that capability would live in a separate agent/orchestration tool that might use the Gateway for model calls.
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableVercel AI Gatewayn/aVercel AI Gateway is an infrastructure/routing layer for LLM API calls, not a product with a built-in AI assistant UI for users to delegate tasks to; it enables developers to build agents (e.g., ToolLoopAgent) but does not itself ship a first-party assistant persona for end users.
ai-native userOperate the product with natural-language commands
weight 2 · not comparableVercel AI Gatewayn/aVercel AI Gateway is developer infrastructure (API routing/failover/billing for LLM providers) that is configured via code, dashboard, and API calls — not an interactive assistant meant to be 'operated' via natural-language commands. Evidence about coding-agent connectivity and ToolLoopAgent describes building agents that use the gateway, not commanding the gateway itself in natural language, so this axis is a category mismatch for this product type.
ai-native userTest against a sandbox environment without touching production data
weight 1 · not comparableVercel AI Gatewayn/aAI Gateway is a model-routing/API proxy layer, not a data-plane product with production datasets or sandbox/staging environments to isolate from production data; the story's premise (sandbox vs production data) doesn't map onto its category. No evidence describes environment separation or sandbox testing modes, confirming this axis is a category mismatch rather than a gap.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableVercel AI Gatewayn/aVercel AI Gateway is a request-routing/proxy layer for LLM API calls (unified API, retries, budgets, observability) — it has no scheduler, cron, or workflow orchestration feature for recurring jobs. This is a category mismatch, not a missing capability of this product type.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableVercel AI Gatewayn/aVercel AI Gateway is a model-routing/API gateway product, not an automation-building platform with a concept of versionable 'automations' to review or roll back — this axis is a category mismatch for its product type.