OpenRouter vs Vercel AI Gateway: Cost, Routing, and Model Coverage

Vercel AI Gateway is my default for Vercel-hosted applications and shareable coding work. OpenRouter is my default when model breadth, provider choice, and infrastructure portability carry more weight. I use both because they optimize different parts of the same request.

I came to this comparison after using each in production-shaped systems. My always-on Hermes agent runs on AWS and calls models through OpenRouter. My Vercel agent fleet and claude-gateway wrapper use Vercel AI Gateway. In my Vercel AI Gateway review, I measured the Gateway against direct providers and found consistent time to first token, useful cache pricing, and enough available capacity to finish work while several direct services were sold out or rate-limited.

The next question was obvious: if OpenRouter already gives me one key, a large catalog, and automatic failover, what does Vercel's Gateway add? And if Vercel charges zero markup, why keep OpenRouter around?

Here is the short answer.

They route at two different layers

An AI gateway makes two separate decisions. First it selects a model. Then it selects a provider deployment serving that model.

Those decisions have different risk. Sending Claude Sonnet through Anthropic, Bedrock, or Vertex should preserve the model's broad behavior, though context limits, supported parameters, cache policy, and release timing can still vary. Falling from Claude Sonnet to Gemini or DeepSeek changes the model itself. Tool behavior, reasoning, safety policy, and output quality can move with it.

Both products handle both layers. OpenRouter accepts an ordered models array and falls through providers within each model. Vercel accepts fallback models under providerOptions.gateway.models, then applies provider routing to each model in turn. The feature checkboxes look similar. The defaults and the depth of control differ.

Cost: Vercel wins the fee comparison, OpenRouter can win the invoice

Vercel charges provider list price with zero token markup, including BYOK. A Vercel team starts with $5 in monthly Gateway credits. Buying credits moves the team to paid usage and ends the recurring $5 allowance.

OpenRouter passes through upstream inference rates, then charges a 5.5% fee when you buy credits, with an $0.80 minimum on card payments. A workload that consumes $100 at listed model rates therefore requires $105.50 in OpenRouter credit purchases. Vercel charges $100 before any payment-processing fees. Small top-ups make OpenRouter's minimum fee more visible: $5 of credit costs $5.80, an effective 16%.

That settles the comparison only when both gateways send the request to the same provider, service tier, and region.

Open-weight models change the result because the host sets the price. On August 3, the public endpoint lists for openai/gpt-oss-120b showed a CoreWeave route on OpenRouter at $0.03 per million input tokens and $0.17 per million output tokens. The cheapest Vercel route I found was Baseten at $0.10 in and $0.50 out. OpenRouter's 5.5% fee barely dents that gap. The broader supply pool produces a lower bill.

The same-day deepseek/deepseek-v4-flash-0731 snapshot landed differently. Both gateways exposed DeepInfra at $0.09 in and $0.18 out, plus DeepSeek first-party's $0.0028-per-million cache-read rate. Here Vercel keeps the fee advantage because the cheapest useful routes exist in both catalogs.

The practical cost rule is:

1. Compare the exact provider deployments available for the model.
2. Compare input, output, cache-write, and cache-read prices separately.
3. Add OpenRouter's credit-purchase fee.
4. Run your own token mix through the resulting rate cards.

My coding-agent ledger from the Vercel review was 96.6% cache reads. At that composition, the cache-read line dominates the invoice. A router that saves $0.05 per million uncached input tokens but moves the conversation onto a provider with cache reads ten times as expensive loses quickly.

BYOK has a cleaner answer on Vercel

Vercel adds no Gateway fee to BYOK. The tradeoffs are operational: BYOK requires paid Gateway usage, failed BYOK requests can fall back to Vercel-funded credentials, and BYOK spend sits outside Vercel budgets.

OpenRouter's current BYOK documentation needs a pricing clarification before I would put a large forecast behind it. The pricing page lists $25,000 of list-price BYOK inference per month without fees on pay-as-you-go, then a 5% fee. The BYOK guide describes the waiver as the first one million BYOK requests each month. Those are different meters. OpenRouter's BYOK routing is more configurable — multiple keys per provider, priority and fallback sections, and filters by model, API key, or workspace member — but Vercel's fee policy is easier to model.

Model offerings: count live routes, not homepage claims

Catalog totals age badly. I queried both public model APIs on August 3, 2026:

• Vercel's GET /v1/models returned 313 models: 208 language, 24 embedding, 5 reranking, 32 image, 30 video, 6 realtime, 3 speech, and 5 transcription models.
• OpenRouter's GET /api/v1/models returned 337 entries across 58 creator prefixes. Its pricing page advertised 400+ models and 70+ providers at the same time.

The counts use different taxonomies. OpenRouter exposes image, audio, and video generation through dedicated APIs and its AI SDK provider, while its main catalog remains centered on generative models. Vercel puts model type directly into one catalog response. A raw total does not tell you whether the particular model, modality, or provider route you need exists.

Language-model breadth still favors OpenRouter. It lists more experimental releases, open-weight variants, free endpoints, and rolling aliases such as ~anthropic/claude-sonnet-latest. Those aliases make scouting fast and make reproduction harder: the same slug can resolve to a different model next week. I use exact model IDs in production and aliases in the lab.

Vercel's catalog is more curated and easier to scan as an application dependency. Its model records expose the context window, supported parameters, modality, cache pricing, and tiered pricing in a consistent shape. The provider detail pages add live latency, throughput, and uptime. That model table remains the best part of the product for my workflow.

Provider redundancy: OpenRouter has more lanes where it matters

I counted distinct provider names for five models present in both catalogs. These are live inventory snapshots, not contractual capacity:

I took the counts from each model's endpoint inventory. The raw OpenRouter DeepSeek inventory and Vercel DeepSeek inventory show the provider names, prices, supported parameters, context limits, and current uptime behind one row of the table.

The pattern matters more than the totals. Proprietary frontier models can run only where the creator permits them to run. Both gateways reach the same small group: the first party and a few hyperscalers. Open weights can run across specialist inference companies, clouds, and regional hosts. OpenRouter's provider marketplace gives it much more route density there.

More routes improve the chance of surviving a provider outage, a sold-out tier, or a rate cap. They also introduce more behavioral variance. Two hosts serving the same open weights may use different quantization, context limits, tool-call support, or inference settings. OpenRouter exposes controls for quantizations, require_parameters, provider allowlists and denylists, and maximum price. Those controls let me define what counts as an acceptable fallback instead of treating every endpoint carrying the same model ID as equivalent.

Vercel covers the controls I need most often: order, only, provider timeouts, model fallbacks, and sorting by cost, time to first token, or output throughput. Provider health can demote a degraded route even when it wins the requested sort. The response metadata records every model and provider attempt, which makes a recovered failure visible after the fact.

OpenRouter goes further. Its provider routing can use p50 through p99 latency or throughput thresholds, a price ceiling, parameter support, data-collection policy, ZDR, quantization, region, provider order, or explicit exclusions. The default load balancer weights lower-cost providers more heavily while accounting for uptime. Setting sort or order turns that load balancing off and gives you deterministic priority.

Vercel's default optimizes from recent uptime and latency. OpenRouter's default gives price more influence. I set the policy explicitly for important workloads on either product. Defaults are product opinions, and routing policy belongs in the application design.

OpenRouter routes prompts to models; Vercel routes model names

OpenRouter has another routing layer: routers that select the model from the prompt. Its current openrouter/auto-beta classifies the task, ranks models using recent usage by task type, applies a cost-versus-quality setting, and builds a fallback list. Custom classifiers and reusable presets can move that policy out of application code.

Vercel's model-level controls are deterministic. You request one model, list fallbacks, or define a team-wide rewrite or deny rule. Routing rules are currently beta and operate on model names rather than prompt semantics.

I prefer deterministic routing for evaluated production paths. A support classifier, document extractor, or coding agent should run the model version I tested until a controlled change replaces it. Automatic model routing is useful for a model lab, mixed one-shot traffic, and applications where cost matters more than byte-for-byte reproducibility. OpenRouter has the stronger product for that job.

Developer experience: platform-native versus endpoint-native

Inside a current AI SDK application, Vercel is hard to beat:

import { generateText } from 'ai'

const result = await generateText({
  model: 'anthropic/claude-sonnet-5',
  prompt: 'Review this pull request.',
})

A plain creator/model string uses AI Gateway as the AI SDK's default provider. A deployment on Vercel can authenticate through OIDC, so there is no long-lived gateway key to rotate. Local development pulls a short-lived OIDC token with vercel env pull. The same Gateway also exposes OpenAI Chat Completions, OpenAI Responses, OpenResponses, and Anthropic Messages APIs for clients outside the AI SDK.

OpenRouter asks for one more explicit dependency in an AI SDK project:

import { createOpenRouter } from '@openrouter/ai-sdk-provider'
import { generateText } from 'ai'

const openrouter = createOpenRouter({
  apiKey: process.env.OPENROUTER_API_KEY,
})

const result = await generateText({
  model: openrouter('anthropic/claude-sonnet-5'),
  prompt: 'Review this pull request.',
})

That explicit client becomes an advantage outside Vercel. Any runtime that can make an HTTP request can call OpenRouter's OpenAI-compatible endpoint. The official TypeScript and Python clients are thin, and existing OpenAI SDK code usually needs a base URL and key change. This is why OpenRouter fit Hermes on EC2: its identity and billing are independent of the cloud running the agent.

The practical DX split is simple. Vercel removes code and secret management from a Vercel application. OpenRouter removes assumptions about where the application runs.

Prompt caching changes the routing decision

Both gateways normalize prompt caching across providers that require explicit cache markers. Both report cache reads and writes. OpenRouter adds a feature I want Vercel to copy: provider sticky routing.

After a cached request, OpenRouter keeps that conversation on the same provider endpoint. You can pass a session_id to establish the affinity before the first cache hit. If the provider fails, routing opens back up and the request falls through. The same ID groups an agent's requests in the session log.

Vercel's automatic caching is strong at the prompt layer. It inserts cache breakpoints for Anthropic and MiniMax, and its Responses API supports a stable cache anchor plus five-minute or one-hour entries. I could not find a documented equivalent to OpenRouter's conversation-level provider affinity. For a cache-heavy agent, I would pin a Vercel provider with order or only, then let failover trade a cache miss for availability only when that route fails.

This is the core tension in redundant agent routing: failover wants freedom to move; prompt caching wants every turn to land on the same warm provider. OpenRouter makes that tension an explicit session primitive.

Observability, budgets, and privacy

Vercel's operational controls fit its deployment model. Budgets can apply at team, project, and API-key scope, and an OIDC-authenticated request automatically counts against its Vercel project. The dashboard groups requests and spend by project and key, shows token counts and time to first token, and exposes the full provider-attempt chain. Filtered logs export as CSV or JSON. The generation and credits APIs cover programmatic lookup; custom reporting handles aggregated spend by user, tag, model, and provider.

OpenRouter gives each API key a credit limit and exposes usage by model, provider, and key. Its workspaces, presets, organization policy controls, SSO, SCIM, and enforced workspace budgets expand on enterprise plans. Session grouping is better suited to long agent traces, especially when a single session crosses chat, image, video, and speech calls.

Both gateways say they avoid storing prompt and completion content by default. Upstream provider policy remains the real boundary. OpenRouter can enforce ZDR globally or per request and filter providers by data-collection policy. Vercel itself operates the Gateway under ZDR and offers provider-level ZDR routing on Pro and Enterprise: per-request enforcement has no added fee, while team-wide enforcement costs $0.10 per thousand successful requests.

For sensitive traffic, I would set the policy in the request or at the team level, restrict the eligible providers, and verify the resolved route in metadata. A gateway creates one policy surface. It does not erase the provider contracts behind it.

The failure modes I would design around

A fallback can succeed technically and fail semantically. Provider fallback within one closed model is the safer form. Cross-model fallback should run only between models that passed the same eval set for that route.

The same open weights can behave differently across hosts. Quantization, context length, tool support, tokenizer patches, and inference parameters vary. Require the parameters you use and limit quantization when output stability matters.

A routing change can destroy cache economics. Send a stable session identifier where OpenRouter supports it. On Vercel, pin the preferred provider for long conversations and treat failover as a cold-cache event.

A low credit balance becomes an availability problem. Both products use prepaid credits for managed capacity. Auto top-up and a budget need to be configured together: one prevents an accidental outage, the other contains a runaway loop.

Catalog entries are promises with short half-lives. Query the model and endpoint APIs during deployment, pin exact IDs, and fail a health check when a required provider or capability disappears.

Which one I would choose

Choose Vercel AI Gateway when the application already runs on Vercel, uses the AI SDK, and has a known model shortlist. You get OIDC, fewer integration lines, zero markup, project-aware budgets, clean request traces, and enough provider routing for most production applications. This is the route I use for my Vercel agents and for the large middle slice of shareable Claude Code work.

Choose OpenRouter when the gateway must outlive the hosting platform, when you sample open-weight models frequently, or when routing policy is part of the product. Its provider pool is wider, its controls are deeper, its automatic model routers are real routing products, and its session affinity respects the economics of agent prompts. This is why Hermes uses it on AWS.

Use both when the workloads already split along that boundary. The extra vendor is justified only if each owns a clear lane. Mine does:

Verdict

Vercel AI Gateway is the better integrated gateway and the cheaper path when the upstream route is equal. OpenRouter is the more capable router: broader language-model inventory, more open-weight deployments, richer provider policy, cache-aware session affinity, and automatic model selection.

My current default remains Vercel because my hosted agents already live there and my measured workloads benefit from its cost model, model table, and OIDC path. OpenRouter keeps the jobs Vercel cannot absorb as cleanly: portable agents, long-tail models, and routing across the widest provider pool.

The deciding question is where you want the intelligence to live. Vercel puts it around the application and its deployment. OpenRouter puts it in the inference route.