Vercel Token Pass Fallback: Which AI Gateway Key Keeps Calls Running

If your team holds a Vercel Token Pass subscription on a Pro plan, the short answer to which AI Gateway credential keeps calls running is now: a standard API key or an OIDC token. According to Vercel’s changelog published today, 2026-11-06, Token Pass credit applies automatically regardless of how a request authenticates, but only those two credential types fall back to team AI Gateway credits when the Token Pass balance runs out. Dedicated Token Pass keys, including any created during setup, still stop cold until the next billing period. Everything behavioral here comes from a changelog published the same day; treat the mechanics below as Vercel’s stated design rather than field-verified behavior, and consult the Token Pass documentation the changelog links to before acting on it.

The practical consequence is a quiet one: credit-exhaustion handling just moved from billing configuration into key architecture. If your production traffic still authenticates with a setup-era Token Pass key, you have no fallback.

What changed today

The changelog makes four distinct changes, and it is worth separating them because they do not all apply to the same credentials.

First, Token Pass credit now attaches to the account, not the key: “Token Pass credit now applies automatically to included model usage through AI Gateway, whether a request authenticates with an API key, OIDC token, or fx login. No dedicated Token Pass API key is required, though you can still create one from the dashboard or the CLI for keys scoped only to featured models and providers.”

Second, exhaustion behavior diverges by credential: “When Token Pass credit runs out for the billing period, requests from a standard key or OIDC token fall back to your team’s AI Gateway credits. Token Pass keys still stop until the next billing period.”

Third, data-retention routing differs between the Token Pass path and the fallback path: “Requests served through the Token Pass provider remain Zero Data Retention (ZDR). Fallback requests follow your team’s setting. With team-wide ZDR enabled, they route only to ZDR providers.”

Fourth, availability is scoped: the behavior is “Available now for Token Pass subscribers on Pro teams,” and Vercel’s own migration instruction is explicit: “If you created a Token Pass key during setup, switch to a standard API key or OIDC token to get fallback.”

That last sentence is unusual. Vendors rarely tell you to stop using a credential type they issued. Treat it as the headline.

The credential matrix

The cleanest way to hold the four behaviors is as a matrix, because no single sentence in the changelog covers every credential across every axis.

Two cells deserve attention rather than assumptions.

The fx login row is genuinely blank on fallback. The changelog’s fallback sentence names only “a standard key or OIDC token,” and its automatic-credit sentence names fx login separately. The reasonable reading is that fx login gets credit but its exhaustion behavior was not specified, not that it silently inherits fallback. If any of your local or CLI-driven workflows authenticate through fx login and would hurt if they stopped at month-end, verify that path directly with Vercel before relying on it. Do not fill the gap with optimism.

The dedicated Token Pass key row is the one that changes architecture. These keys remain valid and still receive Token Pass credit; they simply have no continuation path once that credit is gone. And because they are “scoped only to featured models and providers,” they behave differently from standard keys in a second way: switching credentials can broaden which models and providers your traffic can reach. That is a routing change as much as a billing one.

Independent research on enterprise gateway authentication reaches the same structural conclusion. A PayPal Enterprise AI Platform Engineering paper on MCP gateway auth (a two-author preprint, author-reported and not independently replicated) puts it plainly: “No single credential type covers this space.” Their context is different, OAuth versus static keys versus service accounts across mixed callers, but the underlying lesson transfers: the right credential depends on the caller and the failure mode you care about, so selection belongs in a per-caller matrix rather than a team-wide default. For an interactive developer session, a hard stop at credit exhaustion may be acceptable or even desirable as a cost cap. For a headless production automation serving customers, a hard stop is an outage. Same gateway, different answer.

The silent trap: setup-era keys keep working but lose fallback

The riskiest property of this change is that nothing breaks today. A dedicated Token Pass key issued during setup still authenticates, still routes to its featured models, and still draws down Token Pass credit. The only thing it lost, relative to the new default, is the fallback that standard keys now get for free.

That asymmetry inverts the usual intuition. Normally the older, more specific credential is the conservative choice. Here the setup-era key is strictly worse on the exhaustion axis: it carries all of the credit-exhaustion risk with none of the fallback. Vercel’s instruction to switch is the vendor saying the setup-era credential is now the wrong one to keep.

There is one scenario where keeping a dedicated Token Pass key is defensible: as a deliberate spend ceiling. If a workload should stop, loudly, when Token Pass credit is exhausted rather than drawing down team AI Gateway credits, the hard stop is a feature. But that should be a decision someone made and wrote down, not an accident of which key was pasted into an environment variable during setup. I would audit every Token Pass key currently in service and ask, for each one: if this stopped at 11 p.m. on the last day of the billing period, who notices, and what breaks? If the answer is “a customer’s request,” that key should be a standard API key or OIDC token.

ZDR compliance: where fallback traffic actually goes

For teams with Zero Data Retention obligations, the changelog’s ZDR paragraph contains a split that matters more than the fallback itself.

Requests served through the Token Pass provider remain ZDR. That part is unconditional in the vendor’s telling. Fallback requests, however, “follow your team’s setting,” and only “with team-wide ZDR enabled, they route only to ZDR providers.”

Read that from a compliance owner’s seat. Before this change, a workload pinned to a dedicated Token Pass key was ZDR end to end by construction: Token Pass credit, Token Pass provider, hard stop. After migration to a standard key, the same workload is ZDR only while Token Pass credit lasts. The moment fallback engages, retention posture depends on a team-level setting. If team-wide ZDR is off, fallback traffic may route to providers without a zero-retention commitment, and the changelog describes no signal marking the transition; confirm in your own account whether fallback routing is observable before relying on noticing it.

So the migration has a compliance precondition beyond the credential swap: enable team-wide ZDR before cutting traffic over, or confirm in writing that your retention requirements permit non-ZDR fallback providers. There is a second, subtler check. Because dedicated Token Pass keys are scoped to featured models and providers, moving to a standard key can broaden the set of providers your requests may reach even before fallback engages. Compliance owners should re-verify the actual provider list traffic touches after the switch, not assume it matches the old scoped list.

One caveat on all of this: the ZDR routing rules come from the changelog alone. If your organization treats ZDR as a contractual or regulatory line, verify the fallback routing behavior in your own account before depending on it, and get the team-setting interaction confirmed rather than inferred from a changelog sentence.

Migration checklist: create, cut over, verify, then retire

Vercel supplies the direction of the migration; it does not supply a sequence. The sequencing below is an inference from standard credential-rotation practice, not a Vercel procedure. A language-independent specification for rotating refresh tokens describes the principle cleanly. Its “zero invalidation” claim is about key rotation specifically, where verification keeps using the recorded key while minting switches to the new one, but the rule generalizes: introduce the new credential alongside the old, switch minting to the new one, and keep verifying with the old until transition completes. Applied here, that means do not delete the Token Pass key first.

A workable sequence:

1. Inventory. List every environment, deployment, and local workflow authenticating to AI Gateway with a dedicated Token Pass key. Include CI jobs; they are the ones nobody remembers.
2. Create the replacement first. Issue a standard API key, or configure OIDC token authentication. The changelog’s dashboard-or-CLI sentence covers creating a dedicated Token Pass key only; it says nothing about how standard keys are issued, so take the exact steps from Vercel’s API-keys documentation.
3. Check the ZDR precondition. If retention matters, enable team-wide ZDR before the cutover, not after.
4. Cut traffic over. Update one environment at a time. Keep the old Token Pass key active during the transition so a missed caller fails visibly against the old key rather than silently.
5. Verify the fallback path. Confirm, in your own account, that a request against the new credential draws Token Pass credit automatically. If you can, exercise the exhaustion path in a non-production project before the billing period ends in production; the cheapest time to learn its error and latency semantics is now.
6. Retire the old key. Delete the dedicated Token Pass key only after traffic has run clean on the new credential and you have confirmed no straggler callers.

Two honest gaps in this list: neither the changelog nor the pricing page gives command-level steps, so the exact clicks and flags are yours to confirm in Vercel’s documentation; and the dual-key overlap step assumes both keys can be live simultaneously on one team, which the changelog implies but does not state outright. Verify that before scheduling the cutover around it.

What to monitor as the billing period ends

The fallback changes what “running out of credit” looks like. Previously, exhaustion meant a hard stop you could not miss. After migration, exhaustion means a silent transition to team AI Gateway credits, which is the desired behavior for uptime but a new way to spend money without noticing.

Pro teams already have the tooling for this: Vercel’s pricing page lists managed fallback, spend monitoring, and automatic retries among AI Gateway capabilities, with 500 included token requests per month on the plan ladder shown. So the monitoring step does not require new purchases; it requires actually reading the spend view as the period closes.

One caution from independent research: do not read credit exhaustion off a single ledger. arXiv:2609.24991, a cost-attribution study, reports that AI spend attribution breaks at the seams between gateway logs and provider bills, and that naively joining every source “double counts all gateway spend.” Their tool spans Kubernetes allocations, gateway logs, and provider bills, a broader stack than Vercel-only teams run, so the specific double-counting failure may not map directly onto your setup. The durable lesson does: at a billing boundary, cross-check the dashboard’s credit-exhaustion signal against a second view (provider-side usage, request counts, or your own logs) before concluding the Token Pass balance is actually gone. A false exhaustion reading now has a cost it did not have before: it looks identical to normal operation while quietly billing team credits.

Practical targets to watch in the final days of a period: the rate of Token Pass credit drawdown against the remaining days, the first fallback request, which marks the moment credit actually ran out, and, for ZDR-bound teams, confirmation that fallback requests routed only to ZDR providers.

One action this week

If you take one action from this, take the cheap one: find every setup-era Token Pass key in your infrastructure this week, and decide deliberately, per caller, whether it should hard-stop or fall back. The vendor has made the fallback the default for everything except a key created during setup; if yours dates from setup, the changelog’s own instruction is to switch. That inversion is easy to miss, and the only cost of checking is an afternoon.

Frequently Asked Questions

Which AI Gateway credentials fall back to team credits when Token Pass runs out?

When Token Pass credit runs out for the billing period, requests from a standard key or OIDC token fall back to your team’s AI Gateway credits. Token Pass keys still stop until the next billing period.

What should I do if I created a Token Pass key during setup?

If you created a Token Pass key during setup, switch to a standard API key or OIDC token to get fallback.

How does Zero Data Retention (ZDR) apply to fallback requests?

Requests served through the Token Pass provider remain Zero Data Retention (ZDR). Fallback requests follow your team’s setting. With team-wide ZDR enabled, they route only to ZDR providers.