Model Gateways & Routers Arena
OpenRouter vs Vercel AI Gateway
OpenRouter
OpenRouter, Inc.
OpenRouter wins · 19–10 (13 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 drawnOpenRouter serves a working llms.txt at openrouter.ai/llms.txt (HTTP 200, agent-oriented summary), plus an OpenAPI spec and MCP server that expose docs/data programmatically to agents. This directly satisfies pointing an agent at llms.txt or agent-oriented docs. Missing for 10: independent/community confirmation that agents successfully consume llms.txt in practice.
- [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”
- [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”
Vercel 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.”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Vercel AI GatewayOpenRouter is fundamentally a headless REST API (single endpoint, OpenAI-SDK compatible, streaming, programmatic API key management) that requires no UI and can be called from any script or pipeline, making it inherently suited to CI/automation use; the keyless models endpoint and management API keys reinforce programmatic, non-interactive use. Missing for 10: no explicit CI/CD pipeline examples (e.g., GitHub Actions), no dedicated 'headless/automation' documentation section, and no independent report of someone running it in a CI pipeline.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
- [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
- [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
- [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
AI 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…”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round drawnOpenRouternone0/10Evidence only shows OpenRouter publishing its own MCP server so external AI tools/editors can pull OpenRouter data (docs-14, docs-26, docs-34, probe-3) — this is OpenRouter acting as an MCP server for other clients, not OpenRouter itself consuming/plugging in external MCP servers to gain their tools. There is no evidence that OpenRouter's API or platform lets a user attach third-party MCP servers so OpenRouter-routed models can call their tools; the standardized tool-calling docs (docs-5) refer to generic function-calling, not MCP integration specifically.
- [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”
- [claimed-docs] “The **OpenRouter MCP server** plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter da…”
- [claimed-docs] “Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages…”
- [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”
- [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
ai-native userConnect an agent via an official MCP server
weight 3 · round to OpenRouterOpenRouter publishes an official MCP server that lets AI assistants/agents connect and pull live OpenRouter data (models, prices, credits, rankings, docs) directly from within the editor, confirmed both in docs and via a live probe of the documentation page. Missing for 10: independent/hands-on community validation of the MCP server's real-world reliability beyond first-party docs.
- [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”
- [claimed-docs] “The **OpenRouter MCP server** plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter da…”
- [claimed-docs] “Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages…”
- [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”
Vercel 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.”
ai-native userUse an official CLI
weight 2 · round to Vercel AI GatewayOpenRouternone0/10OpenRouter is an API/model-routing platform for which an official CLI would be a plausible ecosystem tool, but the evidence pack contains no mention of any official OpenRouter CLI — only SDK compatibility, REST API, MCP server, and web UI are documented.
The 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”
ai-native userDrive the product through a documented public API
weight 3 · round to OpenRouterOpenRouter is fundamentally an API product: extensive first-party docs cover the unified chat completions endpoint, streaming, tool calling, model routing/fallbacks, key management, and an OpenAPI spec plus a live, keyless /api/v1/models endpoint confirm a documented, programmatically accessible public API. Community evidence corroborates real-world programmatic use (switching models, key minting, billing caps) reinforcing that it is driven via API in production.
- [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
- [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
- [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
- [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
- [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
AI 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…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to OpenRouterOpenRouter offers a documented Management API for creating/rotating API keys, workspace spend budgets, and per-key limits/expiry, which supports issuing distinct, capped credentials for agents (openrouter-docs-8, openrouter-docs-10, openrouter-comm-12, openrouter-comm-11). However, there's no explicit documentation of fine-grained scoping (e.g., restricting a key to specific models, tools, or actions) beyond spend caps, so 'least-privilege' is only partially realized. Missing for 10: explicit per-key model/tool/action scoping, granular permission controls beyond spend limits, and independent hands-on verification of the key-management API's robustness.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Docs 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. …”
ai-native userBuild against official SDKs
weight 2 · round to Vercel AI GatewayOpenRouter documents an OpenAI-compatible API and explicitly recommends using the OpenAI SDK as a drop-in replacement, plus offers an OpenAPI spec and request builder for generating client code, which supports building against it programmatically. However, there is no evidence of dedicated first-party OpenRouter SDK packages (e.g., official Python/Node/Go libraries) beyond OpenAI SDK compatibility. Missing for 10: dedicated official multi-language SDKs, independent developer corroboration of SDK usage (only OpenAI-SDK compatibility and generic API docs are cited).
- [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
- [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”
AI 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…”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnOpenRouternone0/10No evidence in the pack mentions webhooks or event subscription mechanisms of any kind for OpenRouter; the documented features (routing, caching, key management, MCP server) do not include webhook support.
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to OpenRouterOpenRouter's docs explicitly mention an interactive Request Builder for generating API requests in any language, plus a live OpenAPI spec is served and confirmed by probe, and the docs site is extensively organized with runnable-style examples across guides. Missing for 10: X, Y — no independent/hands-on account of actually running the interactive Request Builder or evidence of embedded runnable code sandboxes beyond the Request Builder claim.
- [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
There'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”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to OpenRouterA probe confirms https://openrouter.ai/openapi.json returns HTTP 200 with an actual "openapi" key, giving a downloadable machine-readable OpenAPI spec, and docs also mention an interactive Request Builder and llms.txt for AI-native consumption. missing for 10: independent/community confirmation that the spec is actively used or kept in sync with the API by third-party developers.
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
- [claimed-docs] “You can use the interactive Request Builder to generate OpenRouter API requests in the language of your choice.”
A 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”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnOpenRouternone0/10The evidence pack covers routing, fallbacks, caching, BYOK, key management, and privacy settings, but nowhere documents API versioning (e.g., v1/v2 endpoints) or a formal deprecation policy/timeline for endpoints or models. The 'latest alias' for models is about model freshness, not API version stability guarantees.
Vercel 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”
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 drawnOpenRouternone0/10The evidence pack shows OpenRouter provides a single-request API, model routing/fallbacks, and programmatic key management, but there is no documentation of a batch/bulk inference endpoint or any mechanism to submit many items/prompts in one bulk operation. missing for 10: batch API or bulk job submission endpoint, evidence of processing many items in a single call, bulk data/export operations.
Vercel 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 Vercel AI GatewayOpenRouternone0/10OpenRouter is an LLM routing/API gateway; nothing in the evidence describes user-defined event-driven rules or triggers (e.g., webhooks, if-this-then-that automations) that fire actions automatically. Model fallback and provider routing are static request-time configs, not event-triggered automation rules.
The 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…”
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 OpenRouterOpenRouter's docs explicitly describe gateway-level response caching that returns cached results with zero billable usage (cutting cost) and near-instant latency, plus provider sticky routing specifically designed to maximize cache hit rates on subsequent requests. This directly matches the story's ask for gateway-side caching to reduce cost/latency on repeated calls. Missing for 10: independent or hands-on community confirmation that caching actually reduces cost/latency in practice, and more detail on cache TTL/configurability beyond the sticky-routing mechanism.
- [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
- [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
- [claimed-docs] “OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a cached request.”
- [claimed-docs] “OpenRouter uses **provider sticky routing** to route your subsequent requests to the same provider endpoint after a cached request.”
- [claimed-docs] “To maximize cache hit rates, OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a…”
Docs 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…”
Latency
platform engineerRun traffic through gateway infrastructure that adds minimal latency overhead to provider calls
weight 2 · round to OpenRouterOpenRouter's docs describe latency-reducing features (response caching bypasses billing and reduces latency, sticky routing to maximize cache hits, load-balanced provider selection, streaming support) that imply a gateway designed for low overhead, but there is no explicit benchmark or first-party claim quantifying the gateway's own latency overhead versus direct provider calls. Community feedback is mixed—some praise ease of switching models and reliability (comm-2), while others report unexplained inconsistency and debugging difficulty (comm-8)—but none of this directly measures gateway latency overhead. Missing for 10: quantified latency-overhead benchmarks (vendor or independent), explicit performance comparison vs. direct provider calls, and hands-on latency testing evidence.
- [claimed-docs] “When a cached response is available, OpenRouter returns it immediately from cache with no billing (all billable usage counters are reported …”
- [claimed-docs] “OpenRouter uses provider sticky routing to route your subsequent requests to the same provider endpoint after a cached request.”
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
- [community] “I had consistent problems (5 months back) with OpenRouter and other providers. And very hard to debug. I used the provider directly (Google)…”
Docs 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…”
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 OpenRouterOpenRouter supports programmatic API key management (creation, per-key limits/expiry) and workspace-level budget caps (daily/weekly/monthly/lifetime) that auto-block requests once reached, directly enabling an agent to be given its own scoped key with hard spend guardrails; community confirms billing caps and per-key limits are a valued differentiator. missing for 10: explicit per-key rate-limit (requests/sec) controls beyond spend caps, and independent hands-on verification that runaway agent spend is actually blocked in practice.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Docs 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…”
Budgets
platform engineerSet hard budgets and spend limits per key, team, or user
weight 3 · round to Vercel AI GatewayOpenRouter's docs clearly show hard, auto-enforced 'workspace budgets' with configurable daily/weekly/monthly/lifetime dollar caps that block requests once reached (openrouter-docs-10), covering team-level budgets. Per-key limits are only supported by an informal community mention of 'expiry/limits per key' (openrouter-comm-12, openrouter-comm-11) rather than first-party documentation, and per-user budget controls are not evidenced at all. Missing for 10: official docs confirming per-key hard spend limits, explicit per-user budget/quota controls, and independent verification of enforcement.
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Docs 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.”
Spend tracking
platform engineerTrack spend per model, key, team, or user across all providers in one place
weight 3 · round to Vercel AI GatewayOpenRouter provides key management (creation, limits per key), workspace budgets with dollar caps by interval, and BYOK cost control, plus community confirmation of billing caps and per-key limits — but the evidence pack lacks explicit documentation of a unified spend dashboard broken down by model, team, or user across providers in one place. missing for 10: consolidated analytics/dashboard showing spend segmented by model, by team, and by individual user; documentation of team-level spend attribution; independent confirmation of cross-provider spend reporting granularity.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Docs 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.”
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 OpenRouterOpenRouter's docs explicitly describe BYOK (bring your own provider keys), letting developers use their own provider API keys for direct control over rate limits and costs, and this is corroborated by community testimony citing consolidated billing/key management as a core benefit. Missing for 10: independent hands-on verification specifically of BYOK traffic routing (most community evidence discusses OpenRouter credits/key management generally rather than BYOK specifically).
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK). ... Using provider keys enables direct co…”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK).”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Vercel 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…”
Programmatic admin
ai-native userProvision gateways, keys, and budgets programmatically through an admin API
weight 3 · round to OpenRouterOpenRouter documents a management API for provisioning and rotating API keys programmatically (openrouter-docs-8) and community users confirm the ability to mint/limit keys (openrouter-comm-12, openrouter-comm-11). Workspace budgets are documented as a feature to cap spend (openrouter-docs-10), but the evidence doesn't explicitly confirm budgets are settable via the same admin API, and there's no mention of provisioning 'gateways' as a distinct programmable resource. Missing for 10: explicit API endpoint documentation for setting/adjusting workspace budgets programmatically, and any concept of provisioning separate 'gateways' via API.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
Vercel 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”
Virtual keys
platform engineerMint gateway-managed keys for teams and apps without exposing raw provider keys
weight 3 · round to OpenRouterOpenRouter's docs explicitly describe programmatic key management endpoints for creating/managing/rotating API keys for apps without exposing provider keys (docs-8), backed by BYOK for provider key control (docs-9/24/32) and workspace budgets to cap spend per workspace/team (docs-10). Community corroborates ease of minting and limiting keys (comm-12, comm-11). Missing for 10: independent verification of team/app-scoped key isolation guarantees and no first-hand platform-engineer account of using the management API at scale.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
- [community] “They offer billing caps! Most model providers still don't do this, but if you're going to run anything in public it's very useful to have ha…”
Docs 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…”
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 GatewayOpenRouternone0/10Evidence pack shows OpenRouter's API gateway features (routing, fallbacks, caching, key management, privacy settings) but contains no mention of exporting logs/traces, webhooks, log streaming, or integration with observability stacks like Datadog, OpenTelemetry, or similar. missing for 10: log/trace export mechanism, OpenTelemetry or webhook integration, documentation of any observability-stack connector.
The 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.”
Logs
platform engineerInspect logged requests and responses with latency, token counts, and cost attached
weight 3 · round to Vercel AI GatewayOpenRouternone0/10The evidence pack covers routing, caching, BYOK, budgets, and key management, but contains no mention of a request/response log viewer, latency dashboards, or per-request token/cost breakdowns that a platform engineer could inspect. missing for 10: activity/logs dashboard documentation, per-request latency metrics, per-request token count and cost attribution evidence.
Docs 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”
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 drawnOpenRouter's core capabilities—model routing, fallbacks, provider selection, key management, workspace budgets, privacy settings, and even the model catalog—are all documented as programmatically accessible via the API (openrouter-docs-8, 10, 12, 21, 35, openapi.json probe), suggesting strong API/UI parity for a product that is API-first. However, there's no explicit vendor claim of full UI-API parity, and dashboard-only features like rankings/analytics visualizations aren't confirmed as API-exposed. Missing for 10: explicit parity statement, evidence that UI-exclusive features (e.g., rankings, usage analytics dashboards) are also fully API-accessible, and independent confirmation from hands-on API users of complete feature parity.
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “Workspace budgets let you cap how much a workspace can spend on OpenRouter inference. Set a dollar limit on any combination of intervals — d…”
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
- [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
- [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
- [probe] “PROBE openapi: HTTP 200 at https://openrouter.ai/openapi.json — contains "openapi" key”
- [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
The 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…”
ai-native userExport all of my data in open formats and leave
weight 3 · round to Vercel AI GatewayOpenRouternone0/10The evidence pack covers API routing, model access, MCP server, and billing features, but contains no mention of any user data export capability (usage logs, account data, chat history) in open formats or account portability/closure process — the axis is applicable to a SaaS platform storing usage/billing data, but no supporting evidence exists.
Vercel 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…”
ai-native userRead the product's source under an open license
weight 2 · round drawnOpenRouternone0/10No evidence that OpenRouter's own source code (the API service, routing platform, or website) is published under an open license; evidence pack only covers API docs, features, and OpenAPI spec, not source availability. missing for 10: any repository link, open-source license file, or statement that OpenRouter's codebase is publicly available.
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 OpenRouterOpenRouter documents EU/US in-region routing for enterprise customers and per-request/account-wide data-policy restrictions, giving users some control over where data is processed, but this is gated to enterprise accounts rather than available to all AI-native users, and community comments note there's no true ZDR/data-sovereignty guarantee in practice. missing for 10: general-tier (non-enterprise) region selection, independent verification that in-region routing works as claimed, and clarity on residency guarantees beyond enterprise contracts.
- [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
- [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
- [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”
Vercel 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.
ai-native userPrevent my data from being used to train AI models
weight 3 · round to OpenRouterOpenRouter lets users restrict requests/account-wide to providers with certain data policies and opt out of routing to providers that may train on data, plus EU/US in-region processing for enterprise, which directly supports preventing training-data use; however community evidence notes there is 'no ZDR' (zero data retention) and 'no true guarantees of ZDR/privacy/data sovereignty,' indicating limits to how absolute this protection is. missing for 10: independent verification that opt-out settings are consistently honored by all providers, clarity on default behavior, and resolution of the ZDR gap raised by users.
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
- [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy.”
- [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
- [community] “No ZDR. No dice.”
- [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”
Vercel 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 to OpenRouterOpenRouter lets users restrict routing to providers with certain data policies (e.g. no-training, zero-retention) both per-request and account-wide, and offers EU/US in-region processing for enterprise, which are real retention/data-policy controls. However there is no documented mechanism for deleting already-retained data or setting explicit retention periods, and community comments (e.g. 'No ZDR. No dice') indicate the zero-data-retention toggle has real-world limitations/gaps rather than full guaranteed retention control. Missing for 10: explicit data deletion/erasure endpoint, documented retention-period settings, and independent confirmation that ZDR/data-policy filters reliably cover all providers.
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
- [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
- [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy.”
- [community] “No ZDR. No dice.”
- [community] “Since it's only discounted on the standard 'OpenAI,' non-ZDR route (old pricing on Azure), a lot of users won't see this benefit since many …”
- [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”
Vercel 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.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round to OpenRouterOpenRouter documents privacy controls—restricting requests to providers with certain data policies, disallowing providers that may train on your data, and EU/US in-region routing for enterprise—which give users some control over how their prompt data is handled downstream, but this is about provider-side data handling, not an explicit opt-out of OpenRouter's own telemetry/usage tracking. Community evidence directly notes 'No ZDR. No dice' and 'no true guarantees of ZDR/privacy/data sovereignty,' indicating real limits on data-handling assurances. Missing for 10: an explicit telemetry/usage-tracking opt-out toggle for OpenRouter's own platform analytics, and independent confirmation that opting out actually stops tracking.
- [claimed-docs] “You can restrict individual requests to only use providers with a certain data policy. This is also available as an account-wide setting in …”
- [claimed-docs] “On your account settings page, you can set whether you would like to allow routing to providers that may train on your data (according to th…”
- [claimed-docs] “For enterprise customers, OpenRouter supports in-region routing in the EU and US. When enabled for your account, your prompts and completion…”
- [community] “No ZDR. No dice.”
- [community] “OpenRouter doesn't expose all the LLM sampling parameters/research that llamacpp, vllm, sglang expose (so no high temperature/highly diverse…”
Vercel 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.
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 drawnOpenRouter documents explicit model fallback via a priority-ordered `models` array that auto-retries the next model on error, plus provider-level fallback/load balancing across top providers, and community confirms this works ('They also support fallback by default so you don't have to write wrappers'). This directly matches the platform engineer's story of configuring automatic fallback across models/providers on failure. Missing for 10: independent quantitative reliability data or a documented edge-case failure of the fallback mechanism itself.
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
Docs 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.”
Load balancing
platform engineerLoad-balance traffic across providers, deployments, or keys by weight, latency, or cost
weight 2 · round to OpenRouterDocs show default load balancing across top providers, customizable provider routing (sort by price/throughput), and ordered model fallbacks, plus BYOK for provider-key control, corroborated by community mentions of built-in fallback behavior. Missing for 10: explicit documentation of weighted routing across specific API keys and independent benchmarks validating latency/cost-based routing performance in practice.
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
- [claimed-docs] “You can customize how your requests are routed using the provider object in the request body for Chat Completions.”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
Docs 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.”
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 OpenRouterOpenRouter's docs and community evidence confirm model fallback lists (priority order, automatic retry on error/rate-limit/down), provider-selection routing rules, load balancing across providers, a 'latest' alias for staying current, and an auto-routing 'meta' model that picks capability-appropriate models to control cost — directly matching policy-based mid-task model switching by cost/capability/availability. missing for 10: no first-party documentation or hands-on evidence of dynamically switching models *within* a single in-flight task/conversation (vs. per-request fallback/config), and no independent benchmark validating routing-rule reliability in production.
- [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “You can customize how your requests are routed using the `provider` object in the request body for [Chat Completions]”
- [claimed-docs] “a latest alias that always resolves to the newest OpenAI flagship model, so your code keeps using the freshest version without redeploying”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
- [community] “One thing I really like about OpenRouter is their 'meta' model that automatically routes the prompt to an appropriately capable model. Saves…”
- [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”
Docs 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…”
Rate limits
platform engineerSmooth provider rate limits by spreading traffic across keys and queuing or throttling requests
weight 2 · round to OpenRouterOpenRouter's default load balancing across providers and automatic model/provider fallbacks (docs-3,4,19) inherently smooths provider-side rate limits, and its key-management API (docs-8) plus BYOK (docs-9,24,32) let engineers create/distribute multiple keys with per-key limits (echoed by comm-12). But there is no explicit documentation of client-side request queuing or throttling, or of deliberately spreading traffic across multiple OpenRouter keys for load smoothing — the evidence covers provider-side resilience, not key-pool traffic shaping. Missing for 10: explicit queuing/throttling mechanism, documented multi-key load-balancing pattern, independent confirmation of rate-limit smoothing at scale.
- [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “OpenRouter provides endpoints to programmatically manage your API keys, enabling key creation and management for applications that need to d…”
- [claimed-docs] “OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)... Using provider keys enables direct cont…”
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [community] “One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish other provid…”
The 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…”
Retries
platform engineerSet automatic retry policies for transient provider errors
weight 2 · round to Vercel AI GatewayOpenRouter's model-fallbacks and provider load-balancing features automatically retry a request against alternate providers/models when the primary is down, rate-limited, or errors out, and this is corroborated by community reports of built-in fallback behavior (openrouter-docs-3, openrouter-docs-4, openrouter-docs-17, openrouter-docs-19, openrouter-comm-2). However, this is provider/model-level fallback rather than a granular, configurable retry policy (e.g., retry count, backoff intervals, specific transient-error codes) that a platform engineer might expect. Missing for 10: explicit retry-count/backoff configuration options, granular control over which transient error codes trigger retries, and independent verification of retry behavior under real outages.
- [claimed-docs] “The models parameter lets you automatically try other models if the primary model's providers are down, rate-limited, or refuse to reply due…”
- [claimed-docs] “OpenRouter routes requests to the best available providers for your model. By default, requests are load balanced across the top providers t…”
- [claimed-docs] “Reliable AI models via our distributed infrastructure. Fall back to other providers when one goes down.”
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
Docs 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…”
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 OpenRouterOpenRouter's docs explicitly state streaming is supported for any model through the gateway API, and community feedback corroborates using a single API/key across many providers with model switching in production. missing for 10: independent hands-on confirmation specifically of token-by-token streaming behavior (e.g., latency/chunking quality) and any provider-specific streaming caveats or limitations.
- [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
- [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
- [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
The 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.”
Tool calling
developerRequest structured JSON-schema outputs across providers
weight 1 · round drawnOpenRouternone0/10The evidence pack covers tool-calling standardization, streaming, routing, fallbacks, and key management, but contains no mention of structured JSON-schema/response_format output support across providers. missing for 10: any documentation or example of JSON-schema response_format, schema validation, or structured output enforcement across providers.
Vercel 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.
developerMake tool and function calls across different providers with a consistent schema
weight 3 · round drawnOpenRouter explicitly documents a standardized tool-calling interface across models/providers (docs-5), consistent with its single-API model access across 500+ models and providers (docs-1, docs-16), and community confirms using the same API key/request format to switch models seamlessly (openrouter-comm-2). Streaming is also documented as working across any model (docs-11/20), supporting the streaming-tools theme. Missing for 10: no independent hands-on verification specifically of function/tool-call schema consistency across multiple providers, and no detailed example showing identical tool-call JSON working unchanged across e.g. OpenAI vs Anthropic vs Google models.
- [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
- [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
- [claimed-docs] “The OpenRouter API allows streaming responses from any model. This is useful for building chat interfaces or other applications where the UI…”
- [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
Vercel 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…”
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 drawnOpenRouter documents a browsable model catalog at openrouter.ai/models and a programmatic GET /api/v1/models endpoint listing model slugs, and a live probe confirms this endpoint returns 426 models with pricing/context-window metadata unauthenticated. Community feedback corroborates ease of comparing/switching models via the unified catalog. Missing for 10: no independent third-party review specifically validating completeness/accuracy of pricing or context-window fields beyond the probe.
- [claimed-docs] “Browse the full catalog at openrouter.ai/models, or list every available slug programmatically via the GET /api/v1/models endpoint.”
- [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
- [claimed-docs] “300T+ Monthly Tokens 10M+ Global Users 80+ Providers 500+ Models”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
Docs 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…”
Compatibility
developerPoint existing OpenAI-compatible code at the gateway by changing only the base URL and key
weight 3 · round drawnDocs explicitly state the OpenAI SDK can be pointed at OpenRouter as a drop-in replacement, and community users corroborate using 'the same api key and same request' across models, confirming base-URL/key swap works in practice. Missing for 10: no explicit first-party code snippet showing the exact base_url/api_key change in the evidence pack, only the general drop-in claim.
- [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
- [claimed-docs] “You can also use the [OpenAI SDK](#using-the-openai-sdk) pointed at OpenRouter as a drop-in replacement.”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
- [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
Vercel 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…”
One endpoint
developerCall many model providers through one consistent API
weight 3 · round drawnOpenRouter's core value proposition is a single API endpoint (OpenAI-SDK compatible) that routes to hundreds of models across 80+ providers, with fallback, load-balancing, standardized tool calling, and streaming for any model — corroborated by live probes (426-model catalog, openapi.json) and community testimonials confirming 'same API key and same request' across providers with automatic fallback. Minor gaps: community notes some inconsistencies (missing sampling params, occasional reliability complaints), missing for 10: fully independent benchmark of API consistency across all providers and resolution of reported debugging/latency complaints.
- [claimed-docs] “OpenRouter gives you access to hundreds of AI models through a single API endpoint.”
- [claimed-docs] “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement.”
- [claimed-docs] “Provide an array of model IDs in priority order. If the first model returns an error, OpenRouter will automatically try the next model in th…”
- [claimed-docs] “OpenRouter standardizes the tool calling interface across models and providers, making it easy to integrate external tools with any supporte…”
- [claimed-docs] “The OpenRouter API allows streaming responses from *any model*. This is useful for building chat interfaces or other applications where the …”
- [probe] “PROBE llms.txt: HTTP 200 at https://openrouter.ai/llms.txt # OpenRouter > A unified API for every major LLM. One endpoint, hundreds of mode…”
- [probe] “PROBE keyless-endpoint: GET https://openrouter.ai/api/v1/models returned HTTP 200 application/json with 426 models (unauthenticated) - live …”
- [community] “Happy for the OpenRouter team... the ability to run any AI model with the same api key and same request has been great to experiment with ne…”
- [community] “It's definitely the best way to try out new models without fiddling with each providers distinct APIs. That said, I don't understand people …”
Extensive 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…”
Not comparable on these axes
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableOpenRoutern/aOpenRouter is an API/routing gateway for accessing LLMs, not a data product that holds a user's own data and surfaces AI-generated insights from it — the axis is a category mismatch for this type of infrastructure tool.
Vercel 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.
ai-native userSet up automations that run autonomously in the background
weight 2 · not comparableOpenRoutern/aOpenRouter is a unified API/routing layer for LLM inference, not an automation/orchestration platform with scheduling or background-run capabilities; setting up autonomous background automations is outside its product category (wrong axis) rather than a missing feature.
Vercel 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 comparableOpenRoutern/aOpenRouter is a model-routing/API aggregation platform for developers to access LLMs, not a product with its own built-in AI assistant that end-users delegate tasks to; its MCP server lets *other* assistants pull OpenRouter data, which is the inverse of this story's axis. Task delegation to an in-product assistant is a category mismatch for an API routing service.
Vercel 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 comparableOpenRouter is an API/routing platform, not a natural-language interface itself, but it does provide an official MCP server that lets an AI assistant issue natural-language commands to pull model data, pricing, credits, and send test messages without leaving the editor — this is the main evidence of NL-command operability. Beyond MCP, there's no chat-style NL command surface for managing keys, budgets, or routing directly. missing for 10: a native conversational/NL interface for account and routing operations, independent hands-on validation of the MCP server's NL command handling, and evidence of NL commands controlling core features like BYOK, budgets, or provider selection.
- [claimed-docs] “The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (…”
- [claimed-docs] “The **OpenRouter MCP server** plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter da…”
- [claimed-docs] “Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages…”
- [probe] “official MCP server documented at https://openrouter.ai/docs/guides/overview/mcp-server.md”
Vercel 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 comparableOpenRouternone0/10OpenRouter's evidence describes production routing, billing, BYOK, and caching features but nothing about a sandbox/test environment isolated from production data or billing. The keyless models endpoint (openrouter-probe-4) only exposes a public catalog, not an isolated test mode for requests. No documentation of test/staging keys, sandbox mode, or non-production data isolation exists in the pack.
Vercel 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 comparableOpenRoutern/aOpenRouter is an API routing/aggregation layer for LLM inference, not a workflow/job scheduler; nothing in its evidence pack relates to scheduling recurring jobs or workflows. This axis is a category error for this kind of product.
Vercel 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 comparableOpenRoutern/aOpenRouter is an API routing/aggregation layer for LLM inference, not an automation-builder product with workflows to version, review, or roll back; this axis is a category error for this product type.
ai-native userSelf-host the core product
weight 3 · not comparableOpenRoutern/aOpenRouter is a hosted API routing/aggregation service, not open-source software designed to be self-hosted; no evidence of a self-hostable core product exists. Self-hosting is a category mismatch for this kind of cloud aggregation service.